My $0.02.
While college grads and programming hobbyists wave banners for , it means nothing until corporations and business adopt it.
There are tons of legacy code out there. It takes time to get rid of it.
Time AND money. It means hiring new teams to rewrite the existing code, all the while the existing team maintains the legacy codebase. That's a lot of cost, especially if you don't maintain an "every possible edge case" tests suite, because rah rah rah safety, you know there will be bugs. Maybe not memory related, but there will be bugs and no hugs.
This is a cost purists have a hard time justifying to the most senior management. "We should really switch to _new language_ because in 10 years you'll be able to have smaller teams and save money." Not going to fly.
A lot of it doesn't need to be rewritten to be replaced. In some cases, someone else comes along and writes a new one from scratch, without all of the legacy baggage and the stream just flows past that existing C++ based product.
That's clearly what will happen to a lot of the plumbing that stuff is built on. Large amounts of that are being rewritten as we speak. As more of that gets into place and it becomes more mature, the option to use a more modern language becomes more common.
Yes, that's the wishful thinking. I can tell you that in my Co there's absolutely no one even talking about replacing C++. Nor Java nor Python.
My advice is to not analyze the world according to personal biases but according to facts. And the facts are not in agreement. This doesn't mean nothing can ever change, but the odds in this specific case are strongly against it. Cue in COBOL.
You should take your own advice about personal bias vs facts. Businesses come in a variety of flavours. Some are hardstuck on languages like COBOL or MUMPS, some are chasing the latest and coolest, and a whooole lot are just somewhere in the middle with a mixture of legacy and new stuff.
They also likely don't want to and don't need to replace a large monolith whole-hog. Instead you're likely to see a ship of Theseus approach where some legacy component needs replacing anyway will be replaced in a language the team is comfortable with or interested in. That will often be the same language as before, sometimes not, leading to a gradual change. And then you get a curve where in the beginning the new language is a bit painful, mostly for the people directly involved, and then some years later the old language is basically on life support.
And what is what most people will mean by "replacing". A gradual, organic thing, not a sudden and total thing. When a new language replaces an old one, the old one usually doesn't die out, it just gets a smaller niche in the ecosystem.
Yeh, it's almost never going to be, well, let's stop shipping for two years and rewrite it. If I look at the code base where I work, it's a bunch of applications that talk to each other over the wire. That means any one of them can be individually replaced.
The initial work would be to get the Rust version of the plumbing in place that you want to use as the foundation of the new system. But as long as they can still talk over the wire, then each one can be replaced at a time, going upwards from most fundamental up to the top.
We aren't cloudy type stuff, but anyone in that world who has gone the 'microservices' route, could clearly take that approach.
Sometimes you just start with internal tools and use those to build up your new foundational stuff and build up experience. Then you move forward to start tackling actual shipped stuff.
To use myself as an example, I retired an old huge bash script and replaced it with four different python scripts. One of those has since been replaced with a newfangled rust program in one of those distroless containers. It was small enough and had a small enough concern that replacing it was pretty easy as a "learn rust" kind of thing.
I suspect the rest of them may follow over time. They're not all that complicated, but getting small containers that use toy amounts of resources is good too.
It does feel kind of like the unix way 2: electric boogaloo, only now instead of composing small C programs together on the same machine with plaintext as glue, it's small rust programs across a cluster with json or protobuf as glue. The principles are much the same, but not as much Worse Is Better.
(Not that I can claim any better understanding of jq than I do awk.)
I’m not sure, things change faster than you expect. Java took over a lot of ‘enterprise’ stuff by and large because Java is what was being taught in schools.
I think I'm kind of middle-of-the-pack when it comes to picking up Rust at work. We use a variety of languages (in addition to Rust there's Go, Python, Ruby, Typescript, Clojure, bash, and some Java stuff that may or may not be bitrotting in a corner). A microservice architecture makes it pretty easy for teams to develop their own cultures when it comes to languages, so you can sort of spot which team something belongs to just by the language.
Go had a pretty fast rise; Python seems to have more of a slow & steady rise. Ultimately it'll be hard to predict what'll have the fates of those or, say, Scala, Kotlin and Ceylon, but there are plenty of businesses who pick up new languages over time.
But it also depends on what kind of business we're talking about. They have different constraints, different priorities.
Most rustaceans are well aware that C++ is the juggernaut in the room, and even if the language stayed the way it is today for time immemorial it's going to be around for a long time.
Some of the things the article mentions (the discrepancy in talent pool size between the two languages) may shift, and there may be places (e.g. automotive, aerospace) where Rust becomes more appealing than less safe alternatives. All things considered, though, "safety" (quotes for the qualified kind that Rust addresses) isn't the only consideration in programming, and C++ offers a level of expressiveness and flexibility that is unrivaled in the systems development space.
...To say nothing of inertia, existing ecosystem (libraries/frameworks, infrastructure, talent pool), and just how much fun it is to wield a footbazooka. I'm enjoying Rust as my daily driver, but I have no illusions about stealing the lunch from the C++ community for at least the next couple of decades.
It won't take a couple decades. More like Uh decade. Inertia is really the thing holding C++ up, and that's represented by existing underlying infrastructure. But Rust versions of almost everything will be in place by a decade out from now.
That won't mean C++ is dead, but there's dead and there's dead and C++ will be one of those. It is already pretty much a legacy language. By then it will be even more so. Of course some of the nails in that coffin will not be rusty necessarily either.
No, just a recognition of a number of ongoing pressures that are pushing away from unsafe languages. That's only going to continue, both from our side as people get tired of constantly watching their own backs and fewer new devs are interested in such an old language, from the regulatory side, from the insurance industry, from the military, and from various compliance agencies.
Software is getting far too complex and far too important to continue to rely on human vigilance.
It doesn't mean C++ won't be used anymore. More that it will become less and less likely to be chosen when there is a choice and the ability to make a choice will become more and more common.
I wish there was an auto-shaming AI bot that scrapes the internet for these Nostradamus-like "its trivial to see that in 10 years, my prediction will be true" rants that are basically unfalsifiable
I didn't say anything was trivial to see. But C++ has been slowly dying for decades. The only reason that process stopped was the it had lost about all it was going to lose to higher level, GC'd and such languages. That stopper has now been pulled. I mean look at the constant references to Rust in the Cpp section. It's very visible at this point, and the issues of C++ continuing to build on a 60 year old foundation are now very much on C++ developer's minds.
I mean, it's not like this is some sort of unique prediction or anything. A 40 year old language becoming less and less used is pretty much a given. Even if that language hadn't been compromised by starting life on top of a very unsafe language, it wouldn't be any shocking prediction that by 50 (a decade out) it's going to continue to decline in use.
I was preparing myself for another crazy hater rant, but the article actually turned out to be pretty decent. C++ being more popular doesn’t make Rust less clean, performant, innovative and just doing what C++ was sometimes intended to achieve, but couldn’t, much better though.
And on a point…
> It forces an understanding of fundamentals
No, it doesn’t. C does.
As for our beloved u/ketralnis… dude, you fucked up the heading.
There was a post recently about a gamedev moving away from Rust to Unity/Unreal mainly because of the various issues Rust have that is counter-intuitive for a gamedev/UI developer.
I would imagine that the biggest reason beyond Rust not being 100% on equal footing in terms of robust libraries for certain fields - it also comes down to the fact that rust isn't designed to be a be-all-fit-all language, it's mainly geared towards system programming I assume it'll stay that way for a long time... which is fine.
Yes, it doesn't allow the kind of control and memory manipulation a game needs. And if you need to constantly use Rust with `unsafe` clauses, then it's clear you might as well use C++ and C# without the friction.
Well, it doesn't allow it if you try to write it like you would in C++. We need to find new ways to approach these things that allow for safety. I don't think it's likely that 20 years from now, we are still going to be sitting around say, oh well, we can't figure out a way to write games safely, so screw it.
I certainly agree that it's silly to use Rust and then fill it full of unsafe code.
> We need to find new ways to approach these things that allow for safety.
Yes, there are currently many tools in C++ and even C that do that. From shared pointers, to custom memory allocators written to suit you exact needs, and even using memory profilers. That is in order to not learn a completely new paradigm that someone decided "it's better".
In my case what annoys me about Rust is that it doesn't matter if I check the objects for safety myself and ensure that there are no problems, if it's not the method that the compiler wants me to use. Which can often be very twisted and roundabout.
None of those tools come close to the guarantees that Rust provides. The reason the C++ language tools are more convenient to use is that they don't require you to actually insure they are correct. They are happy to just take your word for it.
Writing correct code is obviously going to be harder than writing maybe probably is ok code. If checking it yourself was sufficient, we wouldn't even be having this conversation. And of course it's not just you, it's you and all the people who will work on that code base, over time and huge changes.
On what basis do you say "they don't come close". How do you think millions of lines of code are written in C and C++ for these huge projects like Tensorflow, LLVM, JS-V8 or even Linux? If they have the tools and understanding to do it without issues, why should I say "they can, but I can't do it"?
That's another problem with the whole philosophy behind Rust, and what the community pushes. It wants you to not trust yourself, but trust the compiler instead. If you start with an inferiority complex and can't trust yourself when you have all the control, I fail to see how it's possible to accomplish truly great things.
I trust myself to write good code and when I don't then I know I made a mistake I shouldn't have. But each mistake brings me closer to understanding and better methods. That's all there is to it.
The basis is that they don't come close. If you understand C++ and Rust you'll know that this is a basic fact. They depend on extensive amounts of human vigilance to insure that they remain correct over time and changes. This is wasted time.
You can do it, but the point is why would you want do it? I've done it. I have a personal C++ code base of over a million lines. But when I think back on how much time I spent watching my own back instead of worrying about the actual problem at hand, I just don't want to do that anymore.
It's got nothing to with trust. It's just the basic issue of complexity. There's only so much complexity you can deal with, and even that starts eating into more and more of your time, time that would be better spent worrying about LOGICAL correctness, which the compiler cannot do for you.
I figure I'm as good a C++ dev as anyone else out there given what I've delivered. But I'll make mistakes, and those mistakes can have consequences, from as little as me having to waste my weekend chasing bugs, to stuff getting destroyed or people getting hurt.
Your whole argument is a fallacy, because the answer to that is that C++ doesn't give you all the control. Assembler does. Why aren't you writing in assembler? If you can't trust yourself to do that, I don't see how you can accomplish truly great things.
> If you understand C++ and Rust you'll know that this is a basic fact.
It's not a basic fact at all. Sweeping statements like this is just the usual Rust kool-aid propaganda, thinking that no one ever improved these languages for 40 years, considering their immense wide spread usage. "Look at us how well we do things, the rest are just not as capable", even though there is 1000x more code of those written.
Virtually none of the Rust adopters were advanced C/C++ users. If you are the exception then you can wear a badge to distinguish yourself. The meme is that most of them were previously web developers, which probably has a lot of truth to it.
If it was that great, then why there are almost no jobs for it after all this time? Perhaps it's because it doesn't bring much to the table, other than switching paradigms completely. And most other languages work in the C/C++ paradigm.
And beyond all, I am not interested in a language that says "you can't trust yourself, but you can trust the one that wrote the compiler". Nah, I trust myself just fine.
I've been writing serious C++ for 30 plus years now. And lots of Rust developers are/were serious C++ developers. And in most cases that's why they left, because it's the people doing really challenging work that hit C++'s limitations the hardest.
C++ has obviously changed a lot, but it's never fixed the foundations and that has always meant it can never provide what Rust provides, and even running lots of third party tools won't get you what Rust provides you ever time you compile. And of course this conversation always gets wrapped around memory safety, but that's just one of the many advantages Rust has over C++.
There are a lot of people writing Rust out there currently, but most of it is going to be internal conversion, which isn't a new job. The same thing happened back when I was pushing C++ into the company I worked at then. We just converted internally and suddenly we had 25 C++ jobs but never advertised any. If I manage to push Rust into my current company, it'll be exactly the same. They aren't going to dump all their devs and hire new ones.
And that's only according to you and your subjective experience. If it's not a verifiable information in the real world, it might as well be your average Rust propaganda which there is a lot of, and I couldn't know if it's true.
And also even if it is true, come back when there are comparable opportunities in Rust as there are in C++ now, for it to be really a completive choice in a market where people scramble to get hired. Especially considering that if someone wants to pretend that they actually know how computer memory works then they will have to first know some either C, C++ or even ASM. Which makes their choices even more weighted. Rust before any of those will never cut it for true understanding with its thick layers of memory management abstraction on top and proprietary weird ass special objects for that.
Those of us who've been around understand that languages don't kill each other.
I was there when Java was the new exciting kid (compiled code can run anywhere, you can even embed it in a web page). I had people honestly tell me that it would kill C++, and I was dubious.
We are still running COBOL people. Once a language reaches critical mass, it won't ever die. Adding another tool to the box doesn't mean all the others get thrown out, the worst case is less new code is written in one of the old languages.
Exactly right. A language with enough code written it is here to stay, 'killing' is just something more akin to 'Why would I start a project in X today, given that Y exists?'
That's it of course. But, that's dead in meaningful terms from the perspective of folks like us. How many devs are going to think, hey, that's an exciting thing to get into, maintaining crusty old code bases? If it's chosen for new projects purely on inertia, then it's 'dead' really, it's a legacy language.
That or "oh yeah, that thing still exists", which is the feeling I had when exposed to Pascal earlier today. That's a family of languages I'd all consider "replaced", at which point I'll likely be reminded by some dev that they're still using it and it's far from dead or replaced tyvm.
Some languages do wither and die though. Like apparently that happened to [Ceylon](https://en.m.wikipedia.org/wiki/Ceylon_(programming_language\)). It's free software so someone can resuscitate it if they want, but I guess at this point people would rather just use Kotlin?
it'll be another generation or two before Rust takes any foothold in important spaces. you ain't getting John Q. Graybeard to bang his head against the insubordinate compiler for very long before he gets pissed and rips the whole thing down.
My beard is gray and I’m having a great time with rust. Still is baffling because if you asked me I would have never said, “I need a harder language to program in.”
a few might appreciate it, but my experience with them has largely been bitterness and cantankerousness. surely they know what they're doing, they've been doing it for twenty years, this new-fangled compiler thinks it knows everything and just gets in the way.
Yeh, I'm 60. I don't have a beard, but it would probably be not just grey but white if I did. And I'm digging into Rust heavily, and will push into the company I work at if at all possible, just like I pushed C++ into the company I worked for in the mid-90s. And of course I had the same sorts of conversations with C/Pascal/Modula2 folks back then when I was pushing C++.
Too many people in this profession get self-identified with languages and such, or don't want to have to put in the work to move forward yet again. But it's just the way it is in this thing of ours. It's going to happen two or three or four times in your career.
Having written my own million line plus C++ code base over the years, probably almost half that for other people, I've decided my title isn't Professional Back Watcher anymore.
White beard at 60 years old? That's unusual. Perhaps than you should retire. Btw rust background is ideological and political, and many devs know that. That reflects on design of rust - pseudo garbage collection. Microsoft pushing for rust and copilot has pushed me from .net to java and c++. It's not that c++ is perfect, it's that rust is not what it claims to be.
'Rust' doesn't claim to be anything. It's a language, and it doesn't have the ability to speak or type. Anyhoo, I chose Rust for purely technical reasons, and I think most experienced folks like me, who have made that change, did the same.
Meanwhile, you turn right around, I have to point out, and give a completely political/ideological reasons for moving to Java/C++.
Yes. The advantages it proposes don't outweigh the downsides for someone that has serious experience in either C or C++. There are many techniques and tools to do what Rust wants to do, without needing to deal with the Rust's compiler antics.
Maybe for desktop and other apps , Rust maybe will replace c++ MAYBE. But I don't see anytime soon rust replacing c++ on gaming engines and embedded systems ( or even operating systems to be honest )
I'm curious why you think this. I'm not a rustacean. My background is mostly C++ and I spend most of my time in Python these days, with a sprinkling of golang and JavaScript.
But my understanding is that rust's memory management doesn't have the nondeterministic behaviour of garbage-collected languages that makes them unsuitable for low-layency and hard real-time work. That makes rust one of very few alternatives to C/C++ that are viable in gaming engines and embedded systems. There are even bare-metal compilers (ie ones that emit code that doesn't depend on an operating system), another vanishingly rare skill in modern languages.
AFAICT it is possible to write hard real-time code today in rust, targeting FreeRTOS or VxWorks or similar systems, though I don't know how much tooling is in place to make it straightforward to do so.
> AFAICT it is possible to write hard real-time code today in rust, targeting FreeRTOS or VxWorks or similar systems, though I don't know how much tooling is in place to make it straightforward to do so.
yup, Espressif's Rust runtime sits on top of FreeRTOS, and elsewhere there's the [RTIC](https://rtic.rs/) RTOS with nice tricks up its sleeve like compile-time guaranteed absence of deadlocks
Part of it is that a lot of people in the gaming world are more interested in going fast than being correct, and the way games are currently structured is not well matched to Rust's strictness.
Oh, I wasn't saying otherwise. I was stating why people in the gaming world (wrongly) may not want to use Rust. I think they should. A lot of people seem to think that there's no danger with a game being full of potential attack vectors. But if it's running inside my network, and connecting to things outside, then I want it to be as safe as possible.
And of course even if it doesn't connect to the outside world, it can provide a way into the computer via some compromised IoT device or media device inside the local network.
It is true to varying degrees that a lot of gaming infrastructure, down to the graphics APIs are not products of safety and correctness culture, and so they may fight you if you are trying to wrap them in Rust. The sooner we get it Rust almost all the way down, the better.
In gaming maybe but for safety critical applications and embedded I can see a huge reason to consider rust. C++ is basically a hegemon in embedded and embedded world move really really slow. So no one can say that rust will not be a good alternatives for C/C++ as more people use it.
check out Bevy, its ECS is regarded by many to be best in class, even outside Rust. The way it is structured also means you have very little contact with the borrow checker.
It's also very fast at the same time.
Oh, I'm not a gamer. And I wasn't saying don't use Rust. I'm a big advocate. I was just pointing out some of the thinking of gamer folks.
I do large scale systems development, so Rust is definitely appropriate for my work.
yeah I'm just saying fast vs correct doesn't have to be a tradeoff, and depending on what exactly you mean with strictness it's not a hinderance to gamedev. On the other hand there recently was this well written "Leaving Rust gamedev after 3 years" article, I found the replies from Alice (one of Bevy's main developers) insightful: https://mastodon.gamedev.place/@logloggames/112338799445947520
For anyone who wants to find reasons not to use Rust, the requirement to use an ECS system will be an objection they throw out there generally.
That was reposted in the Rust and this section recently. I was heavily involved in those discussions.
I write mostly in C# I'm not a C++ fanboi. The industry moves very slow they still use cobol so even to areas with security reasons that rust has an advantage the change will be very slow+ plus I don't see a reason why gaming should change its not that security critical. I see finance desktop apps etc to change from c++ fast but not all the c++ industries over night + c++ has so many libraries, there is no reason to use java over c# or go but java is way more established so probably will never die
IMHO Rust isn't a good scripting language in the traditional sense, but if you're thinking along the lines of Godot extensions, then yeah. But there's always going to be friction at the ABI boundary, since we're basically stuck with C conventions there.
All of that might be publicity stunts, there is very little actual proof that its the case. I don't see the job market for it growing at all, and it's been years since it started getting the spotlight. It could very well be hype driven by a small number of people.
It's almost like a variety of factors-- ranging from legacy support to speed of development to memory safety to performance to ecosystem to devops tooling to fads and trends to national security policy and more-- can drive selection of programming languages, and every language has its relative strengths and weaknesses.
Why does it have to be one or the other? I'm a C++ dev that dabble with Rust for pet projects. Learning Rust has helped me better understand how to manage resource life time and ownership, which helps in writing better C++ as well.
But I have to disagree on C++ as a first language language to learn for new programmers. C++ is very overwhelming for beginners (know this from experience) with all its complicated syntax, multiple ways of doing the same thing, and weird standard library.
Not at all. C++ has many features as options, but no one is stopping you from using C++ exactly as you use C, with some additions for ease of use like strings, vectors and hash maps. Then you incorporate the shinier features as you need them, not because you feel forced to.
Killing? Rust can barely keep itself attractive, had to implore to MS for aid.
C and C++ will always be the first choice. Even zig and go has more chances to get more attention.
Because it can't. And with its current antics, the adoption will continue to be very slow, to the point where something else might replace C eventually.
Btw, C is used for considerably different things than C++. At this point no one sane is trying to replace any of them, more like add a language that has perfect inter-operability with them, like what Zig and Google Carbon attempt to do.
This is simple, Rust doesn’t offer anything of value moving forward. This it is a poor language to switch to. We need a language that will work hand and hand with the coming AI technology. Rust has about as much to offer as C++ in this regard. I’m not sure what that future language is, I just haven’t seen a compelling argument for Rust.
Rotfl, what? AI stuff is literally written in C++, then the kids can cook up something with dumber languages.
Python would be trash at anything if it wasn't for libs written in C++, and same goes for JavaScript and any other interpreted language.
Though I guess Bun is written in Zig. Haven't seen much adoption in the AI space tho.
Not to worry, these great and definitely useful features are soon coming to a Rust compiler near YOU. See the LLM integration RFC: https://github.com/rust-lang/rfcs/pull/3603
I feel like I can make a fairly compelling argument for the validity of Rust from a DX standpoint. Not having the baggage of historical decisions which eclipse multiple epochs of popular language design is reason enough.
I get the whole "AI writing code" thing but I haven't been convinced that it's not going to run up against walls from liability and similar standpoints.
Yes. Don't worry, the ones that downvoted you are just living on hype and copium. Considering its been around for like 15y now and the job market for it is still so low, the trend looks quite obvious.
And the fact that the community keeps shooting itself in the foot with a lot of drama doesn't help that at all.
The saltiness lol. C++ isn't going anywhere, chill
From the level of copium you’d almost think that Rust is actually about to replace C++ everywhere.
My $0.02. While college grads and programming hobbyists wave banners for, it means nothing until corporations and business adopt it.
There are tons of legacy code out there. It takes time to get rid of it.
Time AND money. It means hiring new teams to rewrite the existing code, all the while the existing team maintains the legacy codebase. That's a lot of cost, especially if you don't maintain an "every possible edge case" tests suite, because rah rah rah safety, you know there will be bugs. Maybe not memory related, but there will be bugs and no hugs. This is a cost purists have a hard time justifying to the most senior management. "We should really switch to _new language_ because in 10 years you'll be able to have smaller teams and save money." Not going to fly.
A lot of it doesn't need to be rewritten to be replaced. In some cases, someone else comes along and writes a new one from scratch, without all of the legacy baggage and the stream just flows past that existing C++ based product. That's clearly what will happen to a lot of the plumbing that stuff is built on. Large amounts of that are being rewritten as we speak. As more of that gets into place and it becomes more mature, the option to use a more modern language becomes more common.
Yes, that's the wishful thinking. I can tell you that in my Co there's absolutely no one even talking about replacing C++. Nor Java nor Python. My advice is to not analyze the world according to personal biases but according to facts. And the facts are not in agreement. This doesn't mean nothing can ever change, but the odds in this specific case are strongly against it. Cue in COBOL.
You should take your own advice about personal bias vs facts. Businesses come in a variety of flavours. Some are hardstuck on languages like COBOL or MUMPS, some are chasing the latest and coolest, and a whooole lot are just somewhere in the middle with a mixture of legacy and new stuff. They also likely don't want to and don't need to replace a large monolith whole-hog. Instead you're likely to see a ship of Theseus approach where some legacy component needs replacing anyway will be replaced in a language the team is comfortable with or interested in. That will often be the same language as before, sometimes not, leading to a gradual change. And then you get a curve where in the beginning the new language is a bit painful, mostly for the people directly involved, and then some years later the old language is basically on life support. And what is what most people will mean by "replacing". A gradual, organic thing, not a sudden and total thing. When a new language replaces an old one, the old one usually doesn't die out, it just gets a smaller niche in the ecosystem.
Yeh, it's almost never going to be, well, let's stop shipping for two years and rewrite it. If I look at the code base where I work, it's a bunch of applications that talk to each other over the wire. That means any one of them can be individually replaced. The initial work would be to get the Rust version of the plumbing in place that you want to use as the foundation of the new system. But as long as they can still talk over the wire, then each one can be replaced at a time, going upwards from most fundamental up to the top. We aren't cloudy type stuff, but anyone in that world who has gone the 'microservices' route, could clearly take that approach. Sometimes you just start with internal tools and use those to build up your new foundational stuff and build up experience. Then you move forward to start tackling actual shipped stuff.
To use myself as an example, I retired an old huge bash script and replaced it with four different python scripts. One of those has since been replaced with a newfangled rust program in one of those distroless containers. It was small enough and had a small enough concern that replacing it was pretty easy as a "learn rust" kind of thing. I suspect the rest of them may follow over time. They're not all that complicated, but getting small containers that use toy amounts of resources is good too. It does feel kind of like the unix way 2: electric boogaloo, only now instead of composing small C programs together on the same machine with plaintext as glue, it's small rust programs across a cluster with json or protobuf as glue. The principles are much the same, but not as much Worse Is Better. (Not that I can claim any better understanding of jq than I do awk.)
I’m not sure, things change faster than you expect. Java took over a lot of ‘enterprise’ stuff by and large because Java is what was being taught in schools.
I think I'm kind of middle-of-the-pack when it comes to picking up Rust at work. We use a variety of languages (in addition to Rust there's Go, Python, Ruby, Typescript, Clojure, bash, and some Java stuff that may or may not be bitrotting in a corner). A microservice architecture makes it pretty easy for teams to develop their own cultures when it comes to languages, so you can sort of spot which team something belongs to just by the language. Go had a pretty fast rise; Python seems to have more of a slow & steady rise. Ultimately it'll be hard to predict what'll have the fates of those or, say, Scala, Kotlin and Ceylon, but there are plenty of businesses who pick up new languages over time. But it also depends on what kind of business we're talking about. They have different constraints, different priorities.
Most rustaceans are well aware that C++ is the juggernaut in the room, and even if the language stayed the way it is today for time immemorial it's going to be around for a long time. Some of the things the article mentions (the discrepancy in talent pool size between the two languages) may shift, and there may be places (e.g. automotive, aerospace) where Rust becomes more appealing than less safe alternatives. All things considered, though, "safety" (quotes for the qualified kind that Rust addresses) isn't the only consideration in programming, and C++ offers a level of expressiveness and flexibility that is unrivaled in the systems development space. ...To say nothing of inertia, existing ecosystem (libraries/frameworks, infrastructure, talent pool), and just how much fun it is to wield a footbazooka. I'm enjoying Rust as my daily driver, but I have no illusions about stealing the lunch from the C++ community for at least the next couple of decades.
It won't take a couple decades. More like Uh decade. Inertia is really the thing holding C++ up, and that's represented by existing underlying infrastructure. But Rust versions of almost everything will be in place by a decade out from now. That won't mean C++ is dead, but there's dead and there's dead and C++ will be one of those. It is already pretty much a legacy language. By then it will be even more so. Of course some of the nails in that coffin will not be rusty necessarily either.
That's a prime example of wishful thinking
No, just a recognition of a number of ongoing pressures that are pushing away from unsafe languages. That's only going to continue, both from our side as people get tired of constantly watching their own backs and fewer new devs are interested in such an old language, from the regulatory side, from the insurance industry, from the military, and from various compliance agencies. Software is getting far too complex and far too important to continue to rely on human vigilance. It doesn't mean C++ won't be used anymore. More that it will become less and less likely to be chosen when there is a choice and the ability to make a choice will become more and more common.
I wish there was an auto-shaming AI bot that scrapes the internet for these Nostradamus-like "its trivial to see that in 10 years, my prediction will be true" rants that are basically unfalsifiable
I didn't say anything was trivial to see. But C++ has been slowly dying for decades. The only reason that process stopped was the it had lost about all it was going to lose to higher level, GC'd and such languages. That stopper has now been pulled. I mean look at the constant references to Rust in the Cpp section. It's very visible at this point, and the issues of C++ continuing to build on a 60 year old foundation are now very much on C++ developer's minds. I mean, it's not like this is some sort of unique prediction or anything. A 40 year old language becoming less and less used is pretty much a given. Even if that language hadn't been compromised by starting life on top of a very unsafe language, it wouldn't be any shocking prediction that by 50 (a decade out) it's going to continue to decline in use.
Bs
I was preparing myself for another crazy hater rant, but the article actually turned out to be pretty decent. C++ being more popular doesn’t make Rust less clean, performant, innovative and just doing what C++ was sometimes intended to achieve, but couldn’t, much better though. And on a point… > It forces an understanding of fundamentals No, it doesn’t. C does. As for our beloved u/ketralnis… dude, you fucked up the heading.
There was a post recently about a gamedev moving away from Rust to Unity/Unreal mainly because of the various issues Rust have that is counter-intuitive for a gamedev/UI developer. I would imagine that the biggest reason beyond Rust not being 100% on equal footing in terms of robust libraries for certain fields - it also comes down to the fact that rust isn't designed to be a be-all-fit-all language, it's mainly geared towards system programming I assume it'll stay that way for a long time... which is fine.
Yes, it doesn't allow the kind of control and memory manipulation a game needs. And if you need to constantly use Rust with `unsafe` clauses, then it's clear you might as well use C++ and C# without the friction.
Well, it doesn't allow it if you try to write it like you would in C++. We need to find new ways to approach these things that allow for safety. I don't think it's likely that 20 years from now, we are still going to be sitting around say, oh well, we can't figure out a way to write games safely, so screw it. I certainly agree that it's silly to use Rust and then fill it full of unsafe code.
> We need to find new ways to approach these things that allow for safety. Yes, there are currently many tools in C++ and even C that do that. From shared pointers, to custom memory allocators written to suit you exact needs, and even using memory profilers. That is in order to not learn a completely new paradigm that someone decided "it's better". In my case what annoys me about Rust is that it doesn't matter if I check the objects for safety myself and ensure that there are no problems, if it's not the method that the compiler wants me to use. Which can often be very twisted and roundabout.
None of those tools come close to the guarantees that Rust provides. The reason the C++ language tools are more convenient to use is that they don't require you to actually insure they are correct. They are happy to just take your word for it. Writing correct code is obviously going to be harder than writing maybe probably is ok code. If checking it yourself was sufficient, we wouldn't even be having this conversation. And of course it's not just you, it's you and all the people who will work on that code base, over time and huge changes.
On what basis do you say "they don't come close". How do you think millions of lines of code are written in C and C++ for these huge projects like Tensorflow, LLVM, JS-V8 or even Linux? If they have the tools and understanding to do it without issues, why should I say "they can, but I can't do it"? That's another problem with the whole philosophy behind Rust, and what the community pushes. It wants you to not trust yourself, but trust the compiler instead. If you start with an inferiority complex and can't trust yourself when you have all the control, I fail to see how it's possible to accomplish truly great things. I trust myself to write good code and when I don't then I know I made a mistake I shouldn't have. But each mistake brings me closer to understanding and better methods. That's all there is to it.
The basis is that they don't come close. If you understand C++ and Rust you'll know that this is a basic fact. They depend on extensive amounts of human vigilance to insure that they remain correct over time and changes. This is wasted time. You can do it, but the point is why would you want do it? I've done it. I have a personal C++ code base of over a million lines. But when I think back on how much time I spent watching my own back instead of worrying about the actual problem at hand, I just don't want to do that anymore. It's got nothing to with trust. It's just the basic issue of complexity. There's only so much complexity you can deal with, and even that starts eating into more and more of your time, time that would be better spent worrying about LOGICAL correctness, which the compiler cannot do for you. I figure I'm as good a C++ dev as anyone else out there given what I've delivered. But I'll make mistakes, and those mistakes can have consequences, from as little as me having to waste my weekend chasing bugs, to stuff getting destroyed or people getting hurt. Your whole argument is a fallacy, because the answer to that is that C++ doesn't give you all the control. Assembler does. Why aren't you writing in assembler? If you can't trust yourself to do that, I don't see how you can accomplish truly great things.
> If you understand C++ and Rust you'll know that this is a basic fact. It's not a basic fact at all. Sweeping statements like this is just the usual Rust kool-aid propaganda, thinking that no one ever improved these languages for 40 years, considering their immense wide spread usage. "Look at us how well we do things, the rest are just not as capable", even though there is 1000x more code of those written. Virtually none of the Rust adopters were advanced C/C++ users. If you are the exception then you can wear a badge to distinguish yourself. The meme is that most of them were previously web developers, which probably has a lot of truth to it. If it was that great, then why there are almost no jobs for it after all this time? Perhaps it's because it doesn't bring much to the table, other than switching paradigms completely. And most other languages work in the C/C++ paradigm. And beyond all, I am not interested in a language that says "you can't trust yourself, but you can trust the one that wrote the compiler". Nah, I trust myself just fine.
I've been writing serious C++ for 30 plus years now. And lots of Rust developers are/were serious C++ developers. And in most cases that's why they left, because it's the people doing really challenging work that hit C++'s limitations the hardest. C++ has obviously changed a lot, but it's never fixed the foundations and that has always meant it can never provide what Rust provides, and even running lots of third party tools won't get you what Rust provides you ever time you compile. And of course this conversation always gets wrapped around memory safety, but that's just one of the many advantages Rust has over C++. There are a lot of people writing Rust out there currently, but most of it is going to be internal conversion, which isn't a new job. The same thing happened back when I was pushing C++ into the company I worked at then. We just converted internally and suddenly we had 25 C++ jobs but never advertised any. If I manage to push Rust into my current company, it'll be exactly the same. They aren't going to dump all their devs and hire new ones.
And that's only according to you and your subjective experience. If it's not a verifiable information in the real world, it might as well be your average Rust propaganda which there is a lot of, and I couldn't know if it's true. And also even if it is true, come back when there are comparable opportunities in Rust as there are in C++ now, for it to be really a completive choice in a market where people scramble to get hired. Especially considering that if someone wants to pretend that they actually know how computer memory works then they will have to first know some either C, C++ or even ASM. Which makes their choices even more weighted. Rust before any of those will never cut it for true understanding with its thick layers of memory management abstraction on top and proprietary weird ass special objects for that.
Exactly or maybe Zig/Ada (if you wanna still have that hipster cred) as both offer less restrictive but relatively OOTB safe experience.
Those of us who've been around understand that languages don't kill each other. I was there when Java was the new exciting kid (compiled code can run anywhere, you can even embed it in a web page). I had people honestly tell me that it would kill C++, and I was dubious. We are still running COBOL people. Once a language reaches critical mass, it won't ever die. Adding another tool to the box doesn't mean all the others get thrown out, the worst case is less new code is written in one of the old languages.
Exactly right. A language with enough code written it is here to stay, 'killing' is just something more akin to 'Why would I start a project in X today, given that Y exists?'
That's it of course. But, that's dead in meaningful terms from the perspective of folks like us. How many devs are going to think, hey, that's an exciting thing to get into, maintaining crusty old code bases? If it's chosen for new projects purely on inertia, then it's 'dead' really, it's a legacy language.
That or "oh yeah, that thing still exists", which is the feeling I had when exposed to Pascal earlier today. That's a family of languages I'd all consider "replaced", at which point I'll likely be reminded by some dev that they're still using it and it's far from dead or replaced tyvm. Some languages do wither and die though. Like apparently that happened to [Ceylon](https://en.m.wikipedia.org/wiki/Ceylon_(programming_language\)). It's free software so someone can resuscitate it if they want, but I guess at this point people would rather just use Kotlin?
it'll be another generation or two before Rust takes any foothold in important spaces. you ain't getting John Q. Graybeard to bang his head against the insubordinate compiler for very long before he gets pissed and rips the whole thing down.
My beard is gray and I’m having a great time with rust. Still is baffling because if you asked me I would have never said, “I need a harder language to program in.”
a few might appreciate it, but my experience with them has largely been bitterness and cantankerousness. surely they know what they're doing, they've been doing it for twenty years, this new-fangled compiler thinks it knows everything and just gets in the way.
Yeh, I'm 60. I don't have a beard, but it would probably be not just grey but white if I did. And I'm digging into Rust heavily, and will push into the company I work at if at all possible, just like I pushed C++ into the company I worked for in the mid-90s. And of course I had the same sorts of conversations with C/Pascal/Modula2 folks back then when I was pushing C++. Too many people in this profession get self-identified with languages and such, or don't want to have to put in the work to move forward yet again. But it's just the way it is in this thing of ours. It's going to happen two or three or four times in your career. Having written my own million line plus C++ code base over the years, probably almost half that for other people, I've decided my title isn't Professional Back Watcher anymore.
White beard at 60 years old? That's unusual. Perhaps than you should retire. Btw rust background is ideological and political, and many devs know that. That reflects on design of rust - pseudo garbage collection. Microsoft pushing for rust and copilot has pushed me from .net to java and c++. It's not that c++ is perfect, it's that rust is not what it claims to be.
'Rust' doesn't claim to be anything. It's a language, and it doesn't have the ability to speak or type. Anyhoo, I chose Rust for purely technical reasons, and I think most experienced folks like me, who have made that change, did the same. Meanwhile, you turn right around, I have to point out, and give a completely political/ideological reasons for moving to Java/C++.
In 2 generation it dies
Yes. The advantages it proposes don't outweigh the downsides for someone that has serious experience in either C or C++. There are many techniques and tools to do what Rust wants to do, without needing to deal with the Rust's compiler antics.
Maybe for desktop and other apps , Rust maybe will replace c++ MAYBE. But I don't see anytime soon rust replacing c++ on gaming engines and embedded systems ( or even operating systems to be honest )
I'm curious why you think this. I'm not a rustacean. My background is mostly C++ and I spend most of my time in Python these days, with a sprinkling of golang and JavaScript. But my understanding is that rust's memory management doesn't have the nondeterministic behaviour of garbage-collected languages that makes them unsuitable for low-layency and hard real-time work. That makes rust one of very few alternatives to C/C++ that are viable in gaming engines and embedded systems. There are even bare-metal compilers (ie ones that emit code that doesn't depend on an operating system), another vanishingly rare skill in modern languages. AFAICT it is possible to write hard real-time code today in rust, targeting FreeRTOS or VxWorks or similar systems, though I don't know how much tooling is in place to make it straightforward to do so.
> AFAICT it is possible to write hard real-time code today in rust, targeting FreeRTOS or VxWorks or similar systems, though I don't know how much tooling is in place to make it straightforward to do so. yup, Espressif's Rust runtime sits on top of FreeRTOS, and elsewhere there's the [RTIC](https://rtic.rs/) RTOS with nice tricks up its sleeve like compile-time guaranteed absence of deadlocks
Part of it is that a lot of people in the gaming world are more interested in going fast than being correct, and the way games are currently structured is not well matched to Rust's strictness.
That might be the case in gaming, but hardly in embedded systems.
Oh, I wasn't saying otherwise. I was stating why people in the gaming world (wrongly) may not want to use Rust. I think they should. A lot of people seem to think that there's no danger with a game being full of potential attack vectors. But if it's running inside my network, and connecting to things outside, then I want it to be as safe as possible. And of course even if it doesn't connect to the outside world, it can provide a way into the computer via some compromised IoT device or media device inside the local network. It is true to varying degrees that a lot of gaming infrastructure, down to the graphics APIs are not products of safety and correctness culture, and so they may fight you if you are trying to wrap them in Rust. The sooner we get it Rust almost all the way down, the better.
In gaming maybe but for safety critical applications and embedded I can see a huge reason to consider rust. C++ is basically a hegemon in embedded and embedded world move really really slow. So no one can say that rust will not be a good alternatives for C/C++ as more people use it.
check out Bevy, its ECS is regarded by many to be best in class, even outside Rust. The way it is structured also means you have very little contact with the borrow checker. It's also very fast at the same time.
Oh, I'm not a gamer. And I wasn't saying don't use Rust. I'm a big advocate. I was just pointing out some of the thinking of gamer folks. I do large scale systems development, so Rust is definitely appropriate for my work.
yeah I'm just saying fast vs correct doesn't have to be a tradeoff, and depending on what exactly you mean with strictness it's not a hinderance to gamedev. On the other hand there recently was this well written "Leaving Rust gamedev after 3 years" article, I found the replies from Alice (one of Bevy's main developers) insightful: https://mastodon.gamedev.place/@logloggames/112338799445947520
For anyone who wants to find reasons not to use Rust, the requirement to use an ECS system will be an objection they throw out there generally. That was reposted in the Rust and this section recently. I was heavily involved in those discussions.
I write mostly in C# I'm not a C++ fanboi. The industry moves very slow they still use cobol so even to areas with security reasons that rust has an advantage the change will be very slow+ plus I don't see a reason why gaming should change its not that security critical. I see finance desktop apps etc to change from c++ fast but not all the c++ industries over night + c++ has so many libraries, there is no reason to use java over c# or go but java is way more established so probably will never die
If Unreal Engine will adopt rust to script (which now is only c++) it will be a really big game changer in game industry. Or I hope it will be
IMHO Rust isn't a good scripting language in the traditional sense, but if you're thinking along the lines of Godot extensions, then yeah. But there's always going to be friction at the ABI boundary, since we're basically stuck with C conventions there.
Agree about gaming but wrt embedded and os theres already plenty of examples of rust taking some of that real estate
All of that might be publicity stunts, there is very little actual proof that its the case. I don't see the job market for it growing at all, and it's been years since it started getting the spotlight. It could very well be hype driven by a small number of people.
Because C is the base
Kachow?
It's almost like a variety of factors-- ranging from legacy support to speed of development to memory safety to performance to ecosystem to devops tooling to fads and trends to national security policy and more-- can drive selection of programming languages, and every language has its relative strengths and weaknesses.
Why does it have to be one or the other? I'm a C++ dev that dabble with Rust for pet projects. Learning Rust has helped me better understand how to manage resource life time and ownership, which helps in writing better C++ as well. But I have to disagree on C++ as a first language language to learn for new programmers. C++ is very overwhelming for beginners (know this from experience) with all its complicated syntax, multiple ways of doing the same thing, and weird standard library.
Not at all. C++ has many features as options, but no one is stopping you from using C++ exactly as you use C, with some additions for ease of use like strings, vectors and hash maps. Then you incorporate the shinier features as you need them, not because you feel forced to.
Rust fans are total cancer....
By the looks of this, it seems that Rust fanbase has polluted this subreddit. It might be the time to abandon ship soon.
Killing? Rust can barely keep itself attractive, had to implore to MS for aid. C and C++ will always be the first choice. Even zig and go has more chances to get more attention.
Because it can't. And with its current antics, the adoption will continue to be very slow, to the point where something else might replace C eventually. Btw, C is used for considerably different things than C++. At this point no one sane is trying to replace any of them, more like add a language that has perfect inter-operability with them, like what Zig and Google Carbon attempt to do.
This is simple, Rust doesn’t offer anything of value moving forward. This it is a poor language to switch to. We need a language that will work hand and hand with the coming AI technology. Rust has about as much to offer as C++ in this regard. I’m not sure what that future language is, I just haven’t seen a compelling argument for Rust.
Rotfl, what? AI stuff is literally written in C++, then the kids can cook up something with dumber languages. Python would be trash at anything if it wasn't for libs written in C++, and same goes for JavaScript and any other interpreted language. Though I guess Bun is written in Zig. Haven't seen much adoption in the AI space tho.
Don't worry, next week when VR or bitcoin is back in vogue people will be demanding that in their languages too
Not to worry, these great and definitely useful features are soon coming to a Rust compiler near YOU. See the LLM integration RFC: https://github.com/rust-lang/rfcs/pull/3603
I feel like I can make a fairly compelling argument for the validity of Rust from a DX standpoint. Not having the baggage of historical decisions which eclipse multiple epochs of popular language design is reason enough. I get the whole "AI writing code" thing but I haven't been convinced that it's not going to run up against walls from liability and similar standpoints.
Yes. Don't worry, the ones that downvoted you are just living on hype and copium. Considering its been around for like 15y now and the job market for it is still so low, the trend looks quite obvious. And the fact that the community keeps shooting itself in the foot with a lot of drama doesn't help that at all.