The organization (gov.) I work for recently took over a product where the entire back-end was written in Rust. Basically the product was developed by a bunch of Rust enthusiasts in a R&D group, and the product was wholly financed by gov. grants. When that money dried out, they were faced with either just shutting it down, or trying to sell or give the product away. Some higher-ups decided this could be a great internal tool, and got it for free.
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.
I feel like it took me 2 weekends to "learn Rust" enough to make feature changes, and another 2 weekends to really "get it" enough to build basic abstractions.
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.
I’d add that this is a great opportunity for OP to treat it as akin to “rustlings” or a possible analogue, where they break different functions that they know work, and building it up again s.t. the tests pass fine.
As a counterpoint, I’m a senior engineer at FAANG with 15 professional YOE. I’ve mostly used scripting languages in my career though.
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.
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.
> 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.
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.
I actually decided not to say "maybe we're particularly smart but..." for this reason. (I'm trying hard not to make it "humblebragging".) Regardless of that, we definitely don't feel smart due to ADHD.
Really all I'm saying is that I can't fathom how someone could take 3 months to be productive in Rust, that's a massive over-estimate.
A lot of people have a different understanding of what "learning a language" means. Your example of a path tracer doesn't show a lot of understanding of the deep parts of Rust (algebraic types, async, etc), while the guy who spent 3 months may have been trying to learn a lot more than just the basics to write a path tracer.
Ah, async is indeed the beast. We haven't really put a bunch of effort into understanding futures and reactors, but we understand them to be state machines (which is unfortunately glossed over by a whole ton of reference material?).
AFAIK it shouldn't take 3 months to pick a crate off the shelf like tokio and use futures effectively, but it could take at least that long to understand them deeply enough to the point where you can make your own reactor from scratch (like tokio) if you're also trying to pick up the rest of the language in parallel.
Most of the two weeks was indeed slaving away at math and not necessarily learning the language better. I think it wouldn't take longer than a few weeks to complete the official book and the nomicon if you're determined to learn the language. And then you'd use the remaining time to get acquainted with the ecosystem... but probably not 3 months of time.
>"With that said, "typical JS/Python devs" might not even know said basic programming concepts"
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.
A path tracer is a classic classroom project example. I really do not think knowing how to write one is even remotely related to "knowing a programming language" at least in the way it's expected in a professional setting
Pather tracing / ray tracer are very easy to implement because it requires basic programming concept. It's all about the math not really programming. You can copy paste from one language to another.
I have 30 years in c++, and yeah, rust was easy, but I'll still admit I'm more productive in matlab or julia or pytorch. And I'm still in that phase where I have to check the internet every 10min in python. But deploying in those languages has throughput and/or latency impacts that may or may not be ok depending on the situation. The reliability is also a thing. Assuring correctness in a dynamic language takes a lot more time, more unit tests are needed. It is still faster to iterate to a solution in abdynamic language though. But rather than write all those tests and live with constraints, I usually rewrite in a non dynamically types language.
"equally productive" is misleading. IME Rust is slower to write but faster overall because you spend much less time debugging and maintaining the code.
"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.
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.
In Rust it's easier for me to use the web API's than it is in C++, and in Rust it's easier for me to use the C/C++ API's than it is in scripting languages.
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.
Yes, the key thing about being productive with Rust is that it heavily nudges you towards designs that compose well, avoiding shared state and enforcing a clear, RAII-based lifecycle for every object. There are facilities that you can use when you need something a bit more general than that, but you should only use them when appropriate - ideally, you'll want to document the reason for their use.
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.
I really think c++23 and future releases should adopt cpp23{} to designate code where the compiler is allowed to break old stuff in the name of enforcing modern practice.
Rust is fabulous at avoiding those types of errors. Use rich types to avoid domain errors, use Rust's enum's to hold state data and then use exhaustive match etc to avoid logic and algorithmic errors, use wrapping_add et al to avoid arithmetic errors.
If you use the type system well you rarely get wiring issues you would normally get at runtime (wasting an entire "programming cycle" of writing code and trying it out).
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"
>"If you use the type system well you rarely get wiring issues you would normally get at runtime (wasting an entire "programming cycle" of writing code and trying it out)."
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""
> 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)
Although you're lucky that someone included the type annotation for x, and you might know what Bar really is, you still can have no idea whether e.g you can safely modify x in this function. Because maybe something else holds another reference to this very same instance and will be confused if the object suddenly changes here.
In Rust if you encounter:
fn foo(x: Bar) {
foobarize(x);
}
you know there is nothing else holding x, and this function can do whatever it likes with it. You can very quickly deduce who owns what, what is shared and what is not shared. IMHO this helps understanding complex systems very much.
I thought this is what would be the case but the reason it is slow for me is not because it takes me a long time to get to compilation. (It’s true but it’s a small factor.)
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.
Rust only prevents shared mutable data by default. You can always mutate things in a local context (i.e. objects that are either owned or uniquely borrowed) or use the "cell" constructs to opt-in to shared mutable state.
> You can always mutate things in a local context (i.e. objects that are either owned or uniquely borrowed)
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.
I agree with this. I may not be able to have a non-working prototype that crashes on its first input as quickly with Rust as with Python, but I can create a working prototype more quickly, and that prototype will transform into production code far more quickly.
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.
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++.
It also depends on the larger ecosystem. If you know Python, it's not just Python the language, but the frameworks, libraries and tooling around it that boost productivity in specific tasks: for example Django and Pandas. Rust may have rough equivalents but they may or may not be as well developed and supported for all the edge cases.
> 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.
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.
You’re correct. I actually spent the summer before I learned Rust learning C++. While that definitely helped learning Rust I was barely capable of writing anything in C++ after 3 months. (Though that wasn’t 3 months full-time)
I’ve done C++ in some projects and still think 3 months re-training might be necessary for new language features, and old foot-machine-guns for that matter! C++ is a dangerous beast if I ever saw one.
Yeah, while there is a decent market of remote Rust developers, hiring locally can be very challenging.
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.
Typically those things would be enclosed in libraries providing safe and convenient APIs. Sometimes you might need to use a bit of Rc<RefCell> here and there. At worst, you are not any worse than in C++: use unsafe.
If I had $1 for every time someone told me that Rust had a "safe and convenient" API to do something that I wanted to do which didn't actually do the thing correctly or conveniently, I would have a lot of money. This line really needs to be dropped from the Rust sales pitch.
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.
I actually don't find that to be the case, since most of the things you need are in one of the mega-libraries from Google or Facebook and the alternatives are often easy-to-find github repos.
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.
Yup it's why the language shouldn't be too integrist with its theories or too particular with its syntax, because when time comes to find an intern to survive a few month and they're all swimming in Java and Javascript, you're fucked and you cant even beg a C/C++ oldie to come out of retirement.
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.
That sounds like a good opportunity to learn the language.
I've had to learn things under duress in my career, often rhat 'low-code' platform whose app is now broken or needs some change, that COBOL system being migrated, whose rules were written before I was born, etc.
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).
> I've had to learn things under duress in my career
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.
The simpler parts of Rust feel like TypeScript, let's say as long as you're doing simple things as a start and don't worry about threading.
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.
> 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.
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.
I'm beginning to wonder if it's actually more difficult for C++ developers to learn Rust, at least speaking from personal experience. There are so many things I want to do in Rust when mapping from my C++ knowledge that are genuinely unsafe, e.g. copying around reference objects (including iterators) but convincing myself through rigorous testing that none of them ever dangle despite the somewhat unrelated lifetimes.
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?!
> copying around reference objects (including iterators) but convincing myself through rigorous testing that none of them ever dangle despite the somewhat unrelated lifetimes
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.
> I'm beginning to wonder if it's actually more difficult for C++ developers to learn Rust, at least speaking from personal experience.
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.
Oh, there are plenty of idioms you can use in C++ that are easy to make safe (as long as you don't make a mistake on some very small amount of code) that Rust will make a nightmare to implement.
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.
The problem is that very few idioms are both safe and compositional (which you need if you want your development approach to scale to the largest projects). Rust focuses on these as a sensible default, for everything else there's unsafe.
> Oh, there are plenty of idioms you can use in C++ that are easy to make safe (as long as you don't make a mistake on some very small amount of code) that Rust will make a nightmare to implement
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.
> I could see how it would be hard for someone whose only background is in js or python.
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!
Never heard this before but will now look out for it.
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.
> But someone who's never called "map" or who has never worked with pointers may take longer.
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.
> 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.
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.
I agree with you. I’m learning Rust as a Python-only (bit of Typescript) mostly data-analyst experience and Rust has been challenging, but I’m slowly getting it thanks in part to its new popularity and variety of tutorials.
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?
If you look at the Rust community, it’s split between those that consider Rust appropriate for systems level programming and those that want to use Rust for everything. The
back-end Rust comes from the latter part of the community and my impression is that it’s fighting an uphill battle, because the language is not a good match for such software when compared to Java or even Go or Python.
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 :-)
> The back-end Rust comes from the latter part of the community and my impression is that it’s fighting an uphill battle, because the language is not a good match for such software when compared to Java or even Go or Python.
>
> 400.000 lines also sounds huge for a web project.
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.
If you're just sending static pages, sure. Not if you're doing significant processing like I do. It's also an issue of scaling, where I could probably serve at least ~1000x more traffic on a single machine (and I know I'll never hit that much traffic). And if you don't need high availability (although I haven't had a single outage is over two years, thanks to Rust's reliability and focus on correctness) this simplifies your architecture and your deployment significantly, because now if you're on a single machine you don't have a distributed system, you don't even need caches, you don't need load balancers, you don't need to administer multiple machines, you don't need Kubernetes, backing everything up is very easy, etc.
(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.)
Is this a one person operation you’re describing or a commercial project developed by a team which is bringing in revenue? How long has it been in production and how long will it be developed and supported?
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.
It’s a huge learning curve but it’s worth it. I came to Rust from Ruby and after a few years of practice now I’m at a spot where I would generally prefer using Rust over Ruby.
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.
> Basically the product was developed by a bunch of Rust enthusiasts in a R&D group
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.
How does "a small team" end up writing 400k LOC? My guess is that the count may be inaccurate - it probably includes a whole bunch of vendored code that got added to the project because of the high-security environment. Rust and Cargo make it challenging to develop a project in a fully "secure" fashion, C/C++ has a better story there.
> Rust and Cargo make it challenging to develop a project in a fully "secure" fashion, C/C++ has a better story there.
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.
There seems to me like there is a clear third option here which is for the organisation to buy an online rust course or select some of the (many) free materials online and pay a few existing employees (or new employees with previous programming experience but no rust experience) to do nothing but study those resources for two months before making them the senior devs/tech leads of the codebase. What is it with organisations refusing to pay to train and upskill employees nowadays? It is such short minded thinking to not invest in your own people.
Tbh mate I think this is a bit of a daft contrarian take. Clearly you would offer it to existing employees to see if anyone was interested then, if not, hire new employees like I said in the comment. If you've still failed to find an employee (who is going to get paid to do nothing but learn a brand new language and then be senior dev/tech lead for it which would be a pretty sweet gig for a lot of people) you would then do the heavy handed approach of forcing an employee to learn it. At the end of the day you can't have a critical piece of organisation infrastructure completely unmaintained and if you have to, then you'll have to strong arm someone in to it, but you should always aim to do that as the complete last resort. And if you are going to do it, you can probably sweeten the deal with a pay rise or other perks. But I seriously don't think you'd have to because if you were a junior/intermediate dev and someone offered you an opportunity like this to both learn a new language whilst getting paid and rise a rank in position and compensation you'd be mad not to take it.
Honestly? I do the job that's in front of me. That has included everything from pre-STL C++, to 90s-era PHP and even Visual Basic for Applications. And a few things even more obscure than that.
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.
Personally, the most important trait I look for when hiring programmers is desire to learn. It’s a natural proxy for both motivation and problem solving.
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.
I volunteer as tribute. Rust is on the list of stuff I’d be excited to learn and use professionally, more so than other stuff I’ve only learned by necessity.
I’m just not sure how often it’s worth the effort, compared with the runtime cost of GC and immutability or mutexes.
How can I learn more about the project and your situation? I use Rust at work and enjoy working with it; I've also done some work for .gov in the past and like to see technology projects in the public sector be successful.
> The product works great, but the codebase is around 400k LOC of Rust, and we don't have any budget to hire Rust developers.
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.
From the individual developer point of view, learning something new while getting paid for it is the best thing. So if your organization is up for it, I would take that chance without a doubt.
Are you guys C or C++ programmers? (I'm not.) Here's why I ask.
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.
Sounds like the project didn’t have a continuity plan for how it would continue to be developed or maintained after the grants ended, regardless of the implementation language.
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?
Fix itself? What would that even look like? We use Rust extensively and haven't regretted it for a moment. If other companies can't see the competitive advantage it offers us, too bad for them.
Which is what I would call "organic growth". The exactly same thing happened with Python originally too. It took a very long time for Python to show up in "the industry" and in many ways it never did because it only shows up in certain parts of it.
> but has not (yet) had a massive industry adoption
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.
Developer desire to use it outpacing industry adoption seems like a sign of a well designed language to me. Developers can switch languages much faster than entire projects or companies can, so having more developers than jobs signals a language that people want to use.
Businesses still view security issues as a cost center. Developers like it because it lets us worry less about the easier mistakes that we all sometimes make and focus more on the deep logical errors that can lead to the same problems.
There has been a desire to use Rust where I work, but it's really hard to make a business case for "Hey, see this C/C++ code that's worked well for years if not decades? Let's rewrite it in a whole new programming language!". I wonder if it's the same story elsewhere?
In general rewriting a well functioning, battle tested codebase is probably a bad idea.
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.
Cargo is not de facto better than vcpkg. That Rust has a blessed package manager instead of community of competing package managers is a lateral, neither better nor worse.
Vcpkg? Never heard of it. 90% of C++ project I saw were using make. Remainder were using cmake.
> 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.
Except for grpc that uses bazel! I know two teams where I work, one uses vcpkg, but the other uses conan. Our company as a whole points to conan as the answer, but mostly everyone uses cmake and git submodules. That is why a single blessed package manager is better than many, none of them play well together. And that is ignoring hunter and meson. I don't know what the gp is talking about.
Just this week we were porting some old c++ over to rust, stuff from the 90s probably. It was relying on the last element of an array being zero due to null termination. It used that value in its computation. That sounds crazy but fine, except it wasn't an array of bytes, so if it wasn't aligned and padded to 4bytes that last value might not be all zeroes. I don't know a common arch outside of microcontrollers where it wouldn't work, but still!
- 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's worth noting that Rust is about the same age as most of the modern C++ paradigms that you see all over C++ codebases these days. C++11 came out at around the same time as the Rust project reached bootstrapping, and C++14 came out less than a year before Rust 1.0.
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.
> 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).
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.
Or old (-ish, I'm early 40s). I'm back around to C/C++, haven't touched it since C++03 and C++11, having recently accepted a Senior+ role in gamesdev and moving away from a decade of backend work.
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
The reason it is popular is that the developers who are working with it right now have most likely chosen to do so, as those are greenfield projects. There simply aren't enough old projects written in Rust around to have people be forced to work with them due to sheer market inertia.
Companies need people to maintain codebases that were started 20 years ago, this is simply not the case for Rust.
We've been hearing this theory since Rust was a much smaller percentage of the total responses. With an order of magnitude more developers using the language, you'd expect this high "loved" rating to have slipped considerably, at least behind less commonly used languages, but it hasn't. So I no longer really buy this theory; I think it's centered in the idea that real improvements to programming languages aren't possible, and familiarity / enthusiasm trumps everything.
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++
I’ve been writing rust full time for the last 2 years, and I’m going to make a bold prediction: I don’t think rust will displace Java at all.
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.
Back in the mid-1990s, Java was the first type- and memory-safe language to be widely adopted in the enterprise. It was, in a sense, the Rust equivalent of its day when compared to the previous standard of C++. It may have been a lot slower and clunkier than C++ back then or Rust today but this mattered less in the 1990s when if anything, its unique cross-platform development story would've made it feasible to seamlessly deploy it on high-performance servers and midrange machines. Sure, today Java/C# are mostly adopted as a matter of convenience but this wasn't always the case.
I'll give another reason: the typical Java (and JS/Python/whatever) developer doesn't have the knowledge, dedication, and interest to learn it. And companies don't care about maximizing performance in most cases, they want good enough for cheap enough, and a decent Rust dev is going to cost more than a decent Java or .NET dev
Dedication and interest among developers will grow when compelling stuff starts to be written in Rust. Same as Java in the 1990s, .net, Python and Ruby in the 2000s or JS in the 2010s.
No, I'm saying the typical dev doesn't have any interest in learning anything new beyond what they already know, and some hot new thing in Rust isn't going to change that. The level of mental effort needed to learn Rust is greater than the typical dev is willing to expend on anything.
I'm an experienced Ruby web developer, and I'm starting to learn Rust. You mentioned Java and Nodejs, but I still wanted to chime in on the topic of languages in web development more generally, and the applicability of Rust to web development.
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.
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.
I thought Rust was to C++ what Scala was to Java. Which implies two communities which don't overlap much. I loved C++ 20 years ago but I'm not going back to manual memory management. I'd rather hold my nose and use golang if the JVM languages don't keep me employed anymore.
Totally agree. Java shops don't have the memory safety issue Rust solves. Without that benefit, why bother switching?
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 think Axum has the potential to be the top web framework. Not too high, not too low, very well designed and complete, and well maintained with healthy momentum. It has become our web framework for web services and web app backend.
Not sure we will ever see a "rails" like framework in Rust (for the better IMO)
Axum, Tonic, Serde, and Tower are extremely powerful together. They make building APIs so straight forward. I do wish we could add a few features for free, such as interning JSON strings (which you can do easily via a new library) but this set up is so pleasant to use that I believe it will stay for a long time.
I have recently written a service in Axum (our main API is written in Rocket), and absolutely LOVE it, especially the macro-free API. Next full backend project will be in Axum for sure.
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.)
One of primary reasons that Rust adoption has been stifled at an org I work with is that the cloud provider we use (GCP) doesn't support Rust with client libraries or SDK's. We know there are 3rd party providers, but they're not willing to go without GCP official support and I can't blame them.
I would put more money on C++ seeing a resurgence contingent on C++ modules getting solid support, than Rust displacing C++ in the enterprise.
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.
Unfortunately I think C++ modules are too little too late. It will take a decade for it to propagate fully through the C++ ecosystem, and even then it will remain fragmented in terms of build systems, packaging, coding styles/standards, etc.
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.
Sure, it will take forever for modules to get everywhere, but you only need a few solid frameworks/libraries with module support for it to matter.
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.
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.
reply