I'm curious about this as someone who is interested in making DIY smart home products as well as their recently announced Zigbee radio module.
But genuine question, is Rust ever going to catch on in the mainstream? It seems to have a bunch of nice to have features and great optimization. But the pick up, from what I've seen, has been less than stellar.
@work we do most of our new development in rust and did so since 2019, its quite a lot more than stellar than most other things we work(ed) with, and we had some interpreted dynamic and some compiled C stuff, its an improvement from either direction..
While at work I'm doing more software development I originally studied comp. eng. and dabbled around quite a bit with embedded systems, mainly in C, ASM and tinyOS with its nesC dialect+framework. Rust is a god send in lots of areas there too, you can establish zero-cost (well some compile cost, but zero runtime ones) contracts and static guarantees with the type systems, like disallowing that code that would produce a register pull up/down configuration with a short-circuit from happening, or shared access to resources can also be done in such ways. Check the respective chapter of the rust embedded book for more info:
> But genuine question, is Rust ever going to catch on in the mainstream? It seems to have a bunch of nice to have features and great optimization. But the pick up, from what I've seen, has been less than stellar.
I'm not sure where you've gotten that impression. Rust is mainstream at this point. All the big companies (e.g. FAAMG) are using Rust. Lots of large products are: Firefox of course, but also, parts of AWS, npm, VS Code, Android. And even key infrastructure products like Linux are looking at integrating it.
I think the key is that it's mainstream at the system/platform layer, not so much the application layer (though maybe one day!). Its benefits to the former are clear and undeniable; a paradigm-shift. Its benefits to the latter are pretty mixed by comparison. Anyone who mostly hangs out at the application-layer and doesn't follow this stuff closely could miss the adoption it's getting elsewhere.
I don’t see Rust becoming mainstream in the enterprise layer anytime soon. 90% or enterprise software consists of a REST API getting JSON payloads and saving them in a DB. The most complex part is often managing the “bus factor”, rather than some technical challenge. You often need just a bit more than VB6.
Rust requires a higher cognitive cost than C# or Python, but doesn’t provide massive improvements in the areas most relevant to enterprise developers (ORMs, JSON serialization, SDKs, etc…)
All of the areas you mention as relevant to enterprise developers are things that require libraries written, potentially with APIs that lean less in the "high performance" and more on "easy to use/hard to misuse", not fundamental changes to the existing language or tooling. I personally think that the big surprise with Rust will be how flexible it can be, covering a wider range of use cases than it might look at first.
Any company that does try to work with Rust today in any vertical slightly outside of what is considered "mainstream" will likely end up having to write their own libraries for things that are already available in other languages, but that's a factor of the ecosystem's age.
Though dependency management is quite easy to manage in rust (as with many high level languages) whereas I would argue dependency management isn't as simple in C/C++ which should boost library consumption and creation.
I know depending on boost or qt might be really easy, but the amount of different toolsets you must know to depend on randomlib is too damn high. I wish though that it doesn't end up like npm, I also hope there'll be some kind of "meta standard library" which integrates different mainstream building block libraries into something that's easy to consume coherently.
I consider most web-services - certainly glue code - to be at the "application layer". Of course these definitions are always fuzzy.
Which isn't to say Rust is never the right choice for those, it's just a more complicated question that's highly project-specific. Which is why it isn't mainstream there like it is in other places.
>Rust is mainstream
For sure it depends what you mean by mainstream. If a FAANG uses language X, it's language X mainstream?
I'd venture to say that to be considered mainstream a language has to at least pass 1% threshold in Tiobe index (or the equivalent in Redmonk or others).
If Rust is mainstream, then Fortran is über mainstream
I would argue that Fortran _is_ "über mainstream" - if you look at computing as a whole. It may not be used extensively for CRUD applications, but it is part of the bedrock of basically all computing. And there are some niches where it is the main/only language.
Rust will likely end up in a similar place - enormously useful in its niche, foundational for infrastructure outside, and with enough uptake and stability to make a career out of. I don't think anyone expects it to eclipse popular dynamic languages for web development, but it might make inroads on C and C++ in areas where active development is still needed.
The rankings in that index are highly suspect. It has Visual Basic at #6 and Classic Visual Basic as #11. Meanwhile Kotlin is down in position #38 and TypeScript at #46 beneath COBOL, PROLOG, Scratch and Logo!
I understand that it is very popular and is increasing adoption. But I was more targeting the embedded systems/hardware. Obviously this blog post is a step in that direction, but I'm still curious if hardware manufacturers will want to spend time adopting it.
> I'm still curious if hardware manufacturers will want to spend time adopting it.
The interesting thing I'm observing[0] is that embedded developers aren't wasting any time waiting for hardware manufacturers to do anything about Rust because they know manufacturers...well, let's express it as: "just don't care about software".
Bluntly, regardless of whether it's perfect or not, Rust is currently pretty much the only hope for devs who are desperate to move on from C for embedded work and if they have reverse engineer every last proprietary bitstream, protocol & application they will.
It's not just about the language itself (which depending on one's perspective has both pluses & minuses) but also the ecosystem/tooling (e.g. libraries with `no_std` support, build/test/doc systems, etc). (And, from my perspective, the community from which this has all grown--and why.)
Maybe it won't succeed but it won't be for lack of trying. :D
Also, one of the interesting aspects of Rust for me is how broad the domains of application are--using the same language from microcontroller level, through UEFI/firmware, OS, applications, & web is pretty appealing and leads to easier migration between domains.
In what space? If you're talking about embedded, it's going to be pretty slow for industry to start using rust en masse. There's a huge amount of inertia in embedded, and the developers are somewhat beholden to manufacturers to release tooling around rust.
In the software space, rust is being used by quite a few companies [0].
It may be true that manufacturers are ignoring Rust but that certainly does not stop or hinder me. Tools like svd2rust mean I only need to rely on the accuracy of their svd files (industry standard register maps) - see
https://github.com/rust-embedded/svd2rust
Additionally, I use vanilla VS Code and rust analyser so no need to use manufacturer supplied lock-in IDEs. There are many compiler targets to choose from for cross compilation and tools like probe-run to flash chips.
One major issue is lack of manufacturer provided code examples written in Rust. For that I rely on the Rust community. A typical example being nrf-hal for Nordic Bluetooth chips.
And honestly, I've been toying around with an Actix web server written in Rust, and the experience is not bad. As someone new to Rust, the main pain points have been along the lines of figuring out how to type a parameter to accept both a database pool and a database transaction (which turns out to be quite hard to figure out). Other than that kind of friction, the experience has been nice.
I think many people are trying to make Rust real deal and some of them make really good job. There was a guy who develops Linux ABI compatible kernel in rust, Tor is being rewritten in to Rust and some of the projects are just amazing.
I believe it will catch on as soon as people realize it's a C performance with modern syntax and memory safety mitigating most of the security flaws and bugs introduced by mismanaged memory.
I fell in love as soon as I saw descriptive scalar types like "i32".
Are there specific areas where you would expect to see greater adoption at this point on the curve? "Mainstream" adoption of a brand-new language takes time, and it's still early on the curve for Rust.
If anything, the hype-train might make it seem like it's a more mature ecosystem than it really is. The questions to ask are, what's causing the hype, and does the product deliver.
From what I've seen in my company there seems to be some resistance to rust due to it already having a lot of code written in other languages and them kinda of being the default go to choice.
RCG with 5 years as an intern. Now that I'm out of college, most of my projects have been minor features that take more time fighting an ancient windows GUI library than actually improving my programming skills. Any suggestions for finding work that will actually improve applications of the various algorithms(outside of grinding leetcode)
Recently did the same. I wish Obsidian had some of the nicer looking UI elements (such as editing a table without switching to markdown). I plan to stick with Obsidian for now, but am looking for something else since Obsidian is too limited(but the devs are great)
Surely you can see the difference between a company trying to change legislation and a company choosing its customers?
Even if you think that corporations should be allowed to influence legislation just as its individual employees can (if they are citizens), it's much easier to boycott a company whose policies you don't like than to boycott the laws of a government you don't like.
(In case the downvoters are incorrectly inferring my opinion on these matters, I should say that I'm not trying to make an argument in support of either corporate lobbying or corporate censorship).
"Hedge funds" generally aren't supposed to beat the market. They're supposed to do different to the market. That might be, for example, generally a bit worse but hugely better if the market suffers a catastrophic loss for a simple example.
