The Adoption of Rust in Business
rustmagazine.org
rustmagazine.org
The product works great, but the codebase is around 400k LOC of Rust, and we don't have any budget to hire Rust developers. And when we had a budget in November, it was really hard to find anyone local (work requires a high security clearance, and remote is not possible for this kind of work due to said security issues).
So we're kind of stuck with just keeping it around until better times, or just re-writing the entire back-end in something we know better. Not to sound like a downer, just an example of what Rust adaption could look like from the other side.
Most of what I learn ends up being throw-away, done out of necessity. However, I feel like something written in a popular and growing language like Rust, with an opportunity to learn, maintain, change and improve, would be a net positive.
I'm biased because I learnt Rust in ~2018 and have enjoyed it, however if this were say Scala or Go before I learnt them, I'd feel the same way.
Yesterday I was in a jam session with a colleague, we prototyped something quick and dirty, got it to work, and then refactored it into something neat and clean. This was such a pleasure, because I feel like the language empowers me to make large refactors mostly without introducing breakages (at least when you're shuffling code and types around).
This is how I've learned most things in my career :D
For something like Rust (or other languages like go or objc) though, I could see how it would be hard for someone whose only background is in js or python. There are concepts completely missing or hidden from the programmer that they now have to deal with.
As someone who has trained several Rust programmers, I've seen people hit two major snags:
- Like TypeScript, Rust is a strongly-typed language that gently encourages functional programming.
- Like C/C++, Rust is a language where you need to know about references vs values, and the stack vs the heap.
Someone who's comfortable in TypeScript and C++ will often take to Rust like a duck to water. But someone who's never called "map" or who has never worked with pointers may take longer. A pure C programmer might struggle as much as pure Python programmer, just from the opposite direction.
That said, I love Rust precisely because it allows me to move between a TypeScript mindset and a C mindset as needed. When I want something fast, solid, correct and easy to maintain, it's my favorite tool. But for many team projects, Rust is overkill—garbage collected languages are often perfectly affordable. And there are many excellent choices!
I was always surprised when people said rust had a steep learning curve, yet it seemed relatively easy to pick up to me.
My first language in school was C++ and my first language on the job was Typescript, exactly as you described. I knew both well and then heard about rust and tried it.
When I wrote my comment I was thinking way back to when I was in undergrad and pointers were a huge stumbling block for many. Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging.
That's not say people can't learn, I'm just thinking about how long it takes someone to get up to speed.
To be clear, safe Rust doesn't actually have pointers. (Well, it does, but only unsafe Rust can dereference them.)
But Rust does have pass by value and pass by reference. It has both stack allocation and heap allocation. And it has a notion of who "owns" something. These aren't technically pointers, but taken together, they're basically a safe interface to doing "pointer stuff." Conceptually, all these ideas should make sense to anyone who has worked with pointers and allocation.
Similarly, Rust allows easy mutable state as long as only one piece of code can see the mutation happen. But many programmers are used to being able to share mutable state between widely separated bits of code. And this affects how you design the architecture of your program! Anyone who has done functional programming will see the implications of this early: "Oh, I need build my architecture around immutable state!" So something like an old-school game engine where any entity can update any other entity is a huge headache in Rust. But a game architecture like ECS that carefully restricts mutation (like Bevy) works beautifully with in Rust.
I don't want to trivialize this: Pointer stuff and mostly-functional architectures are both real skills that take time to learn. Rust is amazing for situations where you feel torn between TypeScript and C/C++. But lots of projects just need a nice GCed language and a good standard library, and Rust wouldn't be the right choice for many teams.
That said I don’t get what you meant by knowing about the stack vs heap in Rust. I’m not from C++ land so maybe this flew over my head, could you elaborate?
Rust was probably also a lot easier to learn pre-async-await, because one would have to explicitly opt in to multithreading through std::thread.
My first productive language was JavaScript via NodeJS (I learned PHP first, but it was a mess). I did so much with it that by the time I learnt other languages on my own, it was out of necessity.
From a language syntax and concept angle, I'd say Java + Scala were difficult to grok at first. Java for the boilerplate, Scala because I could never understand what the underscore is for.
Kotlin became a breeze and pleasure, then Rust after that. I learnt each language by converting my projects from a previous language to a new one. So that helped me limit the concepts I'd introduce.
Mostly do some calcs, interact with a DB and expose stuff via gRPC. By the time I started with futures, channels and threads, I had gotten far enough programming against a single core.
I often advise people starting out to be gentle with themselves and stick to what they know first. Like other complex languages, one might remain a learner for very long.
Worse, you can use both in the same program, which, while safe, is really complicated.
There's a lot to be said for Go's green threads for routine web back end stuff. They avoid the async/thread distinction, because they're both lightweight and can block.
Perhaps when one isn't trying to map some similar-ish knowledge onto Rust it becomes easier, as one doesn't have to drop preconceived notions.
This very much feels like the time I tried to snowboard after having skied for a couple of decades; why can't I move my feet like before?!
It seems to go one of two ways with C++ developers:
- Some C++ developers were alsready hyper aware of object lifetimes and were effectively enforcing Rust's constraints on their own code manually anyway. They find Rust the easiest of anyone
- Some C++ developers were blissfully unaware of object lifetimes and played fast and loose with them so long as it worked. Those C++ struggle with Rust more even those with no previous low-level experience.
> There are so many things I want to do in Rust when mapping from my C++ knowledge
As someone who came to Rust from JavaScript, I can attest that with a few exceptions the opposite is true for JS knowledge: basically everything I was used to being to do from JavaScript I can do in Rust.
The underlying issue with this kind of informal assurance is that it may become incorrect in a large-scale project as it evolves. This is why "unsafe" in Rust is best used locally, as part of something that provides a safe interface to the rest of the code.
Just like there are plenty of idioms you can use in Haskell that are easy to make simple that Rust will make a nightmare to implement.
At the end of the day, Rust is neither of those. It is a safe low level language, and that comes with plenty of restrictions. The language is amazing for how little restrictions it actually has when compared to a naive estimate, but there are still plenty of them.
Like? I know double linked lists and graphs are harder to get right, but aren't impossible.
But on the flip side getting Optional and Send/Sync to work in C/C++ and not to rely on people using best practices is downright impossible.
Hence the part about learning.
I feel like it would take another week or two to learn some of the UnsafeCell/Pin/Generators type stuff, but none of that is needed for 95%+ of Rust code.
I think if you and your team just started learning Rust week by week, you'd find in 3 weeks that you're equally productive in Rust than your current languages. Especially given the code base already exists. Even just starting to learn Rust by writing tests (if there aren't) would be sufficient to improve that system rather than wait to hire or re-write it.
It took me probably more like 1-2 months to really understand how to code in Rust. I do not think a typical team of JS/Python devs would be productive in 3 weeks. I think it would be more like 3 months. Developers with C++ experience seem to pick it up much quicker.
Also, at this point I’m pretty proficient in rust but I’m still far slower than I would be in a scripting language. So I don’t think anyone would ever reach “equally productive” unless they’re comparing themselves to another compiled language.
I like Rust, but it’s challenging, and it’s certainly not a language for rapid development.
This is actually a very fast learning curve. Imagine a typical Python/JS developer becoming proficient with real, production-quality C++ in 3 months? The very notion seems ludicrous to even think about. So the Rust folks are not wrong when they point out that Rust is about empowering developers and enabling higher quality software across the board.
Our very first Rust project (to learn the language) was a path tracer that was done (fully functional) in 2 weeks. I doubt it would take a team 3 months to become productive in Rust. There's always more to learn, but "being productive" is quite a low bar if they already know basic programming concepts.
With that said, "typical JS/Python devs" might not even know said basic programming concepts, so maybe you're talking about those? Regardless, 3 months is an extremely conservative estimate.
-Emily
If Python / JS is all they've ever used they most likely have gaping holes in regards to many general concepts of computing and some might not be able to grasp those for a loooong time.
"If it compiles it works" happens often to me, which is why I'm such a fanboy.
For this reason I'd be much more comfortable jumping into an unknown Rust code base than anything else.
Rust also promotes simple control flow and acyclic data structures by making writing complex control flow and cyclic data structures extremely hard. Its tpe system is also very explicit about who owns what and about sharing.
Imagine you see the following Python function for the first time:
def foo(x: Bar):
foobarize(x)
In Rust if you encounter:
fn foo(x: Bar) {
foobarize(x);
}
It's a very compelling thing about Rust that problematic designs are clearly marked with boilerplate, so you know exactly what to look for and perhaps refactor. There isn't really a close equivalent to this in other languages, e.g. in C++, the "modern" facilities you're supposed to use have the heaviest syntax, and this is often true in Python, Ruby, JS etc.
You're right... but just to add.
In any Enterprise project involves a lot of talking to other systems(think Salesforce, Netsuite, Slack) or implementing existing protocols(SAML, OAuth,LDAP) and other such things. Python being popular for very long means there's prior work in almost every area. I believe this can be one definition of "productive", basically re-using something existing and spend your time on other better things. In a lot of the same projects performance at the CPU level might not be a bottleneck because you're stuck waiting 10 seconds for an API call to Salesforce.
I'm more excited about PyO3 and other Python+Rust advances, where it seems you can offload lot of CPU intensive stuff to Rust but keep the Python layer and its ecosystem.
Of course in most projects one or the other usage dominates so my glib response isn't particularly compelling, but in my current project we do use a similar amount of both.
But we still have some Python Django code and will probably end up with C in driver code.
For a backend webservice prototype, that's probably true. It's not true for everything, though. Especially if there are performance requirements or you need to handle errors properly.
I've found Rust to be extremely productive for implementating interpreters, for example, thanks in no small part to algebraic data types and pattern matching. It's not quite as ergonomic as Haskell/OCaml, since you can't currently match under Box's, but hopefully that feature will get stabilized soonish.
I also have used it for computationally intensive apps, such as a poker odds calculator. Going from a single threaded ~24 hr runtime to a ~15 min runtime on 96 vCPU took a few minutes, thanks to rayon. Of course C/C++ with openmp loop annotations is similarly quick for trivially parallel problems, but Rust's built in unit testing and package management make me far more productive for things like this than in C/C++.
The reason is most things are immutable. Frankly I’m just not used to writing code in that way (even though most of my scripting code is functional and not imperative). I find that when I refactor my Rust it requires significant work.
In mutable code I can just modify a class/struct when something needs to change but when it’s mostly immutable those changes often require significant redesigns.
Perhaps this is just because I’m new to Rust, but that’s just proving my point that it’s hard. I’m better setup to learn a new language than the majority of programmers for sure and it’s been a real struggle.
At this point I would probably be struggling as much in a language like Haskell I suspect. My issue isn’t the borrow checker, it’s immutability.
You do have to explicitly declare them mutable, though, and will warn you if you have a mutable variable that you never mutate. This is helpful for avoiding surprises.
Scale up a bit, and you end up with far fewer (often zero) subtle bugs when other people change other parts of the codebase, or when you do a significant refactor - some of these being the kinds of bugs that are difficult to test for.
I would call that "more productive", personally.
This completely ignores domain / logic /algorithmic errors which in my experience completely dwarf types of errors Rust is supposed to take care of.
On the other hand, Google reports that "to date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." Source: https://security.googleblog.com/2022/12/memory-safe-language...
But overall I agree: you need tests for business logic.
Another thing that Rust gets right is that you're incentivised to write some tests right in the same file where you're writing the implementation (it just works out of the box with cargo test), so even complex logic is easy to test out.
You don't have to go through the "oh, let me setup mocha to add a test... never mind I won't bother right now"
I assume this goes for scripting languages with weak / no typing.
>"You don't have to go through the "oh, let me setup mocha to add a test... never mind I won't bother right now""
Same thing.
So learn Rust? You've already said the product works great so it doesn't seem like a reasonable rewrite candidate.
The vast majority of software doesn't need to be super cutting edge, doesn't do anything particularly difficult, and isn't written by geniuses. Honestly, any developer worth being hired should also be good enough to pick up another language during the work day over the course of a few months.
Rust in particular has a bit of a learning curve, I'll give you that (so I've heard, I don't know it well enough to write production code in it). But "it's hard" doesn't seem like a particularly good reason to throw out a perfectly good 400k line codebase.
I do sympathize with agency's situation—I have actually put Rust into production and been responsible for mentoring programmers to work on it. I like Rust! But I almost certainly wouldn't have chosen Rust for a government production system without making sure that all the stakeholders understood the tradeoffs. Although, it sounds like this was an abandoned R&D prototype that was voluntarily picked up by another team, so I don't necessarily blame anyone involved here.
It’s one thing if we are talking about a Dilbert-level “we are going to rewrite our system in X” but learning something new to support an existing system that performs well? At worst it’s good resume material and at best it should be interesting enough to expand how you think about coding.
Not wanting to learn it at all would be odd.
I’m just not sure how often it’s worth the effort, compared with the runtime cost of GC and immutability or mutexes.
This is not a great starting point for any project, never mind the programming language. It could've been C++ enthusiasts, or Haskell, Scala, Lisp or any other language that appeals to enthusiastic programmers.
I've recently been involved in two projects with the same problem - initially developed by a small team of enthusiast level programmers in language X (not Rust). Other people in the team (competent programmers) have trouble being productive as the enthusiasts had gone to the deep end with language features which were not strictly necessary to complete the task at hand.
Complete absence of dependency management and a myriad of incompatible build tools is a "better story"?
You can have this "story" in Rust by just disabling crates.io centralized registry. Which still leaves you in a better position than C++ because you can use the build tool and dependency management locally and do whatever you're used to doing in C++ land (put 3rd party code in your repo, install them via some other packaging tool etc). Or if you insist on going the whole way, you can invoke rustc via your favorite flavor of make.
On a more realistic note, if you're working with in a very safety/security conscious environment, and still depend on 3rd party code: you could set up your local package registry and have people vet the 3rd party dependencies. Yes, it costs time and money but at least you get the tools to do it from the language ecosystem.
I've been professionally involved with the C/C++ way of doing things for decades and I find the Rust build and dependency management tooling a huge improvement.
Maybe others should do more that just ship compiler + linker.
Maybe training a C/C++ developer in Rust is an option for you? Of course it's not a language you get fluent in in a single weekend, but Rust also isn't extraordinarily complex.
The biggest thing you need to unlearn is the paranoia.
If I did it myself in another language which also has a ton of libraries (eg C++, Java, Go, etc.), there is no reason why I would want to reach for a library for that piece of code in Rust. There's usually a good reason why I didn't use a library.
The convenience of npm and cargo is offset by the fact that the documentation for most libraries is nonexistent, the creators inject their idiosyncrasies, and lots of library code has not actually been tested very well. Not to mention that the dependencies can change for the worse underneath you, and if you want the old features you had, you have to give up all new developments.
It's called Single Ownership.
You can be inefficient with Rust as well.
The good thing is that you're less likely to get a null pointer or other silly mistakes / security incidents waiting to happen.
I think any senior level developer with C++ experience should have no problems grasping Rust on their own. Examples and docs are plentiful.
I recommend rustlings for interactive tutorials to do alongside the rust programming language book. I also just heard a rustacean station episode featuring a pakt author who wrote “ Rust Web Programming” it sounded good.
From the organization POV, yeah that sucks
I started with Ruby. Since then, I've branched out to a bunch more, including Rust. Most are fairly easy to pick up.
There is, however, a class of languages I'm totally scared to try and pick up. They're C, C++, and PHP. It's not because they're bad languages, or I couldn't learn them - it's just that all those languages have a reputation for making security holes easy by default. There will be a learning curve where I'm an actively dangerous programmer to be around. I'm gonna just stay away.
If I started with C++, and not Ruby - my perspective would be quite different. I would assume there are dangerous footguns lurking in every other language as well. Learning any language would be a scary thing.
I would try to learn Rust. Its compiler won't prevent every bug or hole, but it's hard to screw things up as you're learning. There's really only one rule, to avoid using unsafe unless you really can be intentional about what you're doing. If it's uncertainty that keeps you from learning - most languages are far more forgiving than what you're used to. And if not, none of these points apply, I guess.
That's what you get with hype-driven development.
400.000 lines also sounds huge for a web project.
Contrary to other commenters I don’t advise learning Rust just for this project. In general maybe it’s worth it, but web Rust is new, has an uncertain future and likely no job market value. If it was a research project there’s no telling what horrors lie in that code base :-)
I maintain a 180k+ line of code back-end web project and I use Rust. Best decision I've ever made.
I serve over half a millions of HTTPS requests per day. Everything hits the backend, no CDNs or caches of any kind. Average CPU usage on a cheap VPS? ~3%. Hugs of death? No such thing for me. It just runs itself without any supervision for months uninterrupted, so I can sleep at night and not get woken up by an outage. And refactoring is a breeze due to a strong type system, plus all other niceties that Rust has.
So for a complex project that you're going to maintain long-term? Rust is absolutely the right choice, even for backend web-dev. A throwaway CRUD e-commerce website made by a random webdev consulting company on the cheap? Okay, yeah, maybe here you're right, and I probably wouldn't pick Rust there either.
My concern regarding web Rust is focused on long-term viability and development speed, not performance which is a given or memory safety which is a standard in webdev.
(But of course, I'm not saying this is how everyone should do it. I'm just saying what the benefits are for me because Rust's so fast, so it allows me in my particular case to do this, which I wouldn't be able to do with e.g. Ruby because it'd be too slow.)
At a high level, what does the codebase do that it took 400k LOC? CRUD REST endpoints? /s
How long did it take how many engineers to end up with 400k LOC codebase?
Rust is a hot language and there have been many big tech layoffs. Maybe some Rust or C++ developers would now be interested, even at a market discount, to use or learn Rust professionally?
Rust might be okay but even Python I would hesitate. I and my team all converted quickly to being efficient java+js+C# devs coming from either of each and I cant imagine working in a company when not only the business and the tools are particular, but the frigging language as well. It's overloading for new comers.
And imagine in 20 years, which is the age of the software I maintain: you d rather fight a Java or C# spaggheti or a Rust spaggheti ? It will be a spaggheti, you can't escape it and last 20 years being profitable.
These languages are not even on the same spectrum.
-Emily
To increase rust adoption you need to cultivate FOMO - create an aura of "rust is a secret weapon", which it is in certain cases (safety critical performant code).
Rust isn't really meant for prototypes. So don't expect Rust adoption to be in the range of Python or JS/TS. Expect it to max out in C++/Java adoption.
It needs a champion web framework like django, rails, or phoenix. Don't give adopters an overabundance of choice, or they'll recoil.
It already has a better packager than most languages.
If Rust shows that its 10x better than Java and C++ in terms of productivity - it will have no problem getting adoption. Just need more promotion on how much easier it is to work with than C++
Rust is a gorgeous language and I love it, but it optimizes for making good binaries over being easy to learn and use. Java shops don’t use Java because it’s clever, clean or fast. They use Java because it’s a known quantity, it works, it’ll outlive everyone and it’s easy to hire for. Java is popular precisely because it’s not new or shiny. Because there isn’t a new framework every week that you need to learn to stay on top of things. Java is a language for late adopters, who said no to Scala, Clojure and Kotlin. Why would they switch to rust?
If rust displaces anything it’ll be systems languages - C and C++ in web browsers, databases, Linux, embedded systems and some video games. And safety critical systems like helicopter control systems. It remains to be seen if it makes any serious inroads in web services. I can still throw web services together in nodejs dozens of times faster than I can in rust.
Rust isn’t trying to be the world’s most productive language. Rust would rather complex syntax and fast binaries than simple syntax and slow binaries. So it’ll always be harder to learn than Go, Java, C# or Swift. I honestly think Swift - if it had rust’s tooling and ecosystem - is a better language for general purpose computing.
Rust is a lovely language, but like every other language, it’s no magic bullet. Add it to your toolbox, but don’t throw out your other tools.
After tackling the refactoring of a complex Rails app that has a rules processing engine implemented on top of ActiveRecord, the true cost of Ruby's lack of static typing has become apparent to me. It's clear now that you can get a web app up and running quickly in a framework like Rails (as one example of a convenient, low-friction framework). But once you need to turn it inside out and make significant changes to the implementation, you're walking on egg shells and relying on previous devs to have built out good test coverage. A web app written in Rust would be easier to refactor in important ways at this point in the life of the app. It is clear there was a cost to using Ruby, but also that it was deferred.
C++ and Java don't overlap much in the domains they're used in in my experience. Rust may totally replace C++, where the memory safety issue exists and high performance is critical.
I do agree that Rust is prone into displacing C (and very simple C++, any C++ that needs the ++ part was already displaced by now), but I do think it will make inroads into plenty of places it shouldn't be. That's because the foundational tools will get written in it, and this leads people into consuming those tools in Rust code too, to avoid incompatibilities.
As I've said before, Go is more appropriate than Rust for web back end work. The libraries are well debugged, because Google uses them internally. The "goroutine" approach gets rid of the thread/async problem. Garbage collection means not having to think too much about memory management.
Rust is harder. I write mostly in Rust (36,000 lines in the last two years) but for something hard, a high-performance metaverse client. It's overkill for your shopping cart.
(I suspect that the next generation of "champion web framework" will be something that you talk to in English and it generates routine web front and back ends. Probably as a service.)
Not sure we will ever see a "rails" like framework in Rust (for the better IMO)
And yet where I live, it has extremely minimal adoption. There’s more rust jobs at panel beaters than doing software development.
Rust has to fix itself or remain popular but essentially unused.
But sticking to “battle tested” means a local minima at times. For example, there’s no shortage of CVEs in OpenSSL’s past or future. It’s definitely “battle tested”. And yet, that doesn’t mean someone shouldn’t try to write something better.
It may be a good idea to replace, or not. We don't have enough data to decide.
Even if Rust wasn't able to eliminate whole swath of errors in C(++). And it is (Nulls and data races).
Rust has way better package manager, and actually works on Windows.
For example coreutils got rewritten in Rust. And got adopted by Yocto.
> community of competing package managers is a lateral, neither better nor worse.
While I understand your position, that's not my opinion. Having one way to build a package is a blessing. Having had to juggle Python's competitive package manager is a nightmare.
https://imgs.xkcd.com/comics/python_environment_2x.png
Each one has slightly different usages and they are mostly compatible but then you run into edge cases.
-----
And lack of blessed libs is something I am strongly against.
Rust doesn't have standardized time lib and everyone is suffering for it.
- 9.3% of respondents use Rust (#14)
- 87% of respondents who already use Rust would like to continue using Rust. (Most loved)
- 17.6% of respondents who don’t already use Rust would like to try out Rust (Most wanted)
While I generally agree with the sentiment that Rust can, should and probably will improve I don’t see the survey results or your anecdotal experience as cause for alarm.
It’s far from the most popular language (JS 65%) or most popular language without a runtime (C++ 22.5%). But that’s fine because it’s relatively new. The survey indicators a big appetite for trying out Rust among developers who haven’t tried it out already, indicating that the language could continue to grow in popularity.
It would not be an exaggeration to say that most of the C++ you use today is about the same age as Rust.
- Most C++ projects are not greenfield, and C++ programmers are often working with 10-20 years of cruft in their codebases.
- Most of those codebases are also somewhat object-oriented, and thereby tained with "enterprise Javaness."
- C++ has a number of high-profile detractors who are well-liked in the programming world, like Linus Torvalds and (in this sphere) Bryan Cantrill. Most of these detractors haven't touched C++ in 15-20 years and are still railing against the monstrosity that was C++03 and the thickness of the C++ spec (without actually using it).
- C++ is widely used, and often not in places where it is appropriate or useful. When people use something, they see its rough edges.
- C++ isn't "cool" in programming spheres.
Keep in mind that C++ standard is backwards compatible, so every monstrosity added is still there. You might not use it, but your (ex-)colleagues might have, and you might end up maintaining such code. Let's just say it doesn't exactly make it more appealing.
Now, I am not a C++ dev, but how much effort would it be for a team to pick up C++ 20 if they only had worked with was C++ 11?
The functional programming parts and expansion of compile-time metaprogramming (constexpr/templates) are probably the biggest new features, but you probably aren't going to use the more complex parts.
IMO the biggest changes in ergonomics for application writers are:
* better iterator-based algorithms and iterators becoming more powerful than indexes and pointers
* new helper objects like string_view that let you work more efficiently
* functional programming and passing lambdas around is possible
* "override void foo() const noexcept { ... }" - all the extra keywords (override, const, and noexcept) help you with correctness
It's a chicken and egg problem.
More often than not the _perceived_ problem is not performance or memory safety.
As opposed to Rust?
Amazon, Microsoft, Google, Dropbox, Cloudflare, Meta. This is a list of companies I could think of quickly, that don't just "use Rust" they are "heavily invested in Rust".
If this isn't "massive industry adoption", its not clear what is.
A) Get lucky.
B) Be the only choice.
C) Get a massive corporation to back you.
Otherwise you can't ride the network effect to the fullest.
Companies need people to maintain codebases that were started 20 years ago, this is simply not the case for Rust.
This only indicates the huge bias in the voting crowd.
We've also tried the open source GCP client libraries, but they were huge didn't support async at the time.
(Still, I'm much happier hand-rolling some HTTP wrappers than using the official Google Python bindings. Those pull in tons of fragile dependencies.)
You are hand-rolling HTTP wrappers though, so I think we have slightly different perspectives :)
Edit: you have answered that in https://news.ycombinator.com/item?id=34612364
original markdown version:
https://github.com/RustMagazine/rustmagazine/blob/main/conte...
---------------
And check the Github issues:
https://github.com/RustMagazine/rustmagazine/issues
check:
- Call for editors #4
- Call for articles #5
"In 2016, Meta (formerly Facebook) adopted Rust as its “new secure programming language for blockchain”"
C++ has a legendary ecosystem, and many great modern language features for writing safe maintainable code, but the antiquated approach to header files makes it painful to learn and unproductive.
I'm not expecting C++ to go away, and in fact I actually like working in both C++ and Rust (though prefer Rust) so don't much care. But I don't think the addition of modules is going to lead to a resurgence in the language overall.
And the big win IMO is just that it makes it easier to get a MVP off the ground, whether or not it is backed by module-compatible external libraries. The C++ dependency/build story is not that miserable nowadays with modern CMake, git submodules, vcpkg, etc.
C might survive Rust?, but I think C++ is toast.
Made available on CUDA by NVidia?
Made available on Playstation SDK by Sony?
Made available on HPC clusters and compiler toolchains by the respective research labs?
There so many use cases for C++ that Rust still doesn't have a sound story as replacement.