16 ms·

Goodbye, Rust. I wish you success but I'm back to C++ (sorry, it is a rant)

265 points by veidelis 2y ago

joshdavham 2y ago
> the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have Let’s check back in a couple of years!
- goku12 2y ago
  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.
skobes 2y ago
> And the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have. Isn't this premature? Rust is still pretty new.
- dotancohen 2y ago
  > Isn't this premature? Rust is still pretty new. The old lady said both those things to me this week. In two different conversations.
- causal 2y ago
  It is premature. And furthermore, adoption will mostly be driven by new projects written in Rust, not conversion of C/C++. That takes time.
  - emn13 2y ago
    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.
    - qayxc 2y ago
      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.
      - tonyedgecombe 2y ago
        >Maybe the new US government push towards "memory safe" languages will help with that. That could be a whole new year 2000 thing. It would get the programming world out of the doldrums it seems to be in at the moment.
- orbat 2y ago
  It's not that new; nearly 10 years old now I think. Go's adoption was faster
  - dysoco 2y ago
    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.
  - deleted 2y ago
    [deleted]
  - rahkiin 2y ago
    Isnt the first stable language version from 2018?
    - steveklabnik 2y ago
      May 2015.
    - estebank 2y ago
      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.
devnullbrain 2y ago
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.
- causal 2y ago
  Why would staying on top of Rust put you out of a job?
  - Twirrim 2y ago
    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.
  - quickslowdown 2y ago
    The Rust language is what he's saying will put him out of a job, over tim as it replaces C (the language I'm guessing they work with professionally).
- AlotOfReading 2y ago
  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.
causal 2y ago
This is kind of silly to me. You don't have to break up with Rust to use C++. Look for opportunities to adopt Rust, especially greenfield projects. We don't have to eliminate all C++ codebases first.
- tayo42 2y ago
  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.
  - pdimitar 2y ago
    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.
    - goku12 2y ago
      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.
      - pdimitar 2y ago
sedatk 2y ago
TL;DR: “Rust isn’t popular enough”
dysoco 2y ago
> 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.
- ndiddy 2y ago
  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).
zb3 2y ago
If Rust was really that superior, would companies using it not have a competitive advantage in the market?
- PLenz 2y ago
  Languages are fungible at most scales
  - Joel_Mckay 2y ago
    Most languages exhibit Isomorphism, and necessarily so... People are happy in Ivory towers, and often ignore better high-level llvm compiler options. =3
- criddell 2y ago
  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
- qayxc 2y ago
  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.
- AlotOfReading 2y ago
  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.
librasteve 2y ago
goodbye raku, it’s back to perl
whatyesaid 2y ago
Rust is slow to develop and prototype in. It's good if you're a big company not the average Joe. We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.
- Philpax 2y ago
  If it's optional, people are unlikely to use it, and we'll be back at square one again regarding pervasive memory safety issues. That being said, keep an eye on Carbon.
- devnullbrain 2y ago
  If the borrow checker slows you down, the C++ you write instead would just be buggy
  - tylersmith 2y ago
    [flagged]
    - mkipper 2y ago
      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.
fny 2y ago
I deeply appreciate the mood, but when the NSA started pushing memory safety and TRACTOR launched, I doubled down.
- mattgreenrocks 2y ago
  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.
astonex 2y ago
Just give me a modern C++ like language with fast compilation, easy to pull in packages, and build tooling. Basically Go with no GC.
- pjmlp 2y ago
  Check Odin.
  - joshlemer 2y ago
    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?
    - dgellow 2y ago
      https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design
- throwaway2037 2y ago
  How is fast compilation possible with C++-like templates? That seems impossible.
  - jayd16 2y ago
    So redo the templates.
    - AlotOfReading 2y ago
      They did, hence concepts and constexpr. Rust has more powerful versions of both in traits and macros.
romarioj2h 2y ago
[flagged]
- mekoka 2y ago
  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.
azangru 2y ago
> 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.
- david-gpu 2y ago
  > Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript Doesn't that depend on how one decides to "score" a language? And I think that's what the author is getting at, too.
  - flysand7 2y ago
    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.
    - david-gpu 2y ago
      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.
  - coldtea 2y ago
    >Doesn't that depend on how one decides to "score" a language? Not as much, because not all ways of scoring a language are as good either, and in the ways of scoring that matter, English is better than Esperanto.
cedws 2y ago
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.
- stefanos82 2y ago
  > 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.
  - pdimitar 2y ago
    > if it ain't broken, don't fix it! All the CVEs found in the last several years would like a word with you.
    - AnimalMuppet 2y ago
      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.
      - 8fingerlouie 2y ago
deleted 2y ago
[deleted]
catlifeonmars 2y ago
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.
- pdimitar 2y ago
  > Weighing the pros and cons of a particular language without specifying the use case and project requirements seems ass backwards to me. Practically every company I talked with about Rust positions named very good reasons to move to it. N=1 and all, yup, but your opinion is N=1 as well. There are several very engineering-sound reasons to choose Rust and people are aware of them and are appealing to them when considering it.
- dartharva 2y ago
  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).
- b0rsuk 2y ago
  [dead]
- fargle 2y ago
  > 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? you could just as easily say "goodbye allen, but i'm going to torx" or any <insert-things-here> pair. it's only silly if both of the interlocutors happen to agree on the relative merits and that the difference is large enough to be called "silly". the problem is responses like that amplify the vibes of "well, it's clear that everyone agrees that rust/phillips is just objectively better in all ways". i don't think this discussion would be occurring if that were true. the right thing is to drill down into the specific trades, and i'm scratching the surface. oh, you have a greenfield project where manual memory management in C or C++ is burdensome and error prone and it's kicking your butt. perhaps rust might be a good fit? or perhaps you have a problem where you need to maximize the code interchange with a few million lines of existing code and a large set of existing experienced developers? well, maybe not then...
rezmason 2y ago
I don't think the goal of Rust has to be to unseat C++, just like the goal of Macs is no longer to unseat Windows. Here are some nobler goals: * be a language that users and non-users believe is better * be a language that people learn things in before entering the industry * be a language for solving important problems, if not every problem * if a billionaire buys C++ and makes it terrible, be an alternative Edit: unrelated— I really struggle with writing lists on HN. :-(
- pdimitar 2y ago
  > 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.
tschellenbach 2y ago
come to the land of no drama, no changes and always productive Go :)
- tail_exchange 2y ago
  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.
  - TylerE 2y ago
    I could argue that at least 90% of software does t need a very low level language.
    - goku12 2y ago
      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.
      - TylerE 2y ago
        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.
        goku12 2y ago
        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.
deleted 2y ago
[deleted]
PeterWhittaker 2y ago
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.
npalli 2y ago
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.
- Tuna-Fish 2y ago
  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.
- brson 2y ago
  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.
- bryanlarsen 2y ago
  The disadvantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything. The advantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything.
  - echelon 2y ago
    Why would you want a refactor into a broken state? You always need to figure out how much you're going to bite off with each refactor. It's usually possible to do things incrementally.
ksec 2y ago
>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 )
- synergy20 2y ago
  Golang is not much more widely used comparing to rust? both are 17+ years old and they're around 2% of the market.
  - serbuvlad 2y ago
    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.
jksmith 2y ago
"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.
- bobajeff 2y ago
  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.
  - igouy 2y ago
    > ... when the 90s arrived it didn't have a big company pouring gobs of money into marketing it unlike Java. IBM not big enough? :-) But of course IBM's consulting group were technology neutral and pivoted from Smalltalk to Java when the wind changed. > Like who wants to distribute a whole system for each smalltalk program they sell? Smalltalk was marketed to corporations as a 4GL replacement for green screen systems. So enterprise wide client-server apps for insurance/reinsurance, call center outsourcing, assembly line control, options/derivatives/reconciliation, ERP CRM TLA TLA, etc etc I don't claim to have been in "The Room Where It Happens" meetings, so I'll just say that from my lowly perspective during that period Allen Wirfs-Brock's comment ring true. https://wirfs-brock.com/allen/posts/914 https://wirfs-brock.com/allen/posts/914
tikhonj 2y ago
"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.
- echelon 2y ago
  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 There are Rust jobs! I'm hiring Rust devs.
  - ethagnawl 2y ago
    > 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.
srj 2y ago
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.
- MathMonkeyMan 2y ago
  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.
  - nightowl_games 2y ago
    Kinda. The vast majority of c++ I encounter is simple orthodox c++. No one I know cares about new features in c++ and bemoans having to ever write a template. No one really cares about bulletproofing types, ie: copy/move constructors and all that stuff. I'm sure it's different at big companies but the vast vast majority of c++ is just simple procedural code.
    - 8fingerlouie 2y ago
      > 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).
      - weebull 2y ago
        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.
eggy 2y ago
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.
- woodruffw 2y ago
  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.
jvanderbot 2y ago
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.
ppp999 2y ago
[flagged]
synergy20 2y ago
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.
- robertlagrant 2y ago
  Maybe it can. Why don't you propose[0] a list of features that would fit your requirements? You never know! [0] https://lang-team.rust-lang.org/how_to/nominate.html https://lang-team.rust-lang.org/how_to/nominate.html
  - synergy20 2y ago
    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.
- zozbot234 2y ago
  Did you try https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust ?
  - synergy20 2y ago
    yes as mentioned,it's still too large compared to c++ when i have multiple executables
- yolovoe 2y ago
  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.
fsckboy 2y ago
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. edit: thought of one, the soles of shoes
- pornel 2y ago
  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.
kazinator 2y ago
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.
- an_d_rew 2y ago
  True... but whether the ability to so is a superpowers strength or a debilitating weakness depends on both your values and point of view!
dmitrygr 2y ago
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.
- johnnyanmac 2y ago
  > i choose what employers want and will pay for. with the US mandate away from unsafe languages, that may change faster than you think. Unless you are already quite close to retiring.
  - dmitrygr 2y ago
    Mandate? When did the president sign a law written by congress banning C? And even then, the courts have ruled programming as speech, so first amendment applies. I’m not even remotely considering the possibility of letting the thought of pondering maybe worrying cross my mind here.
    - deleted 2y ago
      [deleted]
    - johnnyanmac 2y ago
      Mandate is a strong word, but this month: https://news.ycombinator.com/item?id=42013379 https://news.ycombinator.com/item?id=42013379 "For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by Jan. 1, 2026, is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety," Obviously they can't ban a language. But if you work in the public sector, are a defense contractor, or otherwise have companies which do or want to do work for the government (which yes, includes most FAANGs), this will influence quite a bit of decisions in the US tech industry.
readthenotes1 2y ago
"Dvorak keyboards are better than QWERTY," 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
ribadeo 2y ago
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.
shoulderfake 2y ago
[dead]
AstralStorm 2y ago
About the only remaining issues I personally face is the suspicious lack of plotting libraries, and bit of an insufficiency in maths libraries, especially for higher level operations than just linear algebra. There's no scipy, numpy and matplotlib equivalent yet. Both C and C++ do better in this particular area... Peroxide is a good start, but it cheats much like scipy by calling into Fortran, while having some very pecuilar APIs thanks to that.

265 points by veidelis 2y ago

> the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have Let’s check back in a couple of years!

goku12 2y ago
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.

skobes 2y ago

> And the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have. Isn't this premature? Rust is still pretty new.

dotancohen 2y ago
> Isn't this premature? Rust is still pretty new. The old lady said both those things to me this week. In two different conversations.
causal 2y ago
It is premature. And furthermore, adoption will mostly be driven by new projects written in Rust, not conversion of C/C++. That takes time.
- emn13 2y ago
  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.
  - qayxc 2y ago
    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.
    - tonyedgecombe 2y ago
      >Maybe the new US government push towards "memory safe" languages will help with that. That could be a whole new year 2000 thing. It would get the programming world out of the doldrums it seems to be in at the moment.
orbat 2y ago
It's not that new; nearly 10 years old now I think. Go's adoption was faster
- dysoco 2y ago
  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.
- deleted 2y ago
  [deleted]
- rahkiin 2y ago
  Isnt the first stable language version from 2018?
  - steveklabnik 2y ago
    May 2015.
  - estebank 2y ago
    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.

devnullbrain 2y ago

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.

causal 2y ago
Why would staying on top of Rust put you out of a job?
- Twirrim 2y ago
  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.
- quickslowdown 2y ago
  The Rust language is what he's saying will put him out of a job, over tim as it replaces C (the language I'm guessing they work with professionally).
AlotOfReading 2y ago
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.

causal 2y ago

This is kind of silly to me. You don't have to break up with Rust to use C++. Look for opportunities to adopt Rust, especially greenfield projects. We don't have to eliminate all C++ codebases first.

tayo42 2y ago
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.
- pdimitar 2y ago
  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.
  - goku12 2y ago
    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.
    - pdimitar 2y ago

sedatk 2y ago

TL;DR: “Rust isn’t popular enough”

dysoco 2y ago

> 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.

ndiddy 2y ago
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).

zb3 2y ago

If Rust was really that superior, would companies using it not have a competitive advantage in the market?

PLenz 2y ago
Languages are fungible at most scales
- Joel_Mckay 2y ago
  Most languages exhibit Isomorphism, and necessarily so... People are happy in Ivory towers, and often ignore better high-level llvm compiler options. =3
criddell 2y ago
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
qayxc 2y ago
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.
AlotOfReading 2y ago
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.

librasteve 2y ago

goodbye raku, it’s back to perl

whatyesaid 2y ago

Rust is slow to develop and prototype in. It's good if you're a big company not the average Joe. We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.

Philpax 2y ago
If it's optional, people are unlikely to use it, and we'll be back at square one again regarding pervasive memory safety issues. That being said, keep an eye on Carbon.
devnullbrain 2y ago
If the borrow checker slows you down, the C++ you write instead would just be buggy
- tylersmith 2y ago
  [flagged]
  - mkipper 2y ago
    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.

fny 2y ago

I deeply appreciate the mood, but when the NSA started pushing memory safety and TRACTOR launched, I doubled down.

mattgreenrocks 2y ago
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.

astonex 2y ago

Just give me a modern C++ like language with fast compilation, easy to pull in packages, and build tooling. Basically Go with no GC.

pjmlp 2y ago
Check Odin.
- joshlemer 2y ago
  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?
  - dgellow 2y ago
    https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design
throwaway2037 2y ago
How is fast compilation possible with C++-like templates? That seems impossible.
- jayd16 2y ago
  So redo the templates.
  - AlotOfReading 2y ago
    They did, hence concepts and constexpr. Rust has more powerful versions of both in traits and macros.

romarioj2h 2y ago

[flagged]

mekoka 2y ago
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.

azangru 2y ago

> 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.

david-gpu 2y ago
> Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript Doesn't that depend on how one decides to "score" a language? And I think that's what the author is getting at, too.
- flysand7 2y ago
  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.
  - david-gpu 2y ago
    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.
- coldtea 2y ago
  >Doesn't that depend on how one decides to "score" a language? Not as much, because not all ways of scoring a language are as good either, and in the ways of scoring that matter, English is better than Esperanto.

cedws 2y ago

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.

stefanos82 2y ago
> 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.
- pdimitar 2y ago
  > if it ain't broken, don't fix it! All the CVEs found in the last several years would like a word with you.
  - AnimalMuppet 2y ago
    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.
    - 8fingerlouie 2y ago

deleted 2y ago

[deleted]

catlifeonmars 2y ago

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.

pdimitar 2y ago
> Weighing the pros and cons of a particular language without specifying the use case and project requirements seems ass backwards to me. Practically every company I talked with about Rust positions named very good reasons to move to it. N=1 and all, yup, but your opinion is N=1 as well. There are several very engineering-sound reasons to choose Rust and people are aware of them and are appealing to them when considering it.
dartharva 2y ago
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).
b0rsuk 2y ago
[dead]
fargle 2y ago
> 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? you could just as easily say "goodbye allen, but i'm going to torx" or any <insert-things-here> pair. it's only silly if both of the interlocutors happen to agree on the relative merits and that the difference is large enough to be called "silly". the problem is responses like that amplify the vibes of "well, it's clear that everyone agrees that rust/phillips is just objectively better in all ways". i don't think this discussion would be occurring if that were true. the right thing is to drill down into the specific trades, and i'm scratching the surface. oh, you have a greenfield project where manual memory management in C or C++ is burdensome and error prone and it's kicking your butt. perhaps rust might be a good fit? or perhaps you have a problem where you need to maximize the code interchange with a few million lines of existing code and a large set of existing experienced developers? well, maybe not then...

rezmason 2y ago

I don't think the goal of Rust has to be to unseat C++, just like the goal of Macs is no longer to unseat Windows. Here are some nobler goals: * be a language that users and non-users believe is better * be a language that people learn things in before entering the industry * be a language for solving important problems, if not every problem * if a billionaire buys C++ and makes it terrible, be an alternative Edit: unrelated— I really struggle with writing lists on HN. :-(

pdimitar 2y ago
> 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.

tschellenbach 2y ago

come to the land of no drama, no changes and always productive Go :)

tail_exchange 2y ago
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.
- TylerE 2y ago
  I could argue that at least 90% of software does t need a very low level language.
  - goku12 2y ago
    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.
    - TylerE 2y ago
      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.
      - goku12 2y ago
        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.

deleted 2y ago

[deleted]

PeterWhittaker 2y ago

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.

npalli 2y ago

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.

Tuna-Fish 2y ago
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.
brson 2y ago
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.
bryanlarsen 2y ago
The disadvantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything. The advantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything.
- echelon 2y ago
  Why would you want a refactor into a broken state? You always need to figure out how much you're going to bite off with each refactor. It's usually possible to do things incrementally.

ksec 2y ago

>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 )

synergy20 2y ago
Golang is not much more widely used comparing to rust? both are 17+ years old and they're around 2% of the market.
- serbuvlad 2y ago
  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.

jksmith 2y ago

"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.

bobajeff 2y ago
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.
- igouy 2y ago
  > ... when the 90s arrived it didn't have a big company pouring gobs of money into marketing it unlike Java. IBM not big enough? :-) But of course IBM's consulting group were technology neutral and pivoted from Smalltalk to Java when the wind changed. > Like who wants to distribute a whole system for each smalltalk program they sell? Smalltalk was marketed to corporations as a 4GL replacement for green screen systems. So enterprise wide client-server apps for insurance/reinsurance, call center outsourcing, assembly line control, options/derivatives/reconciliation, ERP CRM TLA TLA, etc etc I don't claim to have been in "The Room Where It Happens" meetings, so I'll just say that from my lowly perspective during that period Allen Wirfs-Brock's comment ring true. https://wirfs-brock.com/allen/posts/914 https://wirfs-brock.com/allen/posts/914

tikhonj 2y ago

"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.

echelon 2y ago
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 There are Rust jobs! I'm hiring Rust devs.
- ethagnawl 2y ago
  > 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.

srj 2y ago

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.

MathMonkeyMan 2y ago
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.
- nightowl_games 2y ago
  Kinda. The vast majority of c++ I encounter is simple orthodox c++. No one I know cares about new features in c++ and bemoans having to ever write a template. No one really cares about bulletproofing types, ie: copy/move constructors and all that stuff. I'm sure it's different at big companies but the vast vast majority of c++ is just simple procedural code.
  - 8fingerlouie 2y ago
    > 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).
    - weebull 2y ago
      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.

eggy 2y ago

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.

woodruffw 2y ago
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.

jvanderbot 2y ago

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.

ppp999 2y ago

[flagged]

synergy20 2y ago

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.

robertlagrant 2y ago
Maybe it can. Why don't you propose[0] a list of features that would fit your requirements? You never know! [0] https://lang-team.rust-lang.org/how_to/nominate.html https://lang-team.rust-lang.org/how_to/nominate.html
- synergy20 2y ago
  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.
zozbot234 2y ago
Did you try https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust ?
- synergy20 2y ago
  yes as mentioned,it's still too large compared to c++ when i have multiple executables
yolovoe 2y ago
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.

fsckboy 2y ago

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. edit: thought of one, the soles of shoes

pornel 2y ago
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.

kazinator 2y ago

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.

an_d_rew 2y ago
True... but whether the ability to so is a superpowers strength or a debilitating weakness depends on both your values and point of view!

dmitrygr 2y ago

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.

johnnyanmac 2y ago
> i choose what employers want and will pay for. with the US mandate away from unsafe languages, that may change faster than you think. Unless you are already quite close to retiring.
- dmitrygr 2y ago
  Mandate? When did the president sign a law written by congress banning C? And even then, the courts have ruled programming as speech, so first amendment applies. I’m not even remotely considering the possibility of letting the thought of pondering maybe worrying cross my mind here.
  - deleted 2y ago
    [deleted]
  - johnnyanmac 2y ago
    Mandate is a strong word, but this month: https://news.ycombinator.com/item?id=42013379 https://news.ycombinator.com/item?id=42013379 "For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by Jan. 1, 2026, is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety," Obviously they can't ban a language. But if you work in the public sector, are a defense contractor, or otherwise have companies which do or want to do work for the government (which yes, includes most FAANGs), this will influence quite a bit of decisions in the US tech industry.

readthenotes1 2y ago

"Dvorak keyboards are better than QWERTY," 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

ribadeo 2y ago

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.

shoulderfake 2y ago

[dead]

AstralStorm 2y ago

About the only remaining issues I personally face is the suspicious lack of plotting libraries, and bit of an insufficiency in maths libraries, especially for higher level operations than just linear algebra. There's no scipy, numpy and matplotlib equivalent yet. Both C and C++ do better in this particular area... Peroxide is a good start, but it cheats much like scipy by calling into Fortran, while having some very pecuilar APIs thanks to that.