Swift is well-designed but is virtually non-existent outside of Apple platforms, so it doesn't have nearly the third-party ecosystem that Rust does. Go has the third-party ecosystem but is poorly designed and doesn't have basic language features like sum types.
Rust is likely the best combination of thought-out design and ecosystem support that exists in a programming language today.
Interestingly, Microsoft is also pushing Rust quite hard with special API packages, tutorials, and even some IDE integration. Windows tools are often closed source, though, so you'll probably never notice it if your favourite tool uses Rust or not.
What IDE integration? VSCode plugins aren't done by Microsoft, finally they got a spot on MSDN docs as of last VSCode release.
Currently there are no plans for proper VS tooling on par with C++ across all Windows development workloads.
If you mean Rust/WinRT, the new toy from the folks that produced C++/WinRT, after they successfully managed to kill C++/CX and turn the UWP development experience back to the glory days of Visual C++ 6.0 with ATL 3.0 (apparently very dear to their hearts), then it isn't something I look forward to ever use, if C++/WinRT is any indication of their understanding about developer productivity.
Or do you mean the Azure Sphere OS, with the whole security marketing sales pitch while have a C only SDK available, and only now evaluating if Rust is something they would support in addition to C.
First, it's now called Rust for Windows (or windows-rs), because the scope has expanded to include (fairly low-level) bindings for all the Win32 and COM APIs in the Windows SDK.
I strongly object to calling it a toy just because it doesn't have certain RAD conveniences. I'm happily using that crate (though currently only the Win32/COM portion) in the native parts of a Windows app I'm working on [1]. Yes, I have to use a lot of unsafe when working with the Win32 and COM APIs, but I keep my unsafe blocks as small as possible, and try to do as much as possible using safe Rust abstractions like slices and the various string types.
FWIW, windows-rs recently removed the bindings for the Windows.UI.Xaml namespace, on the grounds that they were nearly unusable, and because the in-box Windows.UI.Xaml is no longer Microsoft's recommendation for app developers. I think the latter policy is a mistake, because some of us actually want to produce something with a minimal memory footprint, using a GUI toolkit that's already in the working set on all Windows machines. But maybe someone can bring back Windows.UI.Xaml bindings in a separate crate.
> they successfully managed to kill C++/CX
IMO C++/CX was a mistake. It was an attempt to make C++ into something it was not. From what I've read [2], C++/CX spectacularly failed to uphold C++'s zero-overhead principle, and the code size of newer shell components in Windows 10+ suffered as a result. Yes, I felt some of the frustration of working with the current (or at least, mid-2020) tooling for C++/WinRT when I was mentoring an intern on the Windows accessibility team at Microsoft (which I left later that year). But I think the Windows developer platform team had to do what was right for runtime efficiency. Developers who value rapid development over runtime efficiency can still use C#.
> the glory days of Visual C++ 6.0 with ATL 3.0
They were glorious, for code footprint. But like you, I wouldn't want to write new code using ATL (and on the Windows accessibility team at Microsoft, we avoided that as much as practical). Luckily, C++/WinRT is a big improvement over ATL, thanks to modern C++. It's just a step backward from C++/CX for some RAD conveniences that were really a better fit for a language like C#.
And to bring it back to Rust, I think Rust's macro system allows for some powerful high-level tooling on top of the WinRT bindings. For example, I think we could have a macro-based DSL for succinctly declaring a tree of UI elements, and that syntax could be more integrated with the rest of the language than the markup/code dichotomy that was introduced with WPF. Such tooling could also avoid the trap of boilerplate-heavy code generation that's typical of the Visual Studio wizards, and be available to developers who don't use VS.
[1]: The non-native part is using Electron. I'd love to write the whole thing in Rust, but Electron in general, and access to Chromium's full WebRTC stack in particular, is just too convenient.
A wall of text, ignoring that C# developers do have to use C++/WinRT, as not everything is exposed. I guess WinDev is too busy writing IDLs with notepad like tooling.
It is a toy when PAYING customers have to deal with that crap tooling versus C++/CX.
And all the Rust stuff is not "hard at work" as suggested by OP, when it is a small subset of Visual Studio has in the box for .NET languages and C++.
And we’re soon shipping Rust components to several hundred thousands of iOS (and Android, but it’s technically Linux) users at my day job, so there’s that.
As for Windows, I wouldn’t know, that’s your speciality.
But I’m pretty sure there is quite a sizable amount of VSCode users on Windows, all of whom are running a certain Rust utility written by the person you’re replying to.
That's what we call moving the goalposts. You clearly have something more specific in mind, so say that, instead of generalizing and making shit up.
I don't have an exact count, but my guess is that my software is deployed to millions of Windows workstations. That doesn't happen if Rust was "pretty much focused on Linux workloads, mostly."
You asserted with zero qualification: "Rust is also pretty much focused on Linux workloads, mostly."
Which is, like I said, bullshit. You asked for clarification, and you got some. They don't address your use cases, which is fine and fair to call out, but they very clearly show that there is a focus on Windows, contrary to your very broad claim.
Isn't Cloudflare using BoringTun in their Warp app? Rust might not yet be a good choice for the whole app, but IMO it's great for cross-platform non-UI code.
Rust is likely the best combination of thought-out design and ecosystem support that exists in a programming language today.