You have it already on VSCode, which isn't quite the same, however nowadays it is an open question which one is more relevant for Microsoft's management, especially given that VS isn't cross platform (see Azure), and is stuck with WPF/.NET Framework.
Optimistic to assume that modern day programmers even know what a debugger is, or if they do, consider it as anything else than some weird ancient shibboleth only used by the greybeards ;)
To be fair, even before LLMs could spot my bugs in an instant I really only regularly used debuggers in C because it can't display arbitrary types in debug print statements.
Debuggers still have their place in algorithm heavy work, or to pull apart heap dumps to try and figure out obscure bugs.
Even LLMs use debuggers. I asked Claude to reverse engineer a closed source binary the other day. It used gdb to trace its behaviour. Didn’t even use ghidra.
> even before LLMs could spot my bugs in an instant
I guess it depends on the bugs.
LLMs even INSIDE the (VS) debugger couldn't work out some of the more recent bugs I have been looking at. Never mind by statically looking at the code base.
println!() already works, who needs more than that?
Kidding aside, VS Code has excellent debugging support already. Unless you need to share your Rust code base with a legacy C/C++ code base, I don't think VS is the best environment for Rust programming.
There are good use cases for staying within full-fat VS's capability set (drivers, among other things), but I don't think Microsoft needs to add Rust to VS in this much of a hurry.
IDK about "tier 1" but I'll note I've used VS for debugging and profiling Rust binaries. I even wrote a tool to auto-generate a wrapper .sln so I can easily launch from VS: https://github.com/MaulingMonkey/cargo-vs
This is very big news, all major OS vendors that also have a role in C and C++ language tooling, now have diversified their options in systems programming languages for greenfield development.
Additionally we finally get some public news about the MSVC integration rumors regarding Rust.
I'm totally disgusted that my Visual Studio 2022 instance uses 2 Gigabytes (!!) of RAM to run. What the hell is it doing that it's using that kind of memory?
How about those morons solving that first before moving towards Rust. An IDE shouldn't have to use more than a 100MB of RAM tops. Anything more is inexcusable.
BTW Firefox uses 1.1GB RAM so it's not immune from criticism either.
You're right, though I'm not sure about all modern software quite to that extent. VS does have a reputation for being bloated. Even startup is not super fast IMO.
I checked just now. A recent Delphi with a project open: 175-200MB. Water (our IDE, I work at RemObjects) about 300MB.
clangd alone uses 6 GB when working with Chromium’s codebase. Code indexes can be very large, even for a simple application. Out-of-the-box IDEs must index the standard library and keep it in memory.
Tier 1 is the summit of summits - the summum bonum of languages, the highest order to which a language can aspire. Very few ever attain it. Non multa, sed multum: not many, but only those of extraordinary quality. Most languages remain forever in Tier 3, never passing beyond its gates. Of these, scarcely 1% ascend to Tier 2. And from that already distinguished company, a mere 0.1% possess the refinement, depth, and excellence required to cross the final threshold into Tier 1.
Consider what that means: Tier 1 represents roughly the top 0.001% of languages. Pauci sed electi - few, but chosen. The crème de la crème. The aristocracy of languages. Primus inter pares, yet standing at the very edge of what programming language greatness can be.
Ad astra per aspera. Through hardship, to the stars. Tier 1 is not merely another rank: it is the ultima Thule, the farthest frontier, the crown, the apotheosis.
Yes, about as good as a language that is 40 years old, and was also (like Rust) 10 years old when becoming Tier 1 inside Microsoft, while there were far less alternatives.
This is great! Hope this trend will continue in the future; using a memory-safe language should be a top priority imo in context of the coming rogue AI swarms.
Yeah I'd written some rust ~ 10 years ago when the language was very different and that led me to believe that it was a 'great within it's niche' sort of thing for a long time, but after spending the last couple of years with it as a daily driver I think it's a pretty great general-purpose language.
The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.
It is interesting to see the different patterns used due to different cases and tastes. For example, my concurrency patterns rarely use locks, and are instead usually one of:
- Dedicated hardware via DMA, multiple cores/MCUs etc
- Thread pools (e.g rayon)
- GPU
- SIMD
- Atomics
- Interrupts and their ISRs
- Event loops
- std::sync Thread and MPSC (My Std rust default for not blocking the GUI etc)
Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight.
Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).
jdcasale you are right that Arc<RwLock<T>> is a code smell but I would take that a bit further that locking immutable data is even more of a smell. The real bad guy in this case is the RwLock not Arc. For anything that you hydrated once and never mutate you do not need the RwLock. Arc just clones the pointer so it is safe to share for concurrent reads so something like Arc<T> is fine and if you need initialization locking then LazyLock<Arc<T>> lets you lock the initialization but then everything else is just a pointer copy.
I hit this recently while building a url unfurl social card renderer for a project which ended up being something like LazyLock<Arc<Database>>
The overuse of the phrase "code smell" is a skill level smell. Too much time spent cargo culting code elegance, not enough time spent in the byte mines.
I've said for a while that the main reason Rust is so popular is that it has a lot of effort put into the developer experience, with the low-level safety honestly not being all that important to a large portion of the programmers who would be fine with a garbage collector. I used to think that maybe a "Rust with garbage collector" would come along, but at this point it honestly seems more likely that an optional garbage collector would be added to Rust (probably with just the primitives in std and leaving it up to libraries to provide a more full experience, like with async runtimes).
No, a class-based OO language where you need to spend effort crafting build targets by hand or use an IDE to define how to build is not anything close to what I'm talking about. If you think that it's "Rust with GC", I think you're misunderstanding what actually appeals to most people about Rust.
I'd also argue that "runs on all OS" is true, but "is easy to develop without extra work in a cross-platform way" is not. I've never cloned a Rust project and had trouble building out of the box on Linux, but I'd estimate maybe one out of 20 C# projects I clone from Github build for me out of the box with `dotnet build`; the rest either require me manually tweaking the build configs to avoid stuff like hardcoded Windows-style paths or link to system dependencies that don't exist on Linux. I imagine you might argue that this is a property of how people use the language rather than the language itself, but that doesn't really matter from the standpoint of whether it's worth it for developers who don't use Windows to spend any time trying to invest in the ecosystem.
Oh, its good at doing desktop applications these days? Which GUI libraries are good these days? Some native win32 binding? Are there good equivalents for Qt?
I'm interested in getting back to native application development; the job is on Electron right now and it's… meh.
Note: You ask different people, and they will all have their favorite tool kits. GPUI is very promising but new. There are a pile of others people will vouch for like Druid, Tauri (Electron-like but faster?) Slint (As the sibling poster pointed out), Iced, Qt bindings etc. I am not sure about native Windows etc bindings: I recognize that OS-native things like that are the most performant, but for me it's worth it to make my programs cross-platform and not worry about OS-specific things.
Note: EGUI is an immediate mode GUI, which isn't for all applications. But it has never limited me, and have written some complex UIs with integrated 3D etc.
> Oh, its good at doing desktop applications these days? Which GUI libraries are good these days? Some native win32 binding? Are there good equivalents for Qt?
If your goal is "delivering applications to only good-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features with a lot of bugs because Qt.
The only foolproof way of having truly professional software is still the same: have N different, very-well integrated apps (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron.
I feel like the weather app makes a lot of sense from a corporate politics point of view.
A 1mb weather app would have a significantly less impressive pie chart associated with it come "here are our improvements" presentation.
Also if times get tough and you're told to reduce headcount by 10%, who do you want to get rid of. Sally who knows the USB driver end to end or Todd who wrote the bloated 1gb weather app. (Don't feel bad for Todd, he knew what he was getting himself into.)
I've been doing forest service stuff for a year with almost no signal and often no gps without antenna and it's incredible what asks for location permission to run. My amazon bought LEDs (15+, 3-5 diff types) all check location before I can connect them. I wind up waiting 30 seconds sometimes more to turn lights on.
Also I've been shadowbanned from a bunch of social media sites and had problems with payment systems, etc because Starlink confuses companies tracking user locations to geoips etc.
Won't even get into the apps that look downloaded and usable until you open them with no signal and they don't work before phoning home.
I've been meaning to go through ALL my apps and delete everything I don't use, I haven't installed a new app in years.
Then you have MacOS now that has the most "wtf" level permission prompts that make you think everything is phoning home or trying to access stuff on your network when it's just connecting bluetooth devices or something daily. I don't know how many games I've installed that now show up as having full screen or keyboard control permissions just to use input devices.
Android's permission system conflates the Bluetooth scanning permission with the "Fine location" permission, because in theory any app that can enumerate nearby Bluetooth devices (including things like nearby Bluetooth Low Energy beacons commonly found in stores and malls) could use that information to locate your phone within a few hundred feet.
It seems like there's a newer build option to explicitly disable the "Fine location" permission prompt while still being able to scan for Bluetooth devices, but such beacons are somehow filtered from the list if it's enabled, and it's only available for builds targeting newer Android versions.
Ah, most of the people just click yes, yes, allow, allow, yesIamsure, next. Especially when the system is training them to do exatly this by these meaningless warnings you described.
I'm sure at least some of those macOS permissions prompts are spurious, but for the most part I think they're genuine red flags of poor software quality if not actual security/privacy threats. When a video game prompts for full disk access, it's probably because it wants to spray config and save files all over my home directory instead of putting them in a platform-appropriate location. When it triggers a permissions prompt about Bluetooth, it's probably using the wrong API to get input from a game controller or the wrong API for identifying what kind of input devices are present. If it triggers the "wants to control your system" prompt, it's probably trying to keep responding to input even when it's no longer the foreground application.
Sometimes the right API might not actually exist, but most of the time it's just lazy developers half-assing a port with no care for making the application behave appropriately for the platform. The prevalence of "Please don't turn off your computer while the game is saving" warnings is pretty clear proof that game devs in particular don't make any platform-specific adjustments they aren't forced to. (Game consoles usually require those warnings, but they're stupidly out of touch on a computer.)
My point is that the notifications are less specific now, so whether or not someone is being a normal dev, which nearly all if not all of them are in my experience, you still get a giant "FULL DISK ACCESS" because a game wants access to your download directory or something ridiculous.
Unrelatedly, I'm still trying to figure out why Apple requires me to unlock my phone to look at the weather. Is there some concern that someone could pick up my phone and learn what city it is in?
Nope; the lockscreen camera is actually an entirely different app, or not-quite-app thing. (Note what happens when you open the camera roll in the lockscreen camera.)
You can use the weather widget on the lock screen, and as long as you have lock screen content when locked enabled, you can see the current area's weather just fine. Or do you want the whole app experience?
The list of professions made obsolete is very long. Why should programming be protected if AI in the future can make software better, safer, and cheaper?
Not to mention, they have 1 GB of headroom in their back pocket if/when they need to make Windows more efficient. Quick rewrite of that app or just scrap it and they've saved months of optimization.
I think it's less about pie charts and more that weather apps can be very eyecandy-heavy. This sort of marketing works well for both consumers and board members.
It's also only 45 frames uncompressed at 4k. It's remarkably easy to hit that if your base assets are mostly raster rather than vector for a dynamic scene.
Obviously, they should try harder, and this is an explanation rather than an excuse, but the graphics assets are mostly why.
I mean, I usually check the weather by putting "weather" into a search engine. And this will show me little SVG icons that take up a tiny fraction of my low-resolution screen and probably involve like less than a kilobyte of path description. And I think this looks perfectly fine and I can hardly even fathom why anyone would want it to be fancier than that. I think that even animating them would make the display actively worse.
Based on windows bloat Sally got fired because she was an old timer and cost to much so all the Sally's are gone and they're all Todd's now and windows is an unstable bloated mess.
The corporate dilemma between "I hired some less competent engineers and they're dragging the team down" and "I hired only highly capable engineers and now I have to give 10% of them bad reviews in stack ranking and later let them go"
There's premature optimisation, where you write a whole bunch of complicated code to avoid cloning an Arc<>. And then there's "premature optimisation" where you skip any consideration for performance until it becomes a problem.
The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.
"Keep calm and clone" is a good advice for beginners. Then it is also a good advice for experts - because when you're an expert and you just think of cloning, that probably means it is easier than borrowing which you would default to.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Notice the aspects and the reasons for knuth's "premature optimization". Is it making the code harder to debug and read? Is it a non-critical path?
If an optimization doesn't impact readability or debugability (for example, picking a datastructure that fits the problem instead of just using a List for everything). Then you should do it.
I see the quote so often pulled by people that want to justify inserting a n^2 algorithm when a log(n) solution is either the same amount of code or 1 line extra.
There's also important context about the era knuth was programming in. Optimization in the era of knuth was targeting the hardware and tickling things like the CPU cache and memory in a very specific way. It was things like clever bit manipulation and packing to save memory. That's the context. In modern terms it'd be "don't use SIMD intrinsics until you know you need them". It wouldn't be "Don't think about algorithmic complexity" which is where I most often see that kludge deployed.
The question to me in terms of memory is, if you're writing a weather app on windows why are you not using C#.
The point of these low/zero overhead languages like Rust is you're in an environment where memory management is ultra critical. The dotnet garbage collector does more than a good enough job for a weather app, likely a much better one than vibe coded .clone() Rust
Maybe they fired all their experienced developers and only have cheap vibecoders now, I don’t know. The decisions of beancounters and lawyers that control these companies are mysterious to me.
Now that WinUI has a Rust API, I think using Rust is a no-brainer.
The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.
The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.
Now extrapolate on all windows included apps and ui elements.
This argument applies regardless of how you feel about vibecoding. Lately people have been asking for x64 machine language and getting reasonable results.
That's less because of what it's implemented in - and more to do with all the tracking and libraries they want to reuse...
BigCo apps will take up lots of space and memory for BigCo reasons - obviously less if it's in Rust vs Go vs Python, but you could easily write Go apps that use far less memory than Rust apps written at BigCo due to BigCo reasons.
It's just not really that much of a priority for them to have their weather app use less than 1GB of memory. It's a far bigger priority for someone to insist that somebody else uses some bloated framework so they can get promoted.
I've been having _a lot of fun_ writing Go apps that don't allocate anything and that use small, preallocated buffers to stream through requests/etc. Basically TigerStyle for Go. I don't use arenas, I just size everything for the worst case (or make the sizes configurable at startup) and still end up using much less memory.
This is really only possible because I told Fable to build the underlying allocation-free HTTP, JSON, etc libraries and consequently I'm not building anything serious yet (although the libraries are well-tested using pre-existing corpuses from reputable projects e.g. curl as well as fuzz tested).
Most "outputs" are passed as out parameters for the function to fill in, and results are Rust-like enums (a Go tagged union containing only small data). I could also have returned (T, error) but I would have to take care that the thing I pushed into the error argument doesn't allocate--not sure if I made the right decision or not, but for now it feels nice. The worst part is that I don't really have a good way to communicate detailed error information, but that hasn't bitten me yet.
This has also been a lot less effort than writing Rust, although Rust would have real checks for lifetimes and im/mutable and enum exhaustiveness and so on--so far I haven't been bitten, and I suspect things like enum exhaustiveness can be addressed via linter if necessary.
> This has also been a lot less effort than writing Rust
I have never written such Go, but as an experienced Rust programmer I can tell you Rust is not hard to write after learning it. Learning it can take more time than usual (although there is also contrary evidence, e.g. from Google) but after you're used to it, you're basically as proficient as in other languages, except some glitches (that can be expensive - rewriting your main structure, but are fortunately rare). Considering the effort involved in coding in such unnatural Go variant, I tend to believe it is far easier to code in Rust (including coding in Rust using this style, since it is more suited to it).
Of course, if you're just vibe coding everything, maybe it is easier because maybe the LLMs write such Go better that they write Rust. But if you're not, even if you're only reviewing the code, I believe it's easier to review Rust code than to review such Go code (and potentially than reviewing any Go code, but that is a different matter).
I was a little bit scared at first, but after 1k lines of code written by hand I started to forget that Rust was complicated. It's not the Go experience, but it's not that bad at all.
If I was writing no-alloc production code, I would stick with Rust, FWIW, at least until Go's library ecosystem improves.
I don't mind writing Rust (have been dabbling with it since ~2014), especially with some AI assistance. It's just more of a grind for me than working with Go.
> Considering the effort involved in coding in such unnatural Go variant,
I was also expecting writing Go in this style to be more friction, but it was surprisingly smooth. The friction was entirely from lack of libraries and a little uncertainty about how to communicate errors without allocating. Rust has better libraries by far, but I felt more friction from the language (e.g., if you have a buffer you have to initialize every element of it or you have to use something like `heapless::Vec`--not a big deal, just decisions to make to figure out what the happy path is).
I touched OCaml several years ago and ran into a bunch of problems with build tooling, standard library, syntax noise, ideological/unhelpful community, etc that turned me off. I'm also just not experienced enough to write OCaml without a GC; that would be biting off a lot of learning.
Reminds me of how they allow OEMs to install bloatware through Windows update now. I believe LG did something that leads to various app installs when you connect their monitors via HDMI.
You gotta have balls or be receiving tons of money to publicly celebrate the sloppiest software company of the decade making your programming language Tier 1 internally.
Codegen was still done via LLVM. LLVM supports the MSVC _runtime_, here they're talking about using their (arguably worse) backend directly to generate code and do optimisations
... but why? The MSVC backend has been falling far behind LLVM with every release. I understand they want uniformity but IMHO either they catch up or they switch fully to LLVM, if they can
Because it takes time. Even with coding agents, to add the capability. Then, there is the question on whether Rust developers who like to engage with Microsoft tools, would really consider Visual Studio as their IDE, instead of something like VS Code, VS Code Agent Mode, GitHub Copilot App, or GitHub Copilot CLI with simpler editors.
I'd be curious to know whether Rust developers believe Visual Studio is the right place for Microsoft to invest Rust specific coding capabilities.
There's two ways to approach this — build tooling for existing Rust developers to get them to adopt the Microsoft stack, or build tooling for existing Microsoft stack developers to get them to adopt Rust.
I'd argue that the former is less important than the latter, and my understanding is that Visual Studio is still the IDE for Windows-centric development, so for those MS-first developers, Rust missing from VS means Rust is poorly supported, end of story.
It would have to be the 2nd option. Who in their right mind would voluntarily choose Windows as their dev env? It will have to be those who are already there.
Most people don't have a choice. Corporate IT has choosen what I run my machine on. I have used a native linux machine, but since my email is still on outlook, everybody uses teams, and all the non-code documents are on windows I end up having to have a windows machine. Linux in a VM under windows ends up being the easiest workflow (though I'm just starting to try WSL and so far it is looking good)
Outlook and Teams are both web apps, or at least they were when I last used them. Even if you download the "native" app it's just Electron. I haven't had trouble using either of them on Linux.
Visual Studio brings a lot to the table for C++ development. Specifically the Debugger, although IntelliSense also often succeeds at queries that stump clangd.
If they can replicate that capability, I think it can be a draw.
I was a mac / Linux guy before my current gig, but Visual Studio is so much more capable than XCode that I basically only use the Windows machine except to debug mac-specific issues. Less so, now, admittedly, that the malware scanner process is literally always pegging a CPU core.
This kind of stuff is why its hard to have good conversations about tooling. Windows is the best place for many kinds of software dev, but perhaps not the kind you are doing.
When it is not the mandated option, under what circumstances is Windows the best choice for software dev? The only domain I can think of is gaming, and Valve is seemingly coming up fast to eat Microsoft's lunch in the next few years.
Valve is certainly increasing the viability of Linux as a platform for gaming, but I can't see developers targeting Wine or Linux for a major game over Windows directly. Not for a decade, if ever.
As mentioned: gaming, most of enterprise dev, graphics/gpu/cad, desktop, certain classes of embedded. Broadly speaking, outside of hacker/web/creative culture, the default is windows.
Regardless of how evil gigantic companies can be, or what the ideal world should look like: from a pure usability perspective, windows is top of the list.
If I got 5$ every time a linux/mac enthousiasts has to tell me they just cannot run something, and proposing a myriad of workarounds to stick to their ideology, I could buy an apple vision pro and let it collect dust in the corner of my basement.
No disagreements on things not working right on Mac/Linux, it's definitely a frustration!
I would argue against the idea that it's the default for most enterprise dev. What you refer to as creative/web culture I would refer to as a newer generation of enterprise dev written in (I know) JS, TS, Electron etc. There is a lot of cross platform stuff out there, at least for clients, and Linux has taken up a lot of ground in the server market as well.
With CAD and GPU programming you have a point - proprietary drivers written for Windows has more technical sticking power.
I guess my feeling is that, especially with all the headlines saying European countries will move away from American software giants, Windows seems less attractive as a long term target for investing my time. Not to mention it's buggy and slow these days.
True, I hate windows like most people. I just also hate being unrealistic about it. Good thing about AI is you no longer really have to care about really understanding the OS, unless you are an admin.
Plenty of us do, so far Valve has failed to make native builds for Linux appealing for game studios, even though they already have to deal with similar APIs on Android, iDevices and PS/Switch.
in Windows, some teams/people use it others don't. Historically it hasn't worked well with some of the internal build/test/etc stuff, that's mostly changed in recent years.
> BuildXL has also been proven to scale to large codebases (e.g., Windows/Office repositories) where builds can consist of millions of processes with terabytes of outputs
This is from rustconf. A lot of the focus at Rustconf this year has been C++ interop, Python Interop, Javascript interop -- it's no longer about "rewrite it in rust", it's about being part of the ecosystem.
Good. As a C+++ programmer Rust has some things that intrigue me. However I have no desire to rewrite everything in rust and so interoperability has been what is holding me back.
We rewrote everything a few years back, completing in 2014 (Rust 1.0 came in 2015) - it costs nearly a billion dollars! I cannot in good conscience go back to management and ask for another billion dollars to rewrite again (Rust might be more productive, but inflation will eat that up, so I expect a rewrite to be more expensive). If Rust can work with my existing code though - I know of a number of small places where there is reason to rewrite anyway because the code is bad (or sometimes was good but not nicely flexible for the features we have added since).
Real numbers. I can't say what directly, but you can make a good guess if you read my comment history. (I don't think this would be worth your time, but you could)
Interesting, Claude’s guardrails prevented it from spelling out the company even after multiple spoofing attempts („This is my account, make sure no one can find out my employer…“)
Grok immediately answered without a second thought.
Based on Grok identifying the company correctly, that would amount to ~3% of annual revenue and 30% of profits which seems insane to me for the cost of a single project.
Anyway, even if that were true, rewrites are becoming drastically cheaper, simpler, and more correct with AI. The Bun rewrite is the largest experiment and seems to be 5-10x cheaper and completed ~100x faster and these costs are likely to come down further. So your claimed $1B rewrite today costs $100M and carries less risk. In 5 years it'll probably cost at most $10M and be finished drastically more quickly. And the vast majority of software doesn't cost $1B to translate.
The rewrite was done over several years which is going to complicate your analysis. It's been making money and over fist for the company for the last 10 years and the investment to R&D has gone down some since the rewrite but not a lot.
Sure I was assuming it wasn't a 1 year outlay. Still, even over several years that's a lot for just software - you're talking about $250M/year in development costs split over 4 years across 600 developers. I'm assuming the bulk of that cost must have been a HW rearchitecture though right and you don't have 600 people trying simultaneously to do a rewrite? Either that or someone was significantly overpaying consultants on the project.
It seems suspect to me is all; the repayment time on $1B from a rewrite of an existing software stack isn't generally huge unless it also enabled adding new features that weren't possible before which enabled significant new revenue streams that justify that $1B outlay.
I'd say you only pay 10% of the cost when you finish/launch the re-written software. The other 90% of cost comes later in the format of operations, deprecation and migration, people both users and devs, community friction and learning cost.
I remember an other 1 tier language ms once had. Anyone remember Visual-J?
On the other hand if we could code in rust and get windows.forms as a ui it might make sense. MS is burning UI layer faster than one can train on
415 comments
[ 0.26 ms ] story [ 7.6 ms ] threadEven LLMs use debuggers. I asked Claude to reverse engineer a closed source binary the other day. It used gdb to trace its behaviour. Didn’t even use ghidra.
I guess it depends on the bugs.
LLMs even INSIDE the (VS) debugger couldn't work out some of the more recent bugs I have been looking at. Never mind by statically looking at the code base.
I can't find my copy of https://en.wikipedia.org/wiki/The_Practice_of_Programming but that is what I recall it says. Those authors are the best known greybeards.
Kidding aside, VS Code has excellent debugging support already. Unless you need to share your Rust code base with a legacy C/C++ code base, I don't think VS is the best environment for Rust programming.
There are good use cases for staying within full-fat VS's capability set (drivers, among other things), but I don't think Microsoft needs to add Rust to VS in this much of a hurry.
The main pain point IME was poor debugger visualizers for standard containers and enums. I fixed some of that for the standard containers by writing some natvis files for std: https://github.com/rust-lang/rust/issues?q=state%3Aclosed%20... . Admittedly, they broke a few times. They also weren't automatically included in the pdbs, so I wrote a crate for that: https://github.com/MaulingMonkey/natvis-pdbs . And then someone crated and stabilized #[debugger_visualizer] for rust itself, which can do the same job: https://doc.rust-lang.org/reference/attributes/debugger.html .
(...I should check on enum visualization, but I suspect it's still poor.)
Additionally we finally get some public news about the MSVC integration rumors regarding Rust.
How about those morons solving that first before moving towards Rust. An IDE shouldn't have to use more than a 100MB of RAM tops. Anything more is inexcusable.
BTW Firefox uses 1.1GB RAM so it's not immune from criticism either.
I checked just now. A recent Delphi with a project open: 175-200MB. Water (our IDE, I work at RemObjects) about 300MB.
Mainly purchased by companies not individuals and will be run on workstation pcs with 16-64gb RAM
So your complaints about 2gb are in the minority I would say, as most users don’t care.
After all, they are stupid enough to pay $1k a year for an IDE per seat!!!
They use wordpress
It's fantastic for websites and servers, and LLMs are very good at generating it.
The primary downside of Rust is the long compile times, especially with macros (serde, etc.) If that can be fixed, it will be sublime.
What’s a Tier 1 language?
Consider what that means: Tier 1 represents roughly the top 0.001% of languages. Pauci sed electi - few, but chosen. The crème de la crème. The aristocracy of languages. Primus inter pares, yet standing at the very edge of what programming language greatness can be.
Ad astra per aspera. Through hardship, to the stars. Tier 1 is not merely another rank: it is the ultima Thule, the farthest frontier, the crown, the apotheosis.
Seems pretty good to me ;)
(I know you're joking).
The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.
Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).
I think C++ is an excellent choice due to its volubility actually. Bc when I want safety, I mostly have it (but I have done a lot of C++, admittedly).
I hit this recently while building a url unfurl social card renderer for a project which ended up being something like LazyLock<Arc<Database>>
If ocaml had a cargo like experience, then I would migrate there.
I'd also argue that "runs on all OS" is true, but "is easy to develop without extra work in a cross-platform way" is not. I've never cloned a Rust project and had trouble building out of the box on Linux, but I'd estimate maybe one out of 20 C# projects I clone from Github build for me out of the box with `dotnet build`; the rest either require me manually tweaking the build configs to avoid stuff like hardcoded Windows-style paths or link to system dependencies that don't exist on Linux. I imagine you might argue that this is a property of how people use the language rather than the language itself, but that doesn't really matter from the standpoint of whether it's worth it for developers who don't use Windows to spend any time trying to invest in the ecosystem.
I'm interested in getting back to native application development; the job is on Electron right now and it's… meh.
Note: You ask different people, and they will all have their favorite tool kits. GPUI is very promising but new. There are a pile of others people will vouch for like Druid, Tauri (Electron-like but faster?) Slint (As the sibling poster pointed out), Iced, Qt bindings etc. I am not sure about native Windows etc bindings: I recognize that OS-native things like that are the most performant, but for me it's worth it to make my programs cross-platform and not worry about OS-specific things.
Note: EGUI is an immediate mode GUI, which isn't for all applications. But it has never limited me, and have written some complex UIs with integrated 3D etc.
If your goal is "delivering applications to only good-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features with a lot of bugs because Qt.
The only foolproof way of having truly professional software is still the same: have N different, very-well integrated apps (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron.
A 1mb weather app would have a significantly less impressive pie chart associated with it come "here are our improvements" presentation.
Also if times get tough and you're told to reduce headcount by 10%, who do you want to get rid of. Sally who knows the USB driver end to end or Todd who wrote the bloated 1gb weather app. (Don't feel bad for Todd, he knew what he was getting himself into.)
Also I've been shadowbanned from a bunch of social media sites and had problems with payment systems, etc because Starlink confuses companies tracking user locations to geoips etc.
Won't even get into the apps that look downloaded and usable until you open them with no signal and they don't work before phoning home.
I've been meaning to go through ALL my apps and delete everything I don't use, I haven't installed a new app in years.
Then you have MacOS now that has the most "wtf" level permission prompts that make you think everything is phoning home or trying to access stuff on your network when it's just connecting bluetooth devices or something daily. I don't know how many games I've installed that now show up as having full screen or keyboard control permissions just to use input devices.
It seems like there's a newer build option to explicitly disable the "Fine location" permission prompt while still being able to scan for Bluetooth devices, but such beacons are somehow filtered from the list if it's enabled, and it's only available for builds targeting newer Android versions.
The forest job sounds nice :)
Sometimes the right API might not actually exist, but most of the time it's just lazy developers half-assing a port with no care for making the application behave appropriately for the platform. The prevalence of "Please don't turn off your computer while the game is saving" warnings is pretty clear proof that game devs in particular don't make any platform-specific adjustments they aren't forced to. (Game consoles usually require those warnings, but they're stupidly out of touch on a computer.)
Sounds like unbounded, dynamic allocation to me!
Replaced by LLM and an offshore contractor. CaPiTaLiSm, right?
Obviously, they should try harder, and this is an explanation rather than an excuse, but the graphics assets are mostly why.
Maybe this has changed since I wrote Rust, but that was a classic beginner fix. Just throw memory at it.
"Keep calm and call clone" is a good strategy for getting things working. Don't prematurely optimize code until you know it's the bottleneck.
The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.
Such a slippery slope between “consideration of performance” and optimization.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Notice the aspects and the reasons for knuth's "premature optimization". Is it making the code harder to debug and read? Is it a non-critical path?
If an optimization doesn't impact readability or debugability (for example, picking a datastructure that fits the problem instead of just using a List for everything). Then you should do it.
I see the quote so often pulled by people that want to justify inserting a n^2 algorithm when a log(n) solution is either the same amount of code or 1 line extra.
There's also important context about the era knuth was programming in. Optimization in the era of knuth was targeting the hardware and tickling things like the CPU cache and memory in a very specific way. It was things like clever bit manipulation and packing to save memory. That's the context. In modern terms it'd be "don't use SIMD intrinsics until you know you need them". It wouldn't be "Don't think about algorithmic complexity" which is where I most often see that kludge deployed.
The point of these low/zero overhead languages like Rust is you're in an environment where memory management is ultra critical. The dotnet garbage collector does more than a good enough job for a weather app, likely a much better one than vibe coded .clone() Rust
The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.
The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.
Now extrapolate on all windows included apps and ui elements.
How much would that cost per license?
This argument applies regardless of how you feel about vibecoding. Lately people have been asking for x64 machine language and getting reasonable results.
BigCo apps will take up lots of space and memory for BigCo reasons - obviously less if it's in Rust vs Go vs Python, but you could easily write Go apps that use far less memory than Rust apps written at BigCo due to BigCo reasons.
It's just not really that much of a priority for them to have their weather app use less than 1GB of memory. It's a far bigger priority for someone to insist that somebody else uses some bloated framework so they can get promoted.
This is really only possible because I told Fable to build the underlying allocation-free HTTP, JSON, etc libraries and consequently I'm not building anything serious yet (although the libraries are well-tested using pre-existing corpuses from reputable projects e.g. curl as well as fuzz tested).
Most "outputs" are passed as out parameters for the function to fill in, and results are Rust-like enums (a Go tagged union containing only small data). I could also have returned (T, error) but I would have to take care that the thing I pushed into the error argument doesn't allocate--not sure if I made the right decision or not, but for now it feels nice. The worst part is that I don't really have a good way to communicate detailed error information, but that hasn't bitten me yet.
This has also been a lot less effort than writing Rust, although Rust would have real checks for lifetimes and im/mutable and enum exhaustiveness and so on--so far I haven't been bitten, and I suspect things like enum exhaustiveness can be addressed via linter if necessary.
I have never written such Go, but as an experienced Rust programmer I can tell you Rust is not hard to write after learning it. Learning it can take more time than usual (although there is also contrary evidence, e.g. from Google) but after you're used to it, you're basically as proficient as in other languages, except some glitches (that can be expensive - rewriting your main structure, but are fortunately rare). Considering the effort involved in coding in such unnatural Go variant, I tend to believe it is far easier to code in Rust (including coding in Rust using this style, since it is more suited to it).
Of course, if you're just vibe coding everything, maybe it is easier because maybe the LLMs write such Go better that they write Rust. But if you're not, even if you're only reviewing the code, I believe it's easier to review Rust code than to review such Go code (and potentially than reviewing any Go code, but that is a different matter).
I don't mind writing Rust (have been dabbling with it since ~2014), especially with some AI assistance. It's just more of a grind for me than working with Go.
> Considering the effort involved in coding in such unnatural Go variant,
I was also expecting writing Go in this style to be more friction, but it was surprisingly smooth. The friction was entirely from lack of libraries and a little uncertainty about how to communicate errors without allocating. Rust has better libraries by far, but I felt more friction from the language (e.g., if you have a buffer you have to initialize every element of it or you have to use something like `heapless::Vec`--not a big deal, just decisions to make to figure out what the happy path is).
You'd get most of the benefits of Go and Rust.
It is essentially an entire Chromium instance around msn.com/weather.
Hilarious that the article is like "Apple's weather app is only 200MB!"
The day that OS vendors started abandoning native apps was a hilarious day.
For the same reason a Rust frontend is being developed for GCC.
https://github.com/fractalfir/rustc_codegen_clr
The year was 2002, VB6 had just been retired for VB.NET which had 0 backward compatibility.
And then we all became Flash/AS3 developers.
The End
I'd be curious to know whether Rust developers believe Visual Studio is the right place for Microsoft to invest Rust specific coding capabilities.
I'd argue that the former is less important than the latter, and my understanding is that Visual Studio is still the IDE for Windows-centric development, so for those MS-first developers, Rust missing from VS means Rust is poorly supported, end of story.
WSL is really nice, as is Windows Terminal. I particularly love its fonts (but that's probably just me).
If they can replicate that capability, I think it can be a draw.
I was a mac / Linux guy before my current gig, but Visual Studio is so much more capable than XCode that I basically only use the Windows machine except to debug mac-specific issues. Less so, now, admittedly, that the malware scanner process is literally always pegging a CPU core.
The alternative being macOS, if Apple actually had competitive prices for all kinds of world economies.
Regardless of how evil gigantic companies can be, or what the ideal world should look like: from a pure usability perspective, windows is top of the list.
If I got 5$ every time a linux/mac enthousiasts has to tell me they just cannot run something, and proposing a myriad of workarounds to stick to their ideology, I could buy an apple vision pro and let it collect dust in the corner of my basement.
I would argue against the idea that it's the default for most enterprise dev. What you refer to as creative/web culture I would refer to as a newer generation of enterprise dev written in (I know) JS, TS, Electron etc. There is a lot of cross platform stuff out there, at least for clients, and Linux has taken up a lot of ground in the server market as well.
With CAD and GPU programming you have a point - proprietary drivers written for Windows has more technical sticking power.
I guess my feeling is that, especially with all the headlines saying European countries will move away from American software giants, Windows seems less attractive as a long term target for investing my time. Not to mention it's buggy and slow these days.
For us to actually move away, European countries need to be willing to fully support the whole programming stack, and hardware.
Because of coding agents? :D
That's an excuse, not the reason.
IntelliJ RustRover has been around for years.
Similarly, VS Code has had Rust plugins written by the community in their spare time years ago.
I don't think this is a hot take, but I'm predicting Microsoft will gradually phase out Visual Studio in favor of VS Code.
Yeah, I know that it can read Visual Studio Projects and Solutions but these are kludges. It's essentially a souped-up file editor.
( Edit: I should probably inform the layperson: It was Visual Studio 2022 )
And for all we know, it might be officially supported in their internal builds of Visual Studio.
> BuildXL has also been proven to scale to large codebases (e.g., Windows/Office repositories) where builds can consist of millions of processes with terabytes of outputs
BuildXL is also NOT compatible with VS and they have no plans to make it so. from the readme in the repo: https://github.com/microsoft/BuildXL
> There are currently no plans to integrate it into Visual Studio.
Also the use of italics there is rather jarring.
windows-rs
> We are running different workloads including rustc perf suite. In general the runtime performance is on par with llvm.
Not what I would've expected!
We rewrote everything a few years back, completing in 2014 (Rust 1.0 came in 2015) - it costs nearly a billion dollars! I cannot in good conscience go back to management and ask for another billion dollars to rewrite again (Rust might be more productive, but inflation will eat that up, so I expect a rewrite to be more expensive). If Rust can work with my existing code though - I know of a number of small places where there is reason to rewrite anyway because the code is bad (or sometimes was good but not nicely flexible for the features we have added since).
Things that wouldn't be worth your time before are trivial these days with LLMs.
Grok immediately answered without a second thought.
Anyway, even if that were true, rewrites are becoming drastically cheaper, simpler, and more correct with AI. The Bun rewrite is the largest experiment and seems to be 5-10x cheaper and completed ~100x faster and these costs are likely to come down further. So your claimed $1B rewrite today costs $100M and carries less risk. In 5 years it'll probably cost at most $10M and be finished drastically more quickly. And the vast majority of software doesn't cost $1B to translate.
It seems suspect to me is all; the repayment time on $1B from a rewrite of an existing software stack isn't generally huge unless it also enabled adding new features that weren't possible before which enabled significant new revenue streams that justify that $1B outlay.
And that 90% could be an underestimate here.
(but yes, the language team and ecosystem were always making a point of incremental addition rather than full rewrite)