>Rust is a superior technology to C++....it disciplines you to do the things the right way.
>But Rust is better in the same way that Betamax was better than VHS, Mastodon is better than Twitter, Dvorak keyboards are better than QWERTY, Esperanto is better than English and Lua is better than Javascript: in communication technologies, adoption and critical mass are 90% of the game and the other 10% are bikeshedding, at best. And programming languages are a communication technology, they're means to communicate ideas to other programmers.
Love this. May be I should repost this every time there is an argument about Rust. And to expand on that, in communication technology, the one easier to use is going to get wider spread / adoption. And while there were never much hype around Go, I think it is a very good example.
But a lot of Rust [1] ideas are now being polished and used elsewhere like Swift. I am sure we will continue to be experimented in other languages and real world to test whether the trade off is worthwhile.
[1] ( ok may be Cyclone or something earlier in case someone wants to nitpick )
>the one easier to use is going to get wider spread / adoption
Between Rust and C++, this is Rust. In C++ you need to a lot more memory safety verification in your head, there are thousands of footguns that you need to be aware of at all times, the template metaprogramming facilities are really hard to grok with their weird syntax.
Rust is strict, but for the kinds of applications that you would replace C++ in this makes it a lot easier to learn.
I think the sentiment that Rust is hard comes from people that come from managed languages (Python/Java/C#) that aren't used to manual memory management. From that perspective Rust is indeed hard.
I'm used to writing C, and think pointers are easy to understand. I wouldn't call rust 'hard' to learn, but it is without a doubt painful. You also aren't doing manual memory management in rust either... I'd assume the sentiment comes from the irrelevant hoops rust makes you jump through to just compile something simple.
You don't need to be aware of 1000s of foot guns for every block of non rust code. But you do have to remember dozens of pedantic rules, or stdlib wrappers just to trick rust into allowing you to compile your simple/demo code.
> You don't need to be aware of 1000s of foot guns for every block of non rust code. But you do have to remember dozens of pedantic rules
Have you tried using rust-analyzer? I'm usually a bit of an IDE skeptic, but Rust is one of those languages where tight integration with the IDE really helps IMO. It's night and day, I honestly wouldn't want to write Rust without rust-analyzer, but with it it's quite pleasant.
C++ has much more bigger inertia. It is like the "default" for all the areas where it is being used. So when learning a language people would rather go to C++ first and then to Rust, if they are really planning to work in corresponding area (game dev etc.). Or even go to C.
Rust will probably replace C++ in some areas where it is a legacy app (or part of the app) that is not changed frequently anymore.
Yep. I've been developing in C++ professionally for a decade and I still have to look up "what's the safe way of making a string literal available in a header file" when it comes up.
Not OP but I think it depends on your definition of 'string'. For example there are some very grumpy devs who believe that C has no strings, and that "const char*" cannot ever be considered a string, and that anyone else who claims so is wrong.
I largely agree with the "programming languages are a communication technology [thus critical mass is critical]" bit, we spend more time reading and explaining code than we do writing it. That's why I'm really hopeful for Rust web frameworks like Loco to get to mainstream-ish.
There are just _so goddamn many_ webdevs that a reasonably popular web framework can bootstrap a language out of the mid-popularity uncanny valley. On the flipside, a lot of webdevs are interested in Rust, but aren't really personally set up to do some embedded or systems stuff, so the activation energy for a given developer getting into it remains slightly higher than other languages.
I think a question that must be asked is "what market?" Go is a very niche language in it's application: it is ubiquitous in the Docker/Kubernetes DevOps world. It's also successful as an alternative to Node in the server/micro services world. And there are many CLI tools written in it (but CLI tools can be written in any language whether or not it has critical mass - there are popular ones even in Haskell!).
Excluding CLI, Go's use cases virtually did not exist when Go was created. So Go was "the right language at the right time" to grow up with it's niches (decent performance, easy to learn, easy to reuse library code, easy to deploy, easy concurrency). It is virtually non-existent anywhere else.
On the other hand, Rust competes in exactly the same high-performance/low-overhead space that C++ dominates. Because of Rust's complexity, it is very unlikely that it can compete anywhere else. Rust must displace C++, or at least be a viable alternative to it.
I wrote a BBS in Rust. It need sleep neither high performance nor low overhead, but it was a delight to write. For example, the compiler error messages are so detailed and explanatory that I learned a lot of the language from it telling me what I was doing wrong and offering suggestions.
I would’ve written it in Python a year ago. Now I wrote it in Rust because it was genuinely fun and the results came out nicely.
I have zero interest, none, nada, in C++. (Readers: please don’t try to win me over. I know more about the subject than you might think and it’s an informed opinion.) For me, Rust doesn’t compete with C++ at all. It’s probably replacing my Python coding more than anything else. The output looks and feels quite Pythonic, but with strict types and AOT compilation to native code. I’m loving it.
What do you mean when you say “Go’s usecases did not exist”? It was invented to write concurrent servers in that would have readable, performant implementations suitable for use across teams, to make code review faster and better, to displace C++, and to prove that certain design principles from Dis / Plan9 were superior to those in Java. I’m not really clear how those usecases did not exist at the time. If you mean “Go is for scheduling containers”, you are wrong, but just because one popular application exists that doesn’t imply that is “what it’s for”.
I inherited a project that uses Go for an industrial control system. It needs to manage valves and pumps and sensors in a performant and accurate and reliable manner, and that's what the developer (an electrical engineer) chose. FWIW the system has been in production for a couple years and works splendidly.
The me of yesteryear probably would have developed such a thing in C++. In an alternate universe, there's a version of me that learned Rust 5-10 years ago and would have chosen that.
... and for all of C++'s perceived simplicity compared to Rust, it can still have compilation issues (looking at the compiler errors output by template classes can be a downright nightmare)
Rust is not "17+ years old" in any relevant sense. Rust 1.0 only came out in 2015, and the first genuinely usable version arguably was only in late 2018 after non-lexical lifetimes (NLL) were added. Golang is a lot older than Rust, practically speaking.
As with most things, I think that not only is "better" subjective, but such dogmatism is a sign that you are not considering that other relevant perspectives or context may exist that can disagree with you. I think true intelligence by definition requires humility and realizing that we can't know everything, there are things we don't know that we don't know, and the world is not so black and white.
Good point. At the cost of relearning typing some folks may increase their speed but its not easy to determine if they would have won similar gains spending time improving habits with qwerty.
That said its nearly irrelevant because for most jobs typing speed isn't a limiting factor for those with average typing speed for proficient users.
> Dvorak isn't particularly better because typing speed isn't worth optimizing for if you are good enough
Is Dvorak even quicker? I tried learning it and found some quirks, for example, lots of English words end in "ght" (thought, bought, draught, taught, etc...) which is extremely awkward to type on a Dvorak layout (you need to strike all three with one finger whereas on QWERTY it's split between both hands so you can alternate).
I agree with your point though. I type 80+ WPM on QWERTY with no maintenance and honestly, I type way faster than I can even think about what to type (especially for programming). Now that my college essay days are way behind me, I don't think it even matters.
>"Rust is a superior technology to C++....it disciplines you to do the things the right way."
It is not. The only thing it disciplines one to do is to bend them to confines of particular safety model. And Rust creators do not have the ultimate authority to say what is the right way anyways. No one does. There are multiple concepts fitting different situations. Rust ignores many. As a general language it looks way too opinionated to me.
> Rust ignores many [safety models]. As a general language it looks way too opinionated to me.
I'd like to see some actual examples of this, and I assume many Rust devs would react the same way. In practice, most proposed "safety models" that Rust complains about don't really work when considering that code must be enabled to interact not just within a single module but rather across modules. This is where Rust nudges developers to make the right choices for successful programming "in the large", while still providing the "unsafe" featureset for safety assurances within a single, self-contained context.
When I said opinionated and ignores I did not mean safety models. I meant programming concepts like OOP for example. And do not tell me that it is not needed, wrong, etc. It is totally fine and useful for some situations and not so much for others. Developer should have a choice.
This is what keeps tripping me up, it is very difficult to be both general and not opinionated. C++ is general, you can use it however you want. Especially in many unsafe ways. Like it or not, this is great news for a general low-level language. A language that tells me how to build, where my files should live and what tools I am to use may be a great user experience, it is not very general. Still not sure what to make of this and where I land on this.
I do not give a flying fuck. Language is a tool. I work with many languages. If clients wants language XYZ then XYZ it is. My private opinion does not matter in this case
This maps to my own experience in the UK. Every time I search for a C++ job, I inevitably end up discussing my fondness of Rust but inability to use it at work. The interviewer will typically reply mentioning discussions of using it for greenfield projects - but I know it won't result in me writing anything of substance.
2 years ago, seeing a somewhat applicable Rust job-description made me 90% certain it was about cryptocurrency fintech. Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages. Neither are fields I really want to work in. And what a shame it would be if such a great language was relegated to being an Ada alternative.
I try to keep on top of Rust, - it's the most likely candidate to put me out of a job - but it will be a long time before there are no more legacy C++ codebases. Being the COBOL guy of the future doesn't sound too bad.
Being in the uk, we were fortunate enough to choose rust as a main language with my co-founder about two years ago. We chose it after trying it out for some toy projects, and with no real experience with it (but both of us having heavy experience of C++, C#, Python, Ruby, and having tested many others).
We chose it because it felt "right", giving us c++ performance, productivity when writing, and a feeling of cleanliness from its type system I had not experienced since ... Ocaml.
But what we did not expect was how great it was from a talent perspective. We started hiring at a time where lots of rust developers were being laid off crypto, and the caliber of candidates is just ... amazing. Rust devs enjoy working with the language, and you get a type of developer who likes producing good code, and is usually quite passionate about coding.
So, I understand rust jobs are not easy to get by, but being on the other side of the table, it's a wonderful talent magnet for our team, allowing us to hire great developers.
Apologies for the off-topic but I am currently in a job search. I'd rate myself below the guys and girls you hired but I am very enthusiastic working with Rust. You hiring?
Again, sorry. :( But I am not getting any networking opportunities lately and couldn't resist replying to your message.
The crypto bit is an interesting filter. Wether the developers you found are true believers, grifters in on the scam, or just mercenaries for hire welding crates, they can't not have an opinion on cryptocurrency so my question to you is how much of that do they bring to work? Are there coffee chats about Ayn Rand and politics or do they steer clear of any of that.
> I think you have a very skewed view of what people interested in cryptocurrency are like.
Given that it's a heavenily gift for criminals (including those wishing to evade taxation on otherwise legit commercial activity) while leeching a good share of world's energy resources, I think he's excused.
Absolutely! It's a spectrum and people lie somewhere on it. I can't have a picture of the entirety of it (though I'd love to), but I can only go off my own experiences. I try and get as full a picture as I can, but it's unfortunately going to be skewed. yours is too. I'd love to hear which way your POV skews towards
Let's assume a normal distribution of humanity exists in crypto, ie, broadly, over all of humanity, there are good people and bad people, so we would expect there to be good and bad people in crypto, as, while there are some self-selecting aspects to cryptocurrency enthusiasts or developers, there isn't a way to select for "only good people". This is true for every group of people. This is true of the police, true of the clergy, true of school teachers, true of software developers, politicians, etc.
So if you've never once seen them, either you're wilfully blinding yourself, or you haven't looked very hard. Now, whether or not grifters are overrepresented in the cryptocurrency community, the cryptocurrency developer community, or the right wing crypto YouTubers community, is an entirely separate question, which I made no claims about. Though I imagine North Korean crypto devs fall into a certain category.
But to claim they don't exist, because you've never seen one is questionable. I mean, that works for some things (eg unicorns and dragons), but I've also never seen eg the Vegas Sphere in person, but I'm fairly convinced it's a real thing that exists.
> Being the COBOL guy of the future doesn't sound too bad.
This is where I arrived for different reasons. It seems that Rust might become an important language, career-wise, so I learned it to the level of basic competency. In the course of doing that, I learned that I really hate Rust. Not on technical grounds, but I find the language itself unpleasant, and I dislike much of the tooling around the language (crates, etc.)
Rust wouldn't be the first language I've learned and dislike, but this time, I decided to just take a pass. Even if Rust becomes the predominant language, there will always be work in other languages. I'll be content with that.
Not OP but the syntax is off-puting for me, it's simply difficult to read.
I can parse and read all C/C++/TypeScript/Java/C# code with ease, it all makes sense and reads like poetry. Rust's syntax is just ugly, I have a visceral unpleasant feeling sort-of like when I have to read Perl code or (to a lesser degree) Objective-C.
lifetime annotations seem to be the biggest yuck for most people, given it's the most un-C++ like syntax (and single-quotes are always balanced in most languages).
This is also true where I am in Australia. There are very few Rust jobs.
However, from the first two comments on the article :
"We use Rust at AWS (in my org) for every new project that would have previously been written in c++.
[–]rigmaroler 104 points 23 hours ago
Microsoft is the same. All new services running on VM-hosting nodes (i.e. domains where C# is explicitly not allowed) have to use Rust now. It's a top-down mandate.
There's also AI investment in converting C/C++ services to Rust, but I have a negative opinion on that investment"
So there is clearly a substantial amount of Rust being written in some places.
That's a kind of tier of employer that wouldn't even invite me to interview but you are right and I expect it will trickle down to my level in the long-run.
Don't beat yourself about it. My advice would be to get not too crazy about programming languages. Become proficient at one. Pick either C++ or Rust. Don't use HN as a source for making your next moves in career - it is very skewed. Rather use that energy to invest into building domain-specific knowledge - that will get you a lot further than being a programming language afficionado and a language lawyer. IMHO.
Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages.
I know a few contractor teams that have moved to Rust not because of any federal pressure, but simply because they're small and hierarchical enough that 1-2 people who understand the benefits are able to set the development language.
They've been using safe languages like Ada and SPARK2014 for decades, and those are hardly unsafe. In fact they are safer and more mature than Rust and easier to learn IMHO.
Tried hiring people for Ada jobs, or finding open source stuff to use in it? Ada has failed to find a market even in the safety-critical niches it should be dominating. Heck, AdaCore is putting out more Rust stuff these days than Ada.
Yet, 7 companies are still in business selling Ada compilers, in a world where most devs refuse to pay for tools while expecting to be paid themselves.
And presumably they're all selling almost exclusively to the aerospace industry. There's like a dozen COBOL compiler vendors too. It's not indicative of the health of the language ecosystem.
Ada is used all over the place in high integrity computing, that is much more than aerospace.
Well, COBOL just got ISO COBOL 2023 out of the door, and both Visual COBOL and NetCOBOL, still offer a much better development experience than many FOSS toolchains.
I don't think spark is easier to learn. Ada probably is. Ada sacrifices some performance for some of the benefits rust gets for free though, and deallocating memory is unsafe in the versions I've played with. If forbidding free is the way we choose to eliminate use after free, then there are a lot more memory safe languages.
Controlled Types and SPARK provide the mechanisms to deallocate only when it is actually safe to do so.
Additionally unbounded collections, are just like graphs in Rust, they provide safe ways to managed dynamically sized collections, while hiding the unsafe code in implementation.
They're saying they stay up to date with Rust, because it's the most likely to do away with C++ (their job), making sure they have relevant skills for if that happens.
> Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages. Neither are fields I really want to work in.
But that's not a problem with Rust, and it's not something that anyone should feel ashamed about. Just acknowledge "Hey I can't use Rust because I can't commit the brain space needed to it".
Exactly. VSCode and Chrome already have Rust code, although only a very small part. But if giant, complex projects like these can find places where Rust fits, most other projects can as well.
Aside: I've been programming for... 35 years or so by my reckoning, but I can't recall ever hearing the term "greenfield project" before this year, and now it's seemingly everywhere. What's up with that? What happened to just... making new things?
I've used the term "greenfield development" for 10 years and I'm not even a native speaker. Though I have been on this site longer than that, so I might have picked that up by osmosis.
Been around programming for ~20 years, professionally engineering for 13 of them, and I think I first heard the term (and have heard it consistently since then) at least a decade ago.
This and also what people don't realize is that because right now Rust is a passion project for most people almost everything in it is of very high quality.
Jobs will come soon because stability and speed is good for business. And then we will have a bunch of lower quality stuff but more jobs. So enjoy the good things at each stage.
I agree with your take and want to add that Rust has stellar tooling and code analysis of it also looks either easier or just more people are doing it so I think linting and semi-automatically applying better practices will be easier compared to, say, Python.
Ime you kind of do, at least did. I learned rust twice I think. First time it had a lot of time hype so I sat down and learned it. Then kind of like this rant never used it so it forgot it.
Then it came up at work and the language changed enough that I had to learn it again. Features were added, the "community approved" libraries changed, tools changed, coding conventions changed.
I never had that feeling with any other language I've used in similar ways. Javascript, ruby, python go I always felt like I could learn, stop using and come back to use pretty easily.
I have difficulty picking Rust again for semi-different reasons than yours: it simply has a huge surface, not only the core language but also the libraries; the amount of those you really must know to be able to call yourself a commercial Rust programmer seems to grow with time. (You mentioned this last point, hence the "semi-different reasons" expression.)
I know Rust quite fine as a language but put me in a commercial project and I'll definitely need a few weeks to learn what should be used for i.e. error handling, logging, OpenTelemetry, and such.
That's odd! Finding libraries (crates) has been the easy part for me. You usually get the answer directly from crates.io. Even in cases where there are multiple alternatives, it's easy to choose one based on the statistics available on crates.io. And in the rare case where you still can't decide, a web search reveals the frontrunner with detailed articles on why.
Oh, I'm not saying it's difficult. I'm saying that at one point it becomes too much. And if I don't actively work with Rust I end up forgetting and having to relearn in the future.
How is it different from the situation in other languages? Especially the ones like C and C++ that don't have a canonical source registry either? (Not a rhetorical question)
Normally yes but f.ex. my favorite Elixir has a community that very strongly prefers and orbits around singular solutions of thorny problems. You will not find many ORMs / DataMappers in that ecosystem, it's one that has been super hard worked on and nearly everyone accepts it and loves it and contributes to it when the need arises.
Meanwhile in many other languages, Golang and Rust included, there are many ways to do the same thing. That introduces difficulty to keep well up to date.
But I can easily agree this point gets very weakened after you have worked with the language for a certain amount of time and on.
I wonder how much of this love of Rust stems from the fact that he actually didn't have a full time job programming in Rust. When one starts off doing hobby projects in Rust the experience can be very pleasant thanks to cargo (btw, it is a bit puzzling that vcpkg is not adopted more broadly in C++ land since the gap from cargo is not that bad).
However, once you get a job writing programs and find out you need to quickly prototype, refactor the code or make changes under a strict deadline, not good, it quite literally is the worst language to make large scale updates beating even C++. This is not counting the other memory safe languages (golang, C#, Java, Kotlin, etc..) which is where you should first target.
> it quite literally is the worst language to make large scale updates beating even C++
Having worked in both C++ and Rust codebases professionally, my experience has been the complete opposite. I have to be extremely cautious when making changes to C++ codebases, (especially async ones) and it’s always a huge time sink trying to just get the damn thing and its tests compiled. Rust’s compiler and tooling, on the other hand, allow me to make high-pressure changes much more confidently. It’s not perfect, but I’ll take it over the average C++ project every time
I'm not sure what's happened on the Rust projects you've worked on professionally, but having used Rust for over nine years now personally and about five years professionally, every experience I've had trying to refactor large projects in Go, C++, Python, and Ruby at work has been strictly worse than even my worst experience having to do so in Rust. Following the compiler errors makes it super easy to follow a chain of cascading changes from needing to change something that gets used elsewhere, which combined with the usual strategy of using the test suite to detect regressions makes it as easy as I could ever imagine. I've often had the experience where I've done large refactors that touch dozens of files and thousands of lines of changes where the tests pass immediately after finishing the changes to get it to compile, and in the refactors at least that size (including ones larger than that where it isn't as cinnamon to where that doesn't happen as often), the remaining work to fix things beyond stuff the compiler can catch is still much smaller than I've had to deal with in other languages.
Obviously, some amount of this is due to my own level of comfort in Rust and not specific to the language, but even if I accepted your premise that Rust is horrendous for large changes, that still would mean that being comfortable with a language can easily make up for any inherent issues with refactoring due to the language itself. If you strongly dislike working on large Rust codebases, I agree that it's probably better to avoid trying to use it professionally, but my experience is so radically different from what you describe that I have trouble believing that this is due to Rust being objectively unfit for large refactors to the extent that you describe.
There are cases when refactoring Rust code where it’s possible to hit limits in the compiler related to e.g. lifetime inference. When these limits are hit, simple straightforward refactorings that are perfectly safe become more complicated - suddenly you’re forced to manually annotate lifetimes, and to thread those lifetimes through function calls, and…
And your small, incremental refactor suddenly isn’t. It doesn’t happen all that often, and they’re working to reduce how often users run into these challenges, but a number of cases like this still exist. And when you run into them it can be a frustrating experience.
Personally I'm convinced that the solution to that is not for the language to be more implicit but rather to make tooling for refactoring more front and center. A task for "add a lifetime to this struct everywhere it's mentioned" is already catered to by modifying the original type and then applying rustfix, but more advanced but relatively common changes should also be mechanized away. The annotations are there not only for the benefit of the compiler but also the developers.
You might want to test some optimization or refactor without crossing all the Ts. Lost of reasons you'd want to quickly iterate without doing the maximum amount of work needed upfront.
You hear this about refactoring a lot and I don't get it. I've done several multi-thousand line refactors of a 500k line rust codebase in the past few years, and it's absolutely fantastic for this task. The type system guides you along, and once the thing compiles, it almost always works exactly as you intended it to. the "quick prototyping" languages like say python are a nightmare to do large refactors in, in my experience. at least if you don't want type system timebombs lurking in infrequently executed corner cases.
My experience is the exact opposite. Rust is slow for the initial programming, but great for making changes in, because the type system holds your hand and makes sure your changes are sound.
Refactoring C++ is an absolute nightmare due to templates and overloading. If you rename a function for example, tools can't propagate that change through a template because there's no way to know if that template is only ever used to call that particular function, and not some other function that happens to share the same name (some overload).
Another way to think of it is that in C++, templates are dynamically typed, and so templates suffer from all of the same refactoring problems that dynamically typed languages do.
In Rust that problem doesn't exist, there is no function overloading and generics are "statically-typed" via traits, so you can factor code that resides within generics just as you would refactor any other code and it all just works.
Rust was specifically designed to be refactorable and in my experience it is. It was part of the dogfooding process of building Rust in Rust - lots of changes to the language, lots of changes to the compiler, lots of churn. Rust's strong type system means you can refactor and be confident that programs continue to work.
> you need to quickly prototype, refactor the code or make changes under a strict deadline, not good
How many projects like this shouldn't be written in C++ in the first place? C++ isn't automatically faster than Java, and with the level of care you're describing ("strict deadlines, just get it done") you're unlikely to realize the advantage of C++.
Rust is a lot better at quick prototyping than C++. There is a specific idiom to writing prototype "throwaway" code in Rust though, where you .clone() and use RefCell<> and Rc<> a lot more than you normally would (not to mention really niche features like Any). The advantage is that this boilerplate guides you when refactoring the code for better reliability and performance later on.
Rust is one of the easiest languages for code refactoring, in my experience: the compiler amd clippy tell me everything i forgot to do. Just literally doing what clippy suggests often gets it compiled.
I use Kotlin all day at work and still think it’s a wonderful language.
I never use Rust at work and also think it’s a wonderful language. Rust is really just a fun language to write apps in. Is it okay for us to admit that yet?
Funnily enough I read the article and thought of Scala, which I love but can no longer find a job doing - and can't help thinking it's in large part due to FUD spread by the Kotlin people.
I’ve casually used Scala at work and home over the past 5 years. I mostly think this is because of the community and also the tooling and libraries.
WRT the community the functional zealots have pushed out everyone that doesn’t align to their ideology. Everyone that just wanted a better Java has moved on to Kotlin or back to modern Java.
WRT the tooling: scalac and sbt are so slow it’s painful and even IntelliJ can’t figure out what’s going on in Scala sometimes.
WRT libraries: every single time I have to upgrade play or the scala version there is a breaking change that either forces me to refactor or is undocumented and screws me at runtime.
So mostly at least for me, I’ve been burned by the language too many times to start a new project in it, especially at work where it will be long lived and I’ll eventually have to upgrade things.
I like C. I learned it a long time ago, it was one of my favorite languages to learn, and I'm comfortable using it.
I'm open to learning new languages, but learning new languages from people who talking nothing but trash about C does not inspire confidence. Nobody who loves unix says "you need to try Windows." At the same time, Windows lovers trash Unix. So the two schools remain separate.
if you want to sell Rust, find people who like C who will recommend Rust and shut everybody else up, then people who like C will listen.
Before Rust, C was my preferred language. It's really hard to talk about Rust in a way that doesn't sound like talking trash about C, because Rust's main reason to exist is preventing safety issues that… people programming in C usually say are not C's fault, so there's nothing to fix there.
The other aspect is that Rust has been developed recently, and didn't have to deal with all the legacy constraints of C. The features that Rust has would be mostly boring compared to modern GC or scripting languages, but they're notable for being in a language that can be as low-level as C. Comparing them directly to C does like trashing C — namespaced modules instead of textual inclusion, macro preprocessor based on AST (do-while tricks not needed), no headers, no need for build scripts in most programs, package management that works on Windows and macOS too, etc. Many other languages have this stuff, but C doesn't, so they're an interesting upgrade from C just because C is so old.
IMO choice of language is a design decision. Weighing the pros and cons of a particular language without specifying the use case and project requirements seems ass backwards to me.
To illustrate, consider if we rewrite the title: “Goodbye, Phillips head screwdrivers, I wish you success, but I’m back to flat heads”. Seems silly, doesn’t it?
To be fair though, I imagine this article is written as a reaction to Rust proponents making similar arguments.
Most regular hard-and-fast organizations outside of the SV bubble don't subscribe to this. They will rather tweak design around to match whatever labor pool is available (e.g. Java for most code farms in the past decades).
> But Rust is better in the same way that Betamax was better than VHS, Mastodon is better than Twitter, Dvorak keyboards are better than QWERTY, Esperanto is better than English and Lua is better than Javascript
Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript.
I caught a different meaning from this entire sentence. I think the author was alluding to the fact that even if you replace a technology with something "better", at the end it doesn't matter, because Most People will keep using Twitter, Most People will keep using QWERTY layout, count all of your acquaintances, I doubt any of them speak Esperanto.
Well at least the idea comes through, but I don't think it makes sense to argue whether Lua is actually better than JavaScript or not.
Indeed. If one primarily values certain technical aspects, Beta was "better" than VHS. But if one primarily values popularity, profitability or practicality, then VHS was "better". And so on with the other examples.
So when we go back to this:
> Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript
All I get from it is "I personally have a strong opinion about what makes a language 'better'". Nothing wrong with that, but it's independent from the argument made by TFA. Perhaps I misinterpreted.
In terms of not being a bag of special cases, and thus easy to use, Esperanto is better than English. Like, if you were to design a language from first principles, you'd come up with Esperanto. The only problem is the massive inertia English has, which makes it "better". In terms of design, it's absolute trash. But it's what humanity's got. Trying to learn English as a second or third or fifth language is just so difficult.
Those special cases are useful or the natural result of speakers coming from other languages. If esperanto were used widely for many years, it would also develop special cases over time. In 200 years, it would be as irregular as english, as it borrowed words and phrases from other languages.
I think maybe they meant it is a better lingua franca than English, which I'm a little more likely to agree with (Esperanto is by no means perfect for this)
For me, one major weakness of English is having adjectives appearing before nouns. The more time passes, the more I hate that aspect of English. It messes up all sorts of things. Most other languages don't have this problem.
Consider that in programming, technical docs, even normal writing, it is almost always better to the most important aspect of a name come first. The adjective-noun order in English makes this awkward all the time.
I love its contribution to wordplay. You can write things like “yesterday we sat down to a meal of golden, moist, roast whisky” because the adjectives lead up to a set of expectations about the subject that turn out to be untrue.
Well, there are denaskuloj, but aside from that, I don't think languages are adopted into communities to replace other languages based on their merits, but based on socio-religious factors that have nothing to do with the language itself
C and C++ are languages of an era. C++ will be unseated eventually but it will take another decade at the minimum for a new generation of programmers who have used the 'modern' languages from day one to overthrow the incumbents. Then another few decades to rewrite everything.
This will never going to happen for obvious reasons; if it ain't broken, don't fix it!
Create interoperability with other languages, like what Swift is currently attempting to do, yes; but to completely rewrite an entire project that consists of millions of lines, I don't think so.
All the code rewrites from the last several decades would like a word in return.
A bunch of those rewrites managed to miss critical things that were encoded in the existing logic in non-obvious ways. They broke a bunch of workflows that way.
A bunch of others went wildly over-budget and wound up getting shut down before they produced anything usable.
But surely the documentation will tell you all the use cases, and the expected inputs and outputs, right? Right? Oh, you don't have documentation like that? Yeah, then it's used in ways you don't know about, and your rewrite is likely to break them. (And that's true even if you do have such documentation, because it's incomplete.)
Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
"But this time we're going to use Rust!" Yeah, but the thing that makes rewrites so hard was never the language, so using Rust isn't going to actually fix it.
> Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
This is a major reason why so many financial/healthcare/insurance/government institutions still runs COBOL software on mainframes. Many times, you're looking at what is essentially a monolith (in many parts, but everything is connected in some way) that was 50+ years in the making.
Rewriting it is a huge and extremely expensive task, and had it not been because COBOL is considered a "bad language" by the young people, and thereby causing problems with recruitment, i'm guesssing the mainframe would be around for 100+ years to come.
As it is now, these companies are forced to migrate away from COBOL, and most companies in the financial sector would probably go for Java, which is posed to becomming the new COBOL.
If you start a career today as a young COBOL programmer, you will most likely have a high salary (for your career) for your entire work life.
The mainframe is certainly on the way out, but it's a big beast to move, and most "estimates" i hear from financial institutions is that they plan to migrate away in 10-30 years, and predicting what happens in 30 years is kinda pointless. Suffice to say that the Mainframe and COBOL is probably here for another 30-50 years.
I agree with your take and want to add that "we want less CVEs" and "we want meaningful rewrites" are not necessarily at odds with each other. We can have both.
I'll also note that efforts like rewriting a lot of UNIX userland in Rust also introduces the benefits of rewrites -- you have to think super hard if you want that obscure command-line switch that only works in X way if another switch has another value or it does the thing Y if two other switches have these other values. I forgot the examples but that's what happened there: people figured "we will not implement command switches X and Y" and lo and behold, people using those tools never even noticed, myself included.
So, rewrites have positives as well. And not everyone doing rewrites is clueless.
I didn't say that those who do rewrites are clueless. I said that rewrites are really hard - far harder than most people expect.
That weird switch behavior? I almost guarantee that someone, somwhere, some when depended on that behavior. Either they no longer use the switch behavior or they no longer use the tool, or they just don't use the rewritten version. But how do you know that? In the best case, the code would have a comment: "This code is to simulate Berkeley 3 behavior for users porting from..." But even that doesn't tell you whether anybody today still depends on it.
I mean, it could be a valid strategy to not rewrite weird behaviors - any of them - and see what breaks, and then only add the ones that are still needed. The upside is a much cleaner rewrite, with fewer (and, hopefully, better documented) weird behaviors. The downside is that you have to break stuff temporarily to find out. (Hopefully you break it in live staging rather than in production...)
All code has a lifespan, either because it rots or it becomes irrelevant/unneeded. Existing C++ code will gradually expire and the most important pieces will indeed be rewritten, accelerated by shrinking expertise.
This may be technically true on a long enough timeline, but COBOL is still the backbone of the financial sector even though companies have dumped millions into attempting to convert it to something new with limited success.
For sure, we can debate the timeline, we can debate what language will replace C++. The way I read stefanos82's reply is that they don't believe C++ code will ever be rewritten, which is obviously not true.
COBOL running the financial sector is a myth in my opinion. There are still companies running aspects of their business on it, but calling it the 'backbone' is an overstatement. If you tallied up lines of code by language in the sector, I would wager COBOL makes up less than 1%.
Yep, I've worked for two companies where Fortran handles all of a major department's business - in both cases it was buried deep under layers of more modern stuff... but it was hugely risky to change it so it stayed.
While the argument is generally correct, Fortran and COBOL aren't in the same league. Fortran is still being upgraded and has some use cases that are hard to achieve in another language. I've seen the Rust subreddit recommending use of old Fortran code with Rust, rather than rewriting it in Rust. Unlike most other languages like C++ and Rust, Fortran kept its scope mostly limited to numerical processing - making it still one of the best solutions to code highly parallel numerical algorithms in.
Fortran isn't surviving just because nobody wants to rewrite Fortran code. Unless you're talking about Fortran77 code.
Oh agreed - Fortran is much more alive than COBOL - but in both cases I think the Fortran had outstayed its welcome. I never saw one of the codebases but the one I did see was Fortran 77 I believe, and there were a lot of gotos and labels.
Rewriting existing code in another language might be one thing LLMs can actually get good at. I wouldn't doubt if they could convert complex projects someday, without too much error or hassle.
C++ is really long in the tooth from a language design and tooling perspective. In that sense its due for disruption. So yes, it seems like C++ is on the way out.
On the other hand, Rust is not a strict upgrade. In game dev, runtime performance and iteration time are priorities. Safety is secondary. Rust isn't gaining that much ground in games because Rust appears to be unnecessarily burdensome. Async is especially useful for UI and game-thread style programming and that seems to be a weak spot of Rust as well.
There's still room for something besides Rust to steal C++ market share.
It will be faster than you think. At some point a big hack is going to occur and governments are going to step in and legislate to ensure it never happens again and we're going to have to rewrite everything written in C/C++ in safer languages. Rust and Ada are safe but I'm hoping something better comes along before the government steps in.
Am I the only one who loves writing C++? I've used some newer languages like Kotlin, and that's good too, but I always come back to C++. I think a lot of the criticism is from the old way it was written, before C++11/17.
C++ is a lot of fun, and there exist many compelling subsets, but the language as a whole is a minefield that you need years of experience to navigate, and probably can never master.
> the vast vast majority of c++ is just simple procedural code.
Probably because where C++ is needlessly complex, C is beautifully simple.
I've used both C and C++ in my career, spending 10+ years as a C programmer (kernels, applications and embedded stuff), as well as 4-5 years as a C++ programmer in a financial institution.
I find the thing most "new C/C++ programmers" complain about is memory management and type safety, but honestly, once you have a few years worth of experience, memory management is almost second nature. Most of the time i write the free() statement at the same time as i write the malloc() statement (if applicable).
One of the things I loved about Python when I learnt it was how it dealt with `public`\`private`\protected``. It was "we're all responsible adults. No need to hide anything. We'll just use a naming convention for members that we don't expect people to directly use."
"Enforce encapsulation" suddenly became. "Respect encapsulation" in my head and a bunch of Java/C++ problems evaporated.
I do love that about Python. The encapsulation is there but you can work around it if you’re willing to take responsibility for breaking the gentlemen’s agreement. That’s a lovely pattern.
I love it too, it tends to bend to my will, for better or worse. It feels like it doesn't stand in my way, and that further translates to feeling like there is nothing between my program and the hardware it runs on.
No need to school me on how that isn't true, I'm just describing my feeling and why I love C++.
I love C++, it was my next language after Turbo Pascal, there was a small stint with C, but already in 1992 it felt outdated.
However, during the last decade C++ culture suffered, probably it has taken too many C refugees.
What you call old way, it is still how many folks write C++ in big corporations, I tend to complain that I only see Modern C++ in conference slides, and my own hobby coding.
Tooling is a pain, packages are a pain, compiles are slow, the language is inconsistent, header files why..., the list goes on and on and its not outdated complaints.
I like the Betamax vs. VHS, X vs. Mastodon bit, because technically if you want a safe, high-integrity programming language today, you would choose SPARK2014, the Ada language that has a legacy of mission-critical real-world software projects for decades, proven verification tools and and it is easy to read and write. Rust gained favor with the tech crowd, while SPARK was being used in avionics, aerospace, and other high-assurance software. Why would you choose Rust a relatively new, unproven language (cite some mission critical software that has been running for a decade written in Rust besides a browser) for crypto, aerospace, AWS, and other critical areas? Programming language adoption is just as much about fashion as it is about a true pros/cons in tech.
I think the answer to “why” here is (and will always be) familiarity: Rust bears syntactic and semantic resemblance to already popular languages. Ada doesn’t to the same degree.
(This could be framed as a fashion choice, but I think the more neutral framing is precedence: Rust achieves desirable language-level properties without exhausting the novelty budget for people writing non-government software.)
> cite some mission critical software that has been running for a decade written in Rust besides a browser
This will be hard for anyone to do, given that Rust 1.0 was in 2015, so 9 years ago.
However, if you want examples of Rust running in mature, critical environments: my understanding is that Firecracker has been a key part of AWS’s serverless control plane for years now. Similarly, my understanding is that Windows has been shipping Rust in the NT kernel for the last year.
The root issue I have with this and many other articles is the false dichotomy around this vs that programming language.
I would feel comfortable interviewing for a Rust, C++, job, and probably a C, Pytbon position as well, just because the industry I'm in might require it.
For me, Rust has a size issue, its std lib after strip is at least 3x as to libstdc++, and Rust is default to statically link to that lib! When you have a few Rust binaries, the storage space adds up quickly, not a good fit for embedded boards where storage is limited(same problems for Go, by the way).
Why can't Rust have a mode to do what c/c++/etc doing, that is, a reasonably sized standard library to link to? Yes I'm aware of 'how to minimize rust size' and 'prefer-dynamic', still comparing to c/c++, it is so much worse when storage size is a concern.
I'm not very hopeful as it has been discussed in the past. If Rust will ever replace C++, binary size is one of its biggest weakness in my opinion.
Been safer is far from enough to replace the incumbent, you also need win in simplicity, speed, size, ecosystem,etc. Size at the moment is the most obvious problem as far as I can tell.
An increasing amount of AWS EC2 dataplane (Nitro firmware/software) is using Rust.
We hit this issue too, and our solution was to go busybox-style with binaries. One binary that then gets linked to with different names. Solved the problem for us.
"Popularity is the only thing that matters, and Rust is not popular enough."
What a fundamentally narrow and depressing point of view.
"Nobody gets fired for IBM" should not be an aspirational sentiment!
And the top comments take the first part axiomatically and only disagree on how (un)popular Rust is.
Lots of ideas and technologies can be useful and successful without becoming massively popular. There's a reason we don't all eat McDonalds and listen to Pop music.
So why shouldn't we expect the same from different ways of thinking about and practicing programming? It's clearly possible to be productive and effective in "unpopular" languages—I've seen it first-hand with OCaml and Haskell teams, and secondhand with lots of other tech—so why not encourage that? I'd rather have an industry that values good taste than slavish trend-following, thank you very much.
> What a fundamentally narrow and depressing point of view.
I want to get work done. Not be a part of some "software taste revolution." If you can't help me get my work done you're not on the list.
It's your point of view that is narrow. If popularity is not material then the loss of a single developer will have no impact and Rust will be the same as it ever was. Otherwise popularity matters and you should endeavor to observe and catalogs Rusts shortcomings so they can be addressed.
> If popularity is not material then the loss of a single developer will have no impact and Rust will be the same as it ever was
If lots of articles are written saying that popularity is all that matters, then people will start believing it, and it becomes a self-fulfilling prophecy. That's the narrowness.
I don't subscribe to this philosophy. People will repeat it in certain contexts to avoid sounding out of touch and incurring social bullying but I have genuine doubts that their beliefs can be so easily manipulated.
> and it becomes a self-fulfilling prophecy
If you do believe this then your answer is just to write a bunch of articles in the opposite direction. It's a gross sort of world to accept living in; though, this is probably why I hold the belief I've espoused above.
> "Popularity is the only thing that matters, and Rust is not popular enough."
This is unfair to the article, when the actual focus is on finding a job and paying the bills.
It doesn't have any of moral bankrupcy of the "Nobody gets fired for IBM" situation, where we'd be enabling corrupt companies because everyone else is also turning a blind eye.
If the post had just been "I'm doing C++ instead of Rust because I could find a C++ job but not a Rust job", that would have been totally reasonable and I would not have said anything. But that was not what the rant was saying—otherwise it would have been boring and not made it to HN and /r/rust.
Rust is extremely popular and is only getting bigger with every passing year. It's got incredible velocity and is about to break into the TIOBE top ten.
The Rust critics can't stop other people from using and enjoying it. It's unstoppable at this point.
> For higher level stuff (e.g.: web backends) Go offers faster iteration cycles than Rust
Rust is excelling in this space and in so many other use cases it was never originally imaged for. Have you seen the Actix/Axum adoption? It's insanely popular, and it's such a nice and low defect rate language to write web endpoints in. It's actually highly productive in this use case.
> Yes, Rust adoption is rising but competing technologies are also getting better
Other languages are not "catching up" on competing with Rust. Adding sum types is great, but that won't deliver the same benefits. Rust features make it fit into a truly unique space.
> a big push in advancing programming languages was the support of big corporations
No big companies using Rust? All of the big companies are using it!
> the first rule of Rust jobs is that no one talks about Rust jobs
> It's insanely popular, and it's such a nice and low defect rate language to write web endpoints in. It's actually highly productive in this use case.
I concur. Lots of folks here and elsewhere will make claims about how Rust isn't a good fit for this space because _it's a systems language_ or because the iteration cycle is too slow and it isn't meant to replace Python/JavaScript/whatever, anyways. To that, I call BS. It's (objectively) a general purpose programming language and can be used to do whatever you need it to.
To your point, I've also found it extremely productive for web development. Even if it does require more work up front, that's (usually) work you're not doing on the back-end chasing and squashing bugs or trying to cover corner cases which you hadn't accounted for -- but the Rust compiler would have.
> What a fundamentally narrow and depressing point of view.
Maybe not for you HN patricians, but most regular people in the world want stability and have other immediate priorities far above becoming a programming language revolutionary.
TRACTOR seems like a helluva Hail Mary. The C and C++ abstract machine had so many sharp pointy bits that need to be reified exactly that I find it hard to translate to Rust.
Whoever wins it (not sure if they’ve announced it yet?) will be doing God’s work but it feels like an enormous undertaking. And I sometimes like these DARPA-hard projects.
You can make a pointer-based graph structure with cycles in C++ without a fuss. You can decide how the memory managed and implement exactly that with minimal barriers in your way.
The language seems to be heavily branding itself as "data-oriented", mentioning it front and center on the website and repo, but never mentions in the docs what makes it data-oriented, or what it even means by that. Is it data-oriented in the Clojure sense, in contrast to "place-oriented"? Or is it data-oriented as in programming with tables of rows, or something else?
Aren't Rust compiles slow as well? I'm suggesting they take a different approach. Are these systems really needed seeing as other languages do without?
Other languages don't do without them, the costs are just worse in Rust (and C++). Go for example consciously tried to avoid shipping generics and was forced to implement them by community pressure. They now pay the same kinds of monomorphization costs as C++ and Rust because the alternatives have greater runtime costs. Go is simply a faster-compiling language overall though and the problem is less noticeable. Macros are similarly ubiquitous in other functional languages, but most of them aren't compiled or meaningfully optimized.
Rust is complex, highly expressive, and does a lot of optimization. None of that's good for compile times. C++ is even worse because of how awful the template abuse gets and the amount of duplicated code that's fed into the compiler from how #includes work.
Is C++ easier to prototype in? Of course there's the borrow checker, but I feel like Rust at least shows up with some expressiveness niceties that gets you some productivity wins in the prototyping stage.
Though really I suppose "comfort with a language " is such a big factor, seeing people really belt out stuff in C is always a bit impressive to me (yeah yeah, bug filled etc)
C forces me to do the barest minimum and avoid prematurely astronaut architect everything. That often makes it faster to prototype in. Not because I can do more. But because I have to reframe the problem so it fits.
But large codebases in C are tedious to work with and slow to refactor.
Safe programs extend beyond those that Rust's borrow checker accepts though. There is more than one way to make a program safe, not all of them would be valid Rust.
There are more than one way to achieve safety in Rust. Two more, infact - runtime safety and fully manual (unsafe with some additional work). Runtime safety is a very fast way to overcome the resistance offered by the borrow checker. While it does slowdown the code a little bit, that should be pretty fine for prototyping. A more careful use of runtime checks will still give you a program more performant than in most other languages.
Runtime safety still comes with a good amount of complication source-wise, having to spam RefCell/Arc everywhere, and whatever derefs/.get()s they necessitate, and probably a different approach to passing references. Refactoring either that or unsafe away after being done with prototyping isn't trivial, if even possible without entirely rethinking the approach.
Isn't that a bit dramatic? How much extra code or care do you need to implement runtime safety checks? This isn't the first time I hear these sort of arguments either. It gives the impression that a crowd is making up one exaggeration after another to drive the perception that Rust is somehow not suitable for general purpose programming.
It is a bit dramatic, though less so for some approaches to programming. And of course prototyping is very different from general purpose programming.
With Rust, if you really want the borrow checker to actually never bother you, you really do just have to spam the dynamically-checked wrappers everywhere; when in the groove, having to stop and wrap some existing field (or its holder) and all its usages just to be able to mutate it because you previously didn't think you'd need to is just completely awful if you don't find that "fun".
Whereas in C, if you want to mutate a thing, you can always do so whenever with no concerns (whereas using unsafe to mutate a field of a &Thing in Rust is just UB, though maybe you can get away with using unoptimized builds for a bit) and deal with previous code that may have been written with the assumption it wouldn't change Later™ (but, importantly, still allowing properly testing the modified thing, and perhaps the entire project). Want to change the lifetime of a thing? Just move where you free it, no need to ever change lifetime args across a dozen functions. And in Java the most anything may take is removing a "final" on a field.
If you remove "develop" from the OP and stick to "prototype", it's a totally valid criticism, and you come across as a condescending jerk if you suggest that software can't be "working" unless it's bug-free.
I can't count the number of times I've wanted to try out some library and whipped up a quick prototype app in an hour or two to play around with it. I don't give a damn if that app is memory safe, handles signals safely, satisfies arcane aliasing rules or deals with any of the other million footguns in C/C++. I'm happy if it compiles and does what I want it to. I deal with that stuff when I inevitably rewrite it from scratch the next day and have an actual design in mind.
FWIW, I'm comfortable enough with Rust that I would personally choose it over C or C++ for most stuff like this these days since the standard library makes a lot of boilerplate prototyping stuff (e.g. setting up a project, pulling in dependencies, handling files and I/O) much more pleasant. But suggesting that anyone who writes unsafe C/C++ in any context doesn't know what they're doing is ridiculous.
I used to work on a product that handled video, and I would regularly spin up prototypes where I’d stitch together gstreamer pipelines with different plugins to try things out. For reasons that aren’t important, it was easier to use an app linked against the gstreamer libraries than to use its CLI.
There were all sorts of ways I’d evaluate some plugin I was trying out. Maybe I’d look at some test pattern for artifacts. Maybe I’d measure latency. Maybe I’d profile its resource usage. But I can confidently say that in all of those cases, the memory safety of the 100 lines of C++ code that told gstreamer how to plug things together had absolutely no impact on what I was evaluating.
Sometimes the code you’re writing is basically unrelated to what you’re interested in from a prototype.
Working software doesn’t always have to be correct or safe. This is highly use case dependent. Rust’s guarantees aren’t free, it comes with a handful of tradeoffs, such as learning curve, implementation speed, (this one is personally annoying) compilation speed, and portability. I’m a huge proponent of using the right language for the job. Sometimes rust is the obvious choice, sometimes it’s Python, Go, Lua, Java, Prolog, C, brainfuck etc.
> Working software doesn’t always have to be correct or safe.
I feel like I am missing some very obvious point of yours because that statement in isolation I cannot agree with (I've read the rest of your comment and still can't find the extra context). Can you clarify?
Isn't that just D? No one uses D not because it's a bad language, but because the actual language isn't nearly as important for adoption as the community behind it.
Develop? Debatable. At a certain scale of project, all the static guarantees become quite helpful. And a "prototype" written in Rust is often much closer to production-ready than you might think. Rust makes it easier to see which corners you've been cutting than most languages.
Apple is positioning Swift as this (and are also moving it from Apple's space on Github etc. into its own and gradually trying to build more of a community), so I wonder if it will catch on more. If people are already using it in the app space, it might be able to branch out into other areas.
Over the last year and a bit they've also been working on strong C++ interop to be able to start using it in their own projects without having to do rewrites, and also better cross-platform and static linking support on Linux which could all make it a lot more attractive.
(For context, like Rust, Swift is both memory safe and data-race safe)
Swift uses garbage collection (I know, arc, but that's still garbage collection), so it more or less is in the same category as Go. And I don't see people choosing Swift over Go any time soon.
I have written no less than 20 hobby mini-projects with Go but it's hardly an alternative to Rust. They serve fairly different purposes. Sure you can write almost any project X with either language but most of the time Go or Rust would be a bad fit for project X and a near-perfect fit for project Y.
Highly loaded network backbones come to mind. At one point almost every GC language starts to struggle.
I've written Rust services in financial companies and it maintained stable memory footprint and near-nonexistent higher P95 latency... for months without restarts.
Your second paragraph: I expect that this must be a microscopic part of their total source code footprint. Is the software used for (equity/futures/options) exchange connectivity? (Oh no, please don't tell me "crypto".) I cannot think of anything else that would warrant the investment in the 2020s.
Depends what you mean by microscopic. If the entire project is a traffic forwarder, proxy, firewall-like, dispatcher / router etc. then that's the heart of the project and having the performance benefits of Rust there is absolutely crucial.
It was not only crypto. We're also talking telecom nodes and there are a lot of different protocols and needs around them (I was surprised how many, and some telecoms are finally waking up to the 21st century and started utilizing proper containerization and virtual networks to enforce compartmentalization / isolation / security).
On the broader topic: nowadays I default to Golang due to its better productivity and shorter dev iteration cycles, for what it's worth. However, there are projects where picking Golang over Rust would be irresponsible. Not the majority of all projects out there, absolutely, but there is an important subset that cannot be ignored.
PERSONAL NOTE: Sadly most of us will never work on those, and I am trying hard lately to change that for myself. Sick of web dev, I started hating it so much that I can do it extremely efficiently and almost with my eyes closed but I still can't forever ignore my needs; we are creative creatures and forcing ourselves to be assembly line workers only leads to spiritual and mental health death.
I was thinking about this earlier today. I decided, albeit probably in a manner way too naiive... use Go if you want to write an app and use Rust if you want to write a program.
I don't have your context so I'm not sure what you mean but in general, it's rather easy to write a web backend with Go, yes. And Rust is a very good fit for many types of servers.
I love Go, but they are not really interchangeable. If you do systems programming and you need a very low-level language, Go is not a good alternative. Though if we are talking about more high-level applications like web servers, then I totally agree.
That 90% is moot if you're trying to replace C++. Rust is a better fit than Go. Granted that Go iteration times are better. But Rust is by no means just a low level language. The abstractions in Rust are fantastic. They feel very ergonomic and high level. I think the real problem with Rust is that many people can't come to terms with the borrow checker. It's whole another skill set to know what the BC is trying to achieve, how to solve BC errors and the alternatives available when you can't. Once you know that though, Rust feels very productive - even extremely helpful in resolving problems in advance.
Believe it or not it’s possible, even desirable, to use an appropriate solution to the problem at hand, rather than treating everything as a nail just because you’re find if your hammer.
That argument is selectively and rather condescendingly applied to Rust far too often. In this particular context (both the parent comment and the article), that criticism should apply more to Go than to Rust. Besides, I don't understand the argument of asking everyone to learn a dozen different languages for an 'appropriate solution at hand' when the differences between them don't justify such effort. I don't dislike Go. But it's disingenuous to argue that Rust shouldn't be used where Go can be.
Besides few areas, Go is a backwards language. I'd rather use F# or Kotlin. And for performance with GC escape hatch it's borderline impossible to beat C#.
Another commenter mentioned the NSA and safe languages, which is what prompted our move...
...and I have to say, Rust is fantastic. I was reading the O'Reilly book when I was doing some gnarly three-star C work and I kept thinking that it would likely be far easier and safer in Rust.
We're now at the point where all new work is Rust and that gnarly, performant AF piece of C that just flies will be replaced with a simpler, safer Rust version.
Another commenter mentioned speed of prototyping. That was a concern for me, too, but so far real life has shown me the opposite: prototyping is only slightly slower, mostly because I am having to learn various Crates instead of using system calls and their libc variants I've known for years, but incremental debelopment from proto to poc to mvp to product is faster because there is far less dumb at each step: if it built, it is safe(r) to extend.
Maybe it is because so much of what we do is low level high performance system programming, I dunno, but, after 37 years, I may soon have invoked a C compiler for the last time.
> I don't think the goal of Rust has to be to unseat C++
Agreed, but it's also true at the same time that projects you would choose C++ for are also very legitimate candidates for Rust. So they are competing, even if that's not the goal of both communities.
> be a language that users and non-users believe is better
Well, lately one person that contributes Rust to the Linux kernel got attacked with ridiculous screaming like "you will never force us to use Rust!" -- and he never did that. So he (or was he somebody else? can't remember now) basically stepped down because it turned out that nobody could challenge his technical work so they started attacking him on every other platform. Inevitably, you get enough of this and want to be left alone. Sad... but that's humans apparently.
As for non-users, even more difficult. But having studies like those of Microsoft and Google that clearly demonstrate that between 60% to 75% of all CVEs are due to memory unsafety, helps a lot.
> be a language that people learn things in before entering the industry
That one is needlessly difficult because a lot of professors are stuck in the early 2000s. Read: they only know Python or JS or Java or C# and they will never learn anything else. Young minds are impressionable so these fossils only perpetuate the problem of indoctrinating people and preventing them from utilizing the innovations in the PL area.
> be a language for solving important problems, if not every problem
Too generic to work, I am afraid. :/
You'll find people on HN arguing that you can solve every problem in the CS area just fine with Brainfuck and that we are all brainless lemmings for not seeing the light. Now replace that language with literally every other and you'll still find people saying the exact same thing...
> if a billionaire buys C++ and makes it terrible, be an alternative
That one is not so bad IMO, be it Rust or any other language really. If this happens the community will still push to do things like they want to, ultimately resulting in a fork if the buyer is stubborn enough.
No money in the world can make people suddenly write terrible code if they are passionate about doing the opposite.
> The majority of the Rust programming jobs asks primarily for deep knowledge in specialized technologies: cryptocurrencies/blockchain, finance trading, machine learning/data analysis, obscure network protocols, cybersecurity, etc.
I agree, but that's a lot of fields and C and C++ jobs ask for the same: finance trading, videogames, machine learning, electronics, legacy protocols, etc. So I don't see how this is unique to Rust but doesn't apply to C++.
Yeah I see very few and far between job offers for Rust but I can say the same for C or C++, and new companies are using Rust not the former languages. Maybe it's easier in the USA.
Usually C or C++ jobs ask for embedded knowledge, whereas Rust ones don't.
What country are you looking in? Everything I’ve seen (US) is like the linked post describes. There’s a fair amount of C or C++ jobs, while the Rust ones are all either crypto startups or extremely specialized (5 years professional rust experience plus 10 years professional Linux kernel development experience, or 4 years professional rust experience plus 8 years compiler development experience, stuff like that).
For personal projects, I use C because it is fun and brings me joy without getting in my way, while Rust brings me pain, and (when i must seek help) derision from the community. Here, I choose fun and joy.
For work I use C because that is what all existing non-toy kernels are written in and will continue to be written in until long after i've retired, been buried, and decomposed. Here, i choose what employers want and will pay for.
Meh, I'll take his closing advice.
If this were written in 2018 i might agree. Rust is currently exploding, however.
C++ is footgun central, which is the opposite of typesafe.
Go doesn't care about typesafety, and had it's heydey already.
Rust is eating everything in 2024.
People have begun to appreciate an approach to maintaining comprehensive typesafety from the db to user input.
Rust is capable of holding much info about what it specifies, and is basically lossless as a specification.
Rust is already eating the world, it just took a couple of decades of committee bikeshedding to achieve it.
People are starting to understand why typesafety matters, as they flail around in bug soup.
At the risk of dating myself, I suspect the author of that self-described rant either has forgotten how long it took for C++ to mostly dethrone plain C, and perhaps practically more relevantly, how painfully long it took for new versions of C++ to be widespread enough that people dared to rely on them. This stuff isn't easy at scale; adoption is slow.
Doesn't mean rust will ever grow like that, but merely slow adoption doesn't sound like a death knell by itself to me.
100% this. It's still absurd to me how codebases in some industries are still basically C++98 and haven't even begun to transition to at least C++17 (which forces new code that adds or changes features to be written C++98-style as well).
Hard to imagine those companies switching to a different language anytime soon. Maybe the new US government push towards "memory safe" languages will help with that.
I think Go thrives in a much more popular field (web services, etc.) and it's also designed to be easy to pick up so I'm not surprised this was the case.
1.0 was in May of 2015, but that was closer to an MVP with stability guarantees than the full language. It wasn't until 2018 that Rust was as usable for most tasks. Everything you might have learned back then is still available, just a lot of restrictions have been removed, and there are more to come.
"There is an huge junkyard of technologies that failed to gain broad acceptance, many of them far more revolutionary than Rust (e.g.: Lisp, Smalltalk). I don't see why those technologies' story can be avoided."
Yeah, but I think more importantly much of the value that Rust brings would have been available 30 years ago if language development/selection wasn't so siloed, full of biases, and driven by (often undeserved) popularity.
As someone who is fascinated with Smalltalk and to a lesser extent Lisp. I think the reason those didn't catch on more broadly is that they were too early and different.
Smalltalk I believe was designed to run on computers that wouldn't be around until the 90s and and when the 90s arrived it didn't have a big company pouring gobs of money into marketing it unlike Java. There are other factors that also contributed it's unpopularity. Like who wants to distribute a whole system for each smalltalk program they sell?
I think also Lisp and APL weren't designed to run on the weak PCs in their day. You needed to use a timesharing system to program in them.
I think it already has. It just isn't very visible to us. Rust becomes easy (especially the borrow checker) once you know how the hardware works. This is unfortunately true for even non-system programming in Rust. However, those who deal with hardware - OS devs, web engine devs, DB engine devs, etc - can see the problem and appreciate what Rust offers. That's why we see big companies like Microsoft, Google, Amazon and even Apple adopt Rust quickly. It's just not visible to us on the surface.
(1) You need to either hire or train someone to write in Rust, and neither is trivial amount of effort. And at the end of the day, you need to push features out. Let's be real: you can find someone to write JavaScript to do full stack development, anywhere in the world, for a cheap price. Rust? The code may be more robust and easier to maintain in the long run, but it's hard to do that unless you already set up a team for that.
(2) Most software companies don't actually care that much about the language they use, the tech stack, or their infrastructure in general. Remember there are lots and lots of software companies that are not Google/Meta etc, and they are not at the bleeding edge of have state-of-the-art infrastructure. Saying that as someone working at a company with thousands of developers, and there are millions of old, ugly, almost unmaintainable Perl code in our core infrastructure running right now. From outside, it all looks fine.
How many wildly successful finance firms are running COBOL somewhere on the backend? How many successful healthcare systems are running MUMPS? Bad languages don't seem to kill companies, just make disgruntled developers and bad products.
Funny enough, there's a bunch of Javascript tooling for which being written in rust, as opposed to thee one they are replacing written in js itself, is their competitive advantage.
Not necessarily. To me the actual advantage is that they are times, if not tens of times, faster than the semi-equivalent JS tool.
People love to downplay long startup times or longer runtimes ("Who cares if it takes 1s to start?" and "It takes 17s vs. 1s, big deal, you are overreacting!") but it does add up with time and makes people dissociate and stop caring. I've seen it (and it happened to me as well).
There's a huge amount of legacy code that cannot be replaced overnight. There's thousands of person-hours invested in such codebases and they need to be maintained. There's also a much greater number of experienced C++ programmers available versus Rust programmers with the same level of experience (especially working experience, not just the language itself), so that's another factor.
So companies with lots of earning potential in greenfield projects might indeed have a competitive advantage, while it's more difficult for those with products that have a large existing C++ codebase.
If I created the perfect language tomorrow the very first problem is that absolutely nobody would have any experience in it.
It would also have no other ecosystem. No books. No tutorials. No mentors. No libraries. No frameworks.
And even as it got those things, they would remain immature and incomplete for a long time when compared to the ecosystem around languages that are decades old.
I could also make an operating system that was superior in every way and it would fail because there would be no apps for it.
In other words, it wouldn't be superior according to the way I understand it. Learning curve, existing libraries and solutions all matter in this comparison..
For me it'd have to interact seamlessly with other languages and enable incremental adoption, otherwise you can't swap one with another.
But you can swap a floppy disk with USB flash drive if the PC has an USB port, so that's what I mean by superior..
Your original premise is flawed; there can never be language that is superior in every aspect. Almost everything is a trade off. A technology that is good for one purpose might be wrong for another and vice-versa. Also a new language will always start with no adoption, no experts, and no libraries so that is also a trade off.
A language that allows incremental adoption will necessarily be limited by that necessity -- another trade off.
When USB was new very few computers had USB ports but nearly all computers had floppy drives. Floppy disks were cheap and flash drives were expensive. If your purpose was to share data then using a USB Flash drive at that time was an inferior experience. If you had a lot of data, a writable CD was a much better choice. If there was ever a period that USB drives were supreme for that task, it was brief. With higher speeds and greater adoption, it quickly became much better to use the Internet to exchange data.
Maybe. The writer notes other technologies that were superior (on some axis) and won second place:
> But Rust is better in the same way that Betamax was better than VHS, Mastodon is better than Twitter, Dvorak keyboards are better than QWERTY, Esperanto is better than English and Lua is better than Javascript
As I understand it, the advantage of Dvorak was that in the study that promoted it, the Dvorak people got retraining and the qwerty people were taken as is.
Once both sets were sent through training, the Dvorak advantage disappeared
What is your comment directed at? If it's the article, I don't see hate. OP professed their love for Rust, but explained why they're moving on to C++. Mainly skepticism that it'll ever cross the chasm into mainstream.
>But Rust is better in the same way that Betamax was better than VHS, Mastodon is better than Twitter, Dvorak keyboards are better than QWERTY, Esperanto is better than English and Lua is better than Javascript: in communication technologies, adoption and critical mass are 90% of the game and the other 10% are bikeshedding, at best. And programming languages are a communication technology, they're means to communicate ideas to other programmers.
Love this. May be I should repost this every time there is an argument about Rust. And to expand on that, in communication technology, the one easier to use is going to get wider spread / adoption. And while there were never much hype around Go, I think it is a very good example.
But a lot of Rust [1] ideas are now being polished and used elsewhere like Swift. I am sure we will continue to be experimented in other languages and real world to test whether the trade off is worthwhile.
[1] ( ok may be Cyclone or something earlier in case someone wants to nitpick )
reply