Isn't this premature? Rust is still pretty new.
The old lady said both those things to me this week. In two different conversations.
Doesn't mean rust will ever grow like that, but merely slow adoption doesn't sound like a death knell by itself to me.
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.
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.
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.
Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages.
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.
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.
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.
Again, sorry. :( But I am not getting any networking opportunities lately and couldn't resist replying to your message.
Also, you should maybe stop associating right wing crypto YouTubers with crypto developers. I would say most I know are left of central.
Calling out FTX is like doing background checks on the company you work for’s VCs, their LPs and then their associates. Nothing to do with crypto on the ground
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.
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.
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.
Well, I am interested. Got any names?
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.
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.
Dependency management is a fact of life for most of us out there in the trenches. It cannot be escaped. We don't want to roll our own.
Look for opportunities to adopt Rust, especially greenfield projects. We don't have to eliminate all C++ codebases first.
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 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.
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.
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.
Rejoice! You are one of today's Lucky 10,000[0]!
Google trends only go back to 2004, but it's older than that.
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.
People are happy in Ivory towers, and often ignore better high-level llvm compiler options. =3
> 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
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.
But many companies are definitely writing new projects in rust rather than C++, including Big Tech.
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).
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.
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..
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.
Money is the biggest parameter, and it would not make number go up in the short term. Tech stacks are in inherently a long term investment and companies are conservative to do big reworks like that.
In theory, yes, but there are two problems:
(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.
We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.
That being said, keep an eye on Carbon.
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.
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)
Maybe if you’ve already got the toolchain set up and boilerplate templates etc.
But large codebases in C are tedious to work with and slow to refactor.
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)
C++ and Rust are a different thing.
That’s simply not true, starting with ARC being compile-time and GC being run-time.
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.
Are you describing 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.
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.
Add to the potion, binary libraries and extern templates for the common types.
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.
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.
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.
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.
You've never dealt with Esperantists, I can tell.
also the irregularities in english developed over centuries by contact with other languages in an environment that lacked the normative influence of globalization and modern communication tools.
at the time english was also not the defacto language for international communication that it is today. this status is responsible for efforts such as a wikipedia in basic english that makes information easier to approach by non-native speakers.
as esperanto was expressly created with the goal of being an international language, any attempts to introduce irregularities will meet a lot more resistance and therefore development of an irregular grammar is unlikely to happen.
That's the problem. It's design by commitee instead of evolutionary organic design. It's how cyborgs think people oughta talk.
I feel you understand the author' point but still disagree for some reason.
I'll put the metaphor back to programming. There's programming for quality and programming for financial gain. If your metrics are the latter, then Javascript is the best language. But many people here do think as engineers, and thus there are other qualities that "are not as good" ways to score a language but maximize the ability to deliver a stable product.
I loath 1-based indexes though. Just odd.
Agreed. Until Esperanto starts having actual native-speaking communities, I will look at it the same way I look at Klingon or Elvish.
that was the point of the OOP, yes. No one cares about quality, but popularity. And OOP feels the same.
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.
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.
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%.
My previous job was at one of the largest investment companies in the world, if the COBOL went away the company would collapse.
Fortran isn't surviving just because nobody wants to rewrite Fortran code. Unless you're talking about Fortran77 code.
> COBOL is still the backbone of the financial sector
All the CVEs found in the last several years would like a word with you.
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.
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'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.
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...)
well yeah, when we switch to an industry that values poaching over retention, you're going to have way too many cases of landmines whose knowledge was held by an employee who left or got laid off 4+ years ago. That makes them much harder than they need to be.
A close 2nd is indeed that documentation is the least valued business item out there. Employees who want to "grow" (financially) are practically encouraged to simply keep moving instead of ensuring future knowledge is spread.
Apple is a rare exception, even if their incentives are perverse.
Im thinking more like at least a century.
It's always a misconfigured default.
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.
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.
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.
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...
It was even simpler in that they aren't confident of mass adoption. I'm unsure if that's Rust's fault (and honestly, finding any job in this market is a small miracle), but it's a valid factor to not want to be stuck to something forever niche.
* 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. :-(
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.
No I won't!!
Sorry.
Why do we throw around “low-level” like it meant anything besides “not JavaScript”… or is that actually the definition?
I've written Rust services in financial companies and it maintained stable memory footprint and near-nonexistent higher P95 latency... for months without restarts.
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 love golang and it is my language of choice but the type system still lets you shoot your foot off sometimes.
...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.
Let’s check back in a couple of years!
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.
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.
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.
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.
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've got a massive multi-binary monorepo and it's so easy to make sweeping refactors to core libraries that impact all build targets.
I can't fathom doing this in C++, or worse, a dynamic 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?
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.
Come to think of it, the 21st century/mutable by default is a nice group also: groovy, C#, golang, TS, Dart and Bright's D.
https://elizarov.medium.com/immutability-we-can-afford-10c0d...
blurred scan: https://www.joyk.com/dig/detail/1595957460688776
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.
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++.
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.
>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 )
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 would argue there is 2 types of complexities here:
1. Complexities when developing (Rust) 2. Complexities once running in production (C++)
I’d much much prefer to have errors and frustrations developing than users dropping out of the sky at 40,000ft
But C++ devs aren’t trying to convince rust devs to change their stack.
I’ve never heard that from a C++ dev.
I don’t think any C++ dev worth talking about thinks that C++ is particularly safe, just that (modern) C++ has plenty of powerful safety features. (Like smart pointers. Analogous to rust’s Rc and Arc)
So much so that it approaches rust’s safety promises in the most common cases.
In what I’ve seen, C++ devs are largely unconvinced that rust is more safe than modern C++ in the most common cases, but rust has a much higher complexity cost, especially when integrating with C code.
It’s really hard to convince hardcore C and C++ devs to use rust, because most of the touted features are seen as fixes for skill issues. Not because they believe that rust is not safer.
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.
A BBS? Does this have a different meaning now than in 1986? Where do I dial up to it?
See https://honeypot.net/2024/11/28/first-light-of.html for screenshots.
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.
How does it deal with GC pauses? Wouldn't they introduce unacceptable jitter for this kind of application?
Anyway, it's relatively straightforward to rewrite from Go to Rust if you aren't doing things that essentially rely on GC (which is quite rare).
I hope someone properly checked that no safety properties depend on Go there. I bet nobody actually did so...
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.
Dvorak isn't particularly better because typing speed isn't worth optimizing for if you are good enough and the difference if any is small.
Lua isn't better than js if it needs to run in the browser natively.
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.
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.
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.
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
I don't care how much you pay me (well, not in a practical sense), I'm not going to bash a bunch of screws in with a hammer. In my industry, the languages and tools do in fact matter and impact the quality of the project. It's hard enough as is without some unreasonable clients saying "oh yeah, can you make this in powerpoint?"
My clients are not that dumb.
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.
...
>I'd like to see some actual examples
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.
If you feel that way, you are free to take the reigns and put unsafe blocks everywhere. Languages by design need to be opinionated (even stuff like machine language), and most of them do not let you say "it's cool, I know what I am doing here" to begin with.
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.
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.
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.
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.
I think the fact that the language is aggravating without complex and tight IDE integration is one of the best indictments of the language there is. Java is another language that's intolerable without impossibly complex IDE support. The more rust matures the more it feels like that.
Still, I'd say that actually the distinction that's aggravating you is almost entirely that Rust won't compile a lot of code that's nonsense, whereas in C++ that code compiles - it's still nonsense, but it compiled anyway. I think that's just plainly worse.
The distinction that's aggravating me is the compiler refuses to compile code that I know is correct, but it's not smart enough to prove it, so it just gives me the finger instead.
Can you elaborate on the dangers of doing this incorrectly? What kinds of dangers are there in making a string literal available to a header file.
And by C++ taking a long time to get the natural string slice type, which it calls `std::string_view`. This type is what you almost always want in APIs that aren't responsible for growing and changing strings - for the names of things, labels, parsing and so on. Because this type was not in C++ 98 or C++ 11 or even C++ 14 people would use `std::string` instead even though they did not need to modify, let alone grow, the text or, since they don't want the overhead of `std::string`, they would use `char *`
It was correct for C++ to seek to do better than C here, but while what they delivered was a lot more powerful it's not clearly better and I think has contributed to widespread misunderstanding.
This is somewhat of an anthropocentric point of view. (In particular, assembler is as far as it gets from this.)
Which frustrates me in many respects. Especially in a specialization like tech where the audience should be used to picking up new tools to make for the best project. But I know most projects are made with business constraints in mind (i.e money and time) and cheapest almost always wins.
Languages like Golang, can make a good argument of being the VHS to Betamax, because it is among the easier to learn memory safe languages. Golang is much more strongly positioned to take over C#, Java, and even Python spaces. Not just technically, as a language, but because of the large corporate machinery and jobs behind it, that is the result of being a Google product.
As for Rust's main claim to fame, memory safety, lots of other lesser known languages are hard at work to become direct viable alternatives to Rust. Some of them are: Hylo, Vale, Lobster, etc... Vlang, while not quite trying to aim as high as the others (on memory safety), uses an optional GC (like Nim and Dlang), and is among the safer languages. It then becomes a question of how much the extra burden of Rust is needed, for the project in question.
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.
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.
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.
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.
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.
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.
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 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.
ironic to call someone's POV narrow just becasue it disagrees with your worldview.
>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.
We had an entire election where a state was bought with votes, admitted it was a scam, and is using the courts as a cost of doing business. Beliefs can in fact be manupulated more easily than you expect for the common people.
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.
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.
I'm not surprised to see this mentality because this is also ultimately a place to foster entrepreneurs, who revolve around money. But it's still saddening to see curiosity be mocked.
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.
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).
"Enforce encapsulation" suddenly became. "Respect encapsulation" in my head and a bunch of Java/C++ problems evaporated.
My current preference is to have everything public, but immutable.
Edit: except for functions. Private functions are a great way of keeping downstream users from touching them. Only expose what you are willing to support.
Linters should be shouting about it and in the PR you’d need to explain why you turned off the warnings to do it anyway, with comments explaining why there was no other feasible option and this was the least bad choice.
BTW, I rarely write _methods and almost never __protected attributes. _something just means “it’s here but you really shouldn’t be playing with it.” I don’t see an advantage to using __anything.
(lots of reasons to like it, too)
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.
No need to school me on how that isn't true, I'm just describing my feeling and why I love C++.
(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.
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.
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.
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.
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.
when stdlib is needed then size becomes a big issue, yes busybox approach helps,but.
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
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.
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.
with the US mandate away from unsafe languages, that may change faster than you think. Unless you are already quite close to retiring.
"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.
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
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.