10 ms·
Ask HN: What is preventing rust from replacing c/c++?
- kierank 9y agoPeople to write code instead of sitting on their high horse. That and performance as good as c, not c-like, not selective benchmarks, not other nonsense.
- symlinkk 9y agoOver 30 years of momentum.
- jfaucett 9y agoBasically I think it boils down to the fact that the c/cpp tooling is actually really sophisticated at this point and developers have already learned how to deal with the pain points of c/c++ so there is little incentive to change. Especially, since it means swapping out a highly advanced ecosystem i.e. UnrealEngine for the chance to spend the next 5 years building your own not-as-good system to then be able to start to program your own game. And its like this in every C/C++ industry I'm aware of (embedded devices / games / desktop apps). I'm a rust fan, even more so of cargo (wish C/C++ had a cargo). But at the end of the day it almost always boils down to transition costs vs. benefits, and the benefits currently don't outweigh the transition costs IMHO.
- hackits 9y agoYou only need a some major players and big names to get behind rust and I would bet it would surpass C/C++ code-base within a couple of years. It wouldn't replace major frameworks or libraries written in C/C++ but I it wouldn't take much work to write the wrappers around them anyway.
- eej71 9y agoWhile such support might be helpful, the majority of systems in C++ that I've seen are significantly larger than the libraries they are consuming. In other words, such library wrappers are but a scratch on the surface of the system. I often wonder - how big does a code base have to be before an advocate of these ideas (ie: "rewrite it in X cause X is abstractly better") might be inclined to backpedal and reconsider their advocacy?
- hackits 9y agoI found working with Operation Flashpoint/VBS2/Arma 2 that the code base being so large and so many edge case conditions that it will never re-written. One example from the VBS2/Armed Assault 1/2 they replaced the way arrays references are handled. Previously array's assignment was a copy. They changed it so array's assignments would mirror java's references and only the pointer to the buffer would be copied eg.. copy on write. They had so many idiotic edge case conditions that they reverted back to the old method. So when I say they just need some major backers it would be for new system and applications that would take advantage of the new language. Re-writing most game engines today doesn't have a strong business case. Writing new games/software and shipping faster is more important.
- memracom 9y agoI think you are correct in regards to the people who are currently using C/C++. They already have done the hard work to make it usable for their systems. But newer developers will look at the complexity of C/C++ development and choose anything but. Maybe it is like politics, rather than attacking your opponents you should offer something that they do not. Then you will build your own constituency and gain influence. It will take a long time, but if you keep on providing benefits to users, then attrition might take you to the top. When someone attacks your camp, ignore them. You do not need a better way to attack them, you just need to stick to the knitting and make your offer provide benefits to users. External forces will likely decide whether or not you overwhelm your opponents.
- AstralStorm 9y agoThe problem with this approach is that you would really have to offer something groundbreaking to displace C and C++ while also matching portability (only matched by Java variants) and performance (often unmatched). The about only languages that could compete right now are extended Ada for high assurance environments and Fortran variants for HPC. They are old but not dead and quite usable if you have the dollars to buy proprietary or invest time. Microcontrollers and constrained environments are another critical niche for C and C++, especially given proprietary compilers. Rust does not go far enough in safety to displace Ada (or Spark variant) while not offering improved performance and comparable portability with all the pains of a new language. It also does not do build once deploy everywhere stuff Java and JS attempt. Rust is neither here nor there. A good effort but not a solution.
- smt88 9y ago> you would really have to offer something groundbreaking to displace C and C++ while also matching portability If you offer something groundbreaking, you don't need to match portability. Many people will be willing to make the tradeoff. > Microcontrollers and constrained environments are another critical niche for C and C++ Why do you assume Rust can't be used for these niches? I understand the potential issues with old environments, but what about modern/future ones? > It also does not do build once deploy everywhere stuff Java and JS attempt. Rust compiles to JS today. It will eventually compile to WebAssembly.
- fuwafuwa 9y agoCode already written in C/C++. I don't think there's anything stopping Rust from snowballing at this time. It's built some very strong libraries for certain problem domains, and because there's package management, it's possible to reuse it. This has already substantially reduced the friction of "systems" programming since you don't run into a challenging build process. But for the majority of folks the answer for an immediate need is still a tool or framework they already use.
- twobyfour 9y agoInertia. You don't rewrite an existing codebase unless the current one is simply not capable of doing what you need it to. And there are a lot of existing codebases in C and C++.
- AstralStorm 9y agoEven when you do rewrite, there has to be a clear benefit. Rust does not offer a clear one. (No, reducing amount of bugs does not do anything when pitted against well tested mature software that already exists.)
- mmstick 9y agoRust does much more than reducing bugs. It is able to reduce memory consumption, decrease the required amount of CPU cycles, and increase maintainability / adaptability. ADTs aren't a joke, and neither is Cargo, move semantics by default, and the borrow checker / borrowing and ownership mechanics as a whole. Shipping solutions in Rust can be done at record speeds, and integrate with existing software. Rust is wildly successful, and there's no way of stopping it.
- AnimalMuppet 9y agoChanging languages isn't free. Rust isn't enough better than C++ for most developers (or their management) to switch. Or, if you're more of the skeptical sort, Rust doesn't seem to be enough better. You could argue that C++ developers don't think they write code that creates memory issues very often. So they underestimate the benefits. (And the borrow checker is a different concept, so they may also overestimate the costs of switching.) The net result, though, is that they perceive the benefits to not be worth the costs.
- JoeAltmaier 9y agoPerhaps they estimate the benefits correctly. In that case, they may never switch.
- AstralStorm 9y agoMore modern styles of C++ just wholesale avoid most problems that are solved by the borrow checker. Smart and owning pointers, dynamic and checked data structures thanks to operator overloading. There are remaining warts but not bad enough in practice.
- jjpe 9y agoThat's not really all that relevant for most existing commercial code since legacy code tends to not get rewritten at all unless it's absolutely necessary, and thus remains stuck with the Old Ways.
- AstralStorm 9y agoIndeed, but unlike a rewrite, you can refactor staying in the same language at your leisure, piece-wise. Plus the argument was mostly pertaining to new code.
- fulafel 9y agoWhat's preventing the tree you planted from replacing the old tree next to it? Nothing really, ask again in 30 years. Software is slow, your OS and browser have taken 20+ years of C/C++ development with top professional development teams to become the nearly tolerable products they are.
- mhink 9y ago> What's preventing the tree you planted from replacing the old tree next to it? Nothing really, ask again in 30 years. That's... actually one of the best descriptions I've ever heard about these tradeoffs. :)
- altotrees 9y agoI would've started using Rust way sooner if academia hadn't forced me to use c++ or c for anything systems related. Upon graduation I felt like a kid in a candy store with all the languages and platforms I hadn't tried in my four years of fun.
- solidsnack9000 9y agoIf it happens, it will take some time. Java has been replacing C++ for many years now...
- deleted 9y ago[deleted]
- szemet 9y agoA big difference is that Rust has a zero overhead interop with C, so it it allows mixed projects or gradual porting. So Scala or Kotlin replacing Java, or F# replacing C# may be a better analogy. What happens there, is that Java and C# are improving just enough that many people are simply not considering the change... And C++ are trying really hard nowadays too - new version with interesting features every few years etc... (By the way - I'm a Rust fan, and also a functional programming fan, so I would be happy if C++, C#, Java would slow down a little to let the alternatives really catch up popularity;)
- solidsnack9000 9y agoI am actually on your side on this one. But the changeover, I think you will agree, will be somewhat slow. So no one should judge Rust too harshly, for not replacing C++ in the Unreal Engine, Microsoft Office Suite, &al. even in the next 5 years.
- joshAg 9y agoTime.
- Sag0Sag0 9y agoAlso some people just do not like coding in rust and that combined with the fact that its new means they refuse to switch.
- nolepointer 9y agoProbably SJWs.
- jlarocco 9y agoWhy would it? As a C++ developer, I think Rust's main selling point (memory safety) isn't as big of a problem as it's made out to be. For every unsafe memory access that results in a crash or exploit, there are millions and millions of memory accesses that work just fine and never cause a problem. Tools like Coverity and Valgrind can catch a ton of errors, and its not clear Rust offers any significant advantages over C++ with Coverity. Parallelism is nice, too, but C++ already has a ton of options there: OpenMP, MPI, TBB, OpenCL, standard library threads, boost/standard library async tools, etc. On the other hand, as an end user, "written in Rust" or "written in <any language>" isn't something I care about. I don't even remember the last time I had a piece of software crash due to a seg fault, so a vague promise of being "safer" isn't good enough to accept an otherwise inferior product. I guess to summarize, C and C++ developers are going to keep writing C and C++ and if Rust is going to take over the world, the people advocating for it will have to write better software in it and beat out software written in the other languages.
- xfer 9y agoCoverity is expensive and majority of software people use are open-source which don't make use of it(hence all the CVEs). As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics. To comment on your last point, it's seeing some light already, ripgrep is already beating grep in performance and is purely written in rust. And i agree that this is how rust will beat C++(if ever), by writing "better" tools than those already exist.
- AstralStorm 9y agoThen why Ada isn't used more in servers? See, people don't care about safety, they tend to want the language to get out of the way. C++ does that because it does not get in the way of a C standard library. Or other system specific stuff. Rust gets in the way enough that the benefit seems not worth it, and it brings few benefit in the server space over, say, Java if performance is not the paramount concern.
- jlarocco 9y ago
- afuchs 9y agoWhy hasn't another language, like Ada with similar goals to Rust, replaced C/C++?
- ktta 9y agoBecause they didn't have the might of Rust Evangelism Strikeforce behind them
- acomjean 9y agoIts the operating systems libraries. They're in C. I did a lot of ada programming (radar) and we had a fairly large library of wrappers to the C network/ ipc / process control that the operating system provided. It was a royal pain. So much so that at least a couple subsystems moved to C (mainly to use the math libraries......)
- AstralStorm 9y agoMore modern styles of Ada work pretty well. The trouble is in getting the code to run in a restricted environments. MCU compiler authors tend to provide C only. Perhaps a transpiler would be better.
- wbond 9y agoFor me, equivalent support for the MSVC toolchain on Windows. Obviously it won't ever be 100% without support from Microsoft, and a lot of work has been done, but some items on https://github.com/rust-lang/rfcs/issues/1061 https://github.com/rust-lang/rfcs/issues/1061 feel important enough to give me pause before spending much time with Rust.
- steveklabnik 9y agoI use it daily, and it works well. I'm still a newbie Windows person so I probably don't notice these pain points...
- trelliscoded 9y agoGreenfield systems work by startups isn't really done these days. If it's not greenfield, it's probably already in c/c++. If it's not a startup, they probably already have a bunch of expensive c/c++ tooling (static analyzers, IDEs, CI systems, ...) that they aren't going to get in rust.
- mmstick 9y agoRust has made major strides in the cryptocurrency industry. Cryptocurrencies are largely becoming powered by Rust, because with cryptocurrencies, there is no room for error.
- memracom 9y ago1. Rust is not C/C++ 2. Lots of software is already written in C/C++ 3. Rust follows the same convention as C/C++, that you integrate functionality by writing a library, compiling and linking it into a monolithic binary 4. Systems that rely on a monolithic binary are NP hard to replace with something different 5. Replacing a monolithic binary works best, in practice, when it is done by refactoring into services that are integrated by something other than a link editor. Although the buzz is all about web microservices, the reality is that message queuing to tie together microservice, macroservices and monolithic binaries, provides better performance more consistent with the linker/monolithic model. 6. Go with its channels and packages may be a more advanced model, and is also competing with Rust. In other words, it is not just a question of comparing Rust to C/C++ 7. The JVM with its JIT has in many cases equaled or exceeded the performance of C/C++ monoliths, but languages like Clojure and Scala take it well beyond mere Java. 8. It may be that replacement of systems is driven more by economics than by technology. In other words it is not Rust that will determine the fate of Rust, but the economic sucess of companies using Rust for mission critical systems. In 20 to 30 years, the businesses that have succeeded will determine which technology is better.
- AstralStorm 9y agoJava Achilles foot has always been memory use and really compute constrained environments. Things like high end video game engines are not being written in Java, Closure or Scala for these very reason. I would be very careful about JIT performance being even close. See, the language does not even expose SIMD well. Doing anything hard realtime (heck, even more complex UI) with a JVM in the way is a big pain.
- deleted 9y ago[deleted]
- kennywinker 9y agoJust one data point, but: I'm currently learning about embedded microcontrollers. The standard starting point for this is arduino, which is C/C++ based, so there is a strong pull towards C++ already. But I really wanted to avoid C/C++, and I spent a long time researching alternatives. Rust was one of the most mature for MCUs, but a) it's not very mature and b) you have to pick an MCU with a lot of flash memory as even the smallest rust binary is >100kb. For reference, one of the chips I've been testing out for this project has 127kb of flash. This evening I loaded on a medium-sized C++ project and it took just 24kb. So that's what's preventing ME from using rust instead of C++
- johnny22 9y agowhich one generated a 100k binary? I see it running on an uno right here, which has less than 100k https://github.com/avr-rust/arduino https://github.com/avr-rust/arduino Were you using zinc or some other project as the base? I figure it is an arm cortex * in your case.
- kennywinker 9y agoI was using the standard rust compiler, plus a bunch of articles on thinning rust binaries. Best I managed was about 80kb after three or four layers of thinning. That link is pretty interesting! The Rev3 uno has 32kb flash, so someone has found a way to thin the binaries enough to fit on an MCU. Cool.. now if only I knew how they did it!
- johnny22 9y agosee how zinc does it https://github.com/hackndev/zinc https://github.com/hackndev/zinc EDIT: Zinc seems to not have been updated in awhile I'm not sure what the current status is of other mcu efforts. I bet some of the other rust folks can elaborate.
- kam 9y agoThe size of a binary statically-linking libstd and targeting a desktop OS has nothing to do with the size of a binary targeting a bare-metal microcontroller where you use only libcore. If you compile for a MCU target with MCU-style code, your code size will be in the same ballpark as the equivalent C++.
- childintime 9y agoI guess that, if you can dislodge C in the embedded space, everything else will follow. So my question is: when can I use Rust on the Cortex M0 (or on a 32 bits RISC-V), with an interactive debugger, preferentially from a simple IDE?
- steveklabnik 9y agoCortex M works today, but since I'm not in the space I can't comment on debuggers or IDEs.
- AstralStorm 9y agoRust produces quite fat code even without safeties on and when using a tiny libc... If you have megabytes of flash to spare, it could probably be fine...
- steveklabnik 9y ago> even without safeties on Most of Rust's "safeties" are only compile-time, and so have no effect on binary size.
- AstralStorm 9y agoMany of them cost nothing over base rust tax, but that is not the issue.
- goodplay 9y agoAnother reason that I don't see given its fair chance might be politics. The human race has a wide variety of values that are often counteracting. Forcing a specific set of values participants must adhere to in order to interact with the community will undoubtedly alienate adopters. That's why most projects, companies, and even governments tend to strip down the rules that govern them to what is necessary for them to function (e.g. separation of religion from state for governments). The common reason given by the rust community to justify their behavior is that technology does not exist in a vacuum, and that technology can not be separated from politics. I completely agree. However, politics should be tackled on a layer incompletely independent from technology. Mixing the two only causes instability and uncertainty for rust. Here are two risks that arise from this mixing. I'm sure there are many, far more serious, risks besides these two: - What happens when (not if) a significant shift in values occurs in the community? Will it collapse? - What about technical or legal changes to the project that were driven by community values rather than technical or legal merits? This is not far fetched when technology and politics are made inseparable in the way it was done in Rust. I use rust in a professional context, and I appreciate what it brings in terms of technical benefits. but I would be lying if a said this aspect of it didn't worry me. I can not recommend its adoption to colleagues from other companies if asked for this very reason (I was asked once so far). Community instability or the mere perception of such is a big barrier to adoption, at least for companies.
- mmstick 9y agoUsing a programming language does not force you to join a community; and what is the Rust community, anyway? Which Rust community? The Code of Conduct pertains to the official venues of communication, not the language itself. All communities have rules. And the rules are quite normal of any community that wants something resembling civility.
- flukus 9y agoBinary compatibility. As a developer I want to be able to: 1. Write an app in rust. 2. Use a rust library in that app, via the native rust interface (using c interfaces negates a lot of the pros of rust). 3. Dynamically link that app to the distro repository version. 4. Have the distro apply security updates to that library without recompiling my app. 5. Ignore cargo completely. As a user I want to: 1. Not download and install multiple copies of common rust libraries (as is the cargo norm). 2. Not be in doubt whether a particular application is using the latest patched libraries. It seems that rust community has learned from the mistakes of c, c++, and java. But they failed to learn the successes as well.
- jjpe 9y agoWhile your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it. As for the multiple copies issue with Cargo: I generally agree with you that this definitely feels like 1 source of major blow up in project compile times, and it would be nice and useful if that were reduced as much as possible. But there is a reason that this system is in place: each crate defines how it compiles and consumes its dependency crates, so if crates A and B both depend on crate C, then A might compile and consume C differently than B does. This results in effectively different libraries once compiled, and ATM there is no way to predict in advance what the effect of any given compile flag will be since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C dependency separate from B's. Then there's the not doubting whether an application uses the latest patches. Up to a point, this can be automated through exploitation of SemVer: if Cargo could figure out that a new library version is API and ABI compatible with the previous version then I'd argue that Cargo should perhaps just auto-update it. A bigger issue is what happens when a new major version of the library is released, as those tend to break APIs in order to perform maintenance. That is something that as of yet has not been automated.
- flukus 9y ago> While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it. It's a rust issue because it's up to the rust compiler to generate ABI compatible binaries, at the moment there is no ABI so there isn't much distros can do. It seems they have no intention of adding one any time soon: https://github.com/rust-lang/rfcs/issues/600 https://github.com/rust-lang/rfcs/issues/600 This is why system libraries are nearly always in c and not c++. The ones that aren't (Qt) have a long history of broken language bindings.
- cbanek 9y agoIt doesn't need to replace it (it's not like c++ is being deprecated), and there has to be real reasons to port over existing code, because there are real costs. The technically best format doesn't always win. Just look at Betamax vs VHS.
- nickm12 9y agoThis question is both a leading and also ill-posed. What is preventing Rust from replacing C/C++ _where_? In existing applications? For new code development? In some particular application (e.g. game engines)? There are lots of good answers in the comments here. I think Rust has a good story for why you might choose it over C/C++ for some uses today, but it's still early days. If Rust is going to take share from C/C++, it will do so over the period of decades, not years.
- jstewartmobile 9y agoThe chorus of Rust zealots who can't let a week pass by without writing yet another "Why won't you stupid plebeians stop using C++?" article. That alone makes me want to crack open some STL code just to spite them, and I hate C++!
- Turing_Machine 9y agoRust will never take off until someone (or some group) uses it as the basis for a new, mind-blowing, must-have thingie. For C it was Unix. For JavaScript it was the web. My guess for when something like that will happen with Rust? Never. Unfortunately, verbose, anal-retentive languages like Rust are simply poorly-suited for writing new, mind-blowing, must-have thingies. On the scale of languages that support exploratory programming, I'd put Lisp at the top, JavaScript fairly near the top, C somewhere above the middle (though it was quite close to the top when it was new), and Rust somewhere down in the FORTRAN and COBOL region of the spectrum. Note that this is completely orthogonal to type-safety, running speed, or any other traditional measure of programming language merit. The shoals of the language ocean are littered with the wreckage of "better" languages (the various Wirth languages, e.g.). What really matters is whether a programmer can sit down and casually explore a cool idea in a few minutes of spare time, and you can't do that in a language that requires half a page of code to concatenate two strings. Swift has managed to roll type safety (more or less) into a language that's actually fun to use, or at least not actively painful. Rust hasn't.
- frik 9y agoElixir brought a sane syntax to Erlang. A Swift or Go inspired simple syntax could revive Rust.
- AstralStorm 9y agoSyntax is not even really a consideration. See how much people put up with in Perl and PHP world. PHP used to be language for web until displaced by JS.
- frik 9y agoThat's your opinion. PHP, JS (nowadays to some extend also Go and Swift) are so successful, BECAUSE they have a simple and C-like syntax. Rust syntax is rather an afterthought, unfortunately.
- burntsushi 9y ago> What really matters is whether a programmer can sit down and casually explore a cool idea in a few minutes of spare time I've been doing this for years with Rust. I'm doing it right now, in fact! The most popular piece of software I've ever written started off as a fun experiment in Rust on an airplane ride. > and you can't do that in a language that requires half a page of code to concatenate two strings. Great news then! Rust doesn't require half a page of code to concatenate two strings.[1] [1] - https://play.rust-lang.org/?gist=ed677c7e279f406d0be1c7f70b540259&version=stable https://play.rust-lang.org/?gist=ed677c7e279f406d0be1c7f70b5...
- IshKebab 9y agoPartly time, but also it's much more difficult to get "something that works" in Rust than it is in C++ due to the borrow checker. Of course your C++ code will probably not be as safe as your Rust code, but many people don't care about that.
- AstralStorm 9y agoIt probably will be just about as safe. The benefits of the borrow checker only become apparent when you're doing complex things. C++ allows you to write bad code easily though, though the most obvious modern way is safe typically. At least until multiple threads or processes happen or you have hard realtime requirements.