29 ms·

Ask HN: What is the state of C++ vs. Rust?

154 points by manaskarekar 10y ago

I would love to hear the thoughts of people who have kept up with the developments in both these languages. Some of the stuff I'm wondering along is features, safety, performance, simplifying the language and so on. C++11/14 brought good things to the table, perhaps C++17 will bring more improvements? I havent gone through the proposals for upcoming features in either language but seems like the pace of Rust development is really good. But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether. Just curious to hear anyone's thoughts on the state of these two languages.

seren 10y ago
Rust is promising but C++ is here to stay. If you have a legacy C++ code base, it is much easier to sell that you are just upgrading the compiler to get new language features, that you are rewriting everything from scratch. Now we'll have to see in the next few years if, for new projects, Rust is chosen over C++ wherever it was used traditionally and in which proportion.
- bluejekyll 10y ago
  Like all legacy code, it will not be replaced. Now if people wanted to bifurcate their codebase they can easily add Rust libraries to existing C++ codebases. In my experience I find Rust to be more productive than C++ and easier to write. Obviously that's a pure opinion.
  - Someone 10y ago
    "they can easily add Rust libraries to existing C++ codebases." Is that truly easy? I would expect all kinds of incompatibilities that would require going through a C layer (object layout, difference in virtual method calling, object ownership, etc). For example, calling a C++ function that takes a pair of iterators from Rust and returns a std::map, passing iterators pointing into a Rust hash table, is that easily done?
    - bluejekyll 10y ago
      Well, it depends on the strategy you use, but yes, you're right that it's hard to share strict/objects. But if the API boundary between the two is kept simple and small, then it's simple. Take a look at the rust ffi omnibus that I posted in this thread. It's object examples show some decent strategies.
  - seren 10y ago
    I do agree with you, and I hope this is the future. However, in big organizations, which are not exactly nimble, this is even hard to say, "Okay we've been developing in C++ for 20 years, now the next part of our infrastructure will be written in Rust". This will be seen as an unwanted risk, associated with a training cost. You will have to demonstrate unequivocally Rust's advantage.
    - bluejekyll 10y ago
      Yes, companies that don't want happy employees make these types of monetary decisions. It's their responsibility to their shareholders to do this. It comes at the expense of long-term support of their software though. There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way.
      - Yoric 10y ago
        > There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way. I tend to agree with you (and I'm a big fan of Rust), but I'm nearly certain I heard people saying exactly that ~20 years ago. I don't remember which was the language that was expected to replace C/C++, perhaps Java or Obj-C or perhaps some variant of ML. So far, it hasn't quite happened. While C/C++ seem to have become much more niche languages in these ~20 years, I suspect that they won't become legacy language any time soon. Now, I may be wrong. Maybe some revolutionary Rust-base game engine (VR engine? IoT platform?) will shift the landscape drastically any day now, but that's hard to predict.
        pjmlp 10y ago
        Well I believe that if Microsoft had made .NET as they originally were thinking of doing, meaning having .NET Native in 2002 instead of 2016 and not having the internal fights between Windows Dev and DevTools, maybe C++'s role on the desktop wouldn't be what it has turned out to be. On the Apple side of the fence, C++ was mostly used for IOKit with everything else that wasn't inherited from UNIX, being Java or Obj-C. Only later on they decided to drop Java, focus on Obj-C and their C++ usage only increased when they decided to sponsor LLVM and move their toolchains to it. Now we have LLVM as one of the major research compilers available, including for Rust, with all three major desktop companies sponsoring it. However I think this is probably the area where they will stay, systems programming infrastructure.
- k__ 10y ago
  I think culture will do its thing here. Getting into C++ now is harder then getting into Rust.
  - zbuf 10y ago
    Fantastic observation and concisely put. I've heard people stating that C is gaining more ground that C++ and it could be for, I imagine, similar reasons. The poster asks whether new C++ will bring more improvements. It will certainly bring more... "more". And with it, the bar to entry is raised a little more; every new feature designed to resolve some issue or edge-case with a previous addition.
    - k__ 10y ago
      I think the problem isn't a technical one. Mozilla seems to put much time into getting the community right, which will get much younger people on board. Then time will do its thing.
- vesak 10y ago
  Java is promising but Cobol is here to stay. Kind of true, but one can rise in popularity while the other dwindles, even if not completely dying. Thing is that 90% of new developers who get to see both Rust and C++ will choose Rust.
  - FT_intern 10y ago
    but the companies that they want to work for have codebases in C++
agentgt 10y ago
This is all personal opinion so take it with a grain of salt. I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or have a worthy alternative. That is I think Rust really needs a killer app/platform/problem similar to how Swift has Apple devices and DevOps now have Go. If Rust could get into a gaming platform or have a really good gaming library like Unity it could have a good starting point to move over mind share. Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had). Rust's current niche (ie users) is language aficionados which historically hasn't been a good niche (ie Haskell) for language propagation. That is I think Rust could get more popular if it can get heavily used by a set of niche users at first. Besides mircoservices and games an interesting niche might be Arduino and IOT [1]. That might be a good niche/platform to dethrone C++. [1]: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/ http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...
- bluejekyll 10y ago
  For those not aware of it, Tokio https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio is a platform that is being built on top of Rust Futures for building exactly these types of services. It's built around futures and mio, so Tokio services are async, and elegant.
  - mastax 10y ago
    I'd say if you want to build web-backend type services in Rust right now, you'd do alright. Hyper, mio, diesel, etc. are all pretty good. I do think (and hope) that things will be much more compelling in a year once tokio and its library ecosystem have matured. Tokio's abstractions seem very compelling.
- mi100hael 10y ago
  > Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had). I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, etc. Building something in Rust would be much more painful.
AshleysBrain 10y ago
I have a large existing C++ codebase but haven't worked in Rust yet. But from what I've seen, Rust looks like a very well designed language that has the low-level and performance aspects of C++, with similar flexibility. IMO the killer feature is the borrowing mechanism which provides provably-safe memory access, eliminating whole classes of memory/security bugs, with minimal performance impact. I don't think C++ will ever expand to encompass that. I haven't got much experience with the Rust toolchain but I think that's a strong reason to seriously consider Rust for any new projects.
rlnunes 10y ago
I have a big C++ legacy code, and it gives me a lot of headhaches. I'm using Rust in some small projects and it's great, no problens with null pointers :). I think a great feature of Rust is that it is easy to use inside C/C++ projects, so u can upgrade your current legacy code without rewrite it :)
- xjia 10y ago
  Do you mean C/C++ and Rust interop? Maybe link them together to form the final executable binary? Can you share more experience on how do you do that?
  - bluejekyll 10y ago
    Rust produces standard linkable system libraries. You can produce dynamic libraries or static libraries on all supported platforms. For actual examples of using Rust with other languages through these libraries this site is great: http://jakegoulding.com/rust-ffi-omnibus/ http://jakegoulding.com/rust-ffi-omnibus/
    - computerphage 10y ago
      More information about platform support can be found here: https://doc.rust-lang.org/book/getting-started.html https://doc.rust-lang.org/book/getting-started.html
  - carols10cents 10y ago
    Not the OP, but I did a talk on an incremental rewrite of a C library to Rust [1]. Rust has good FFI capabilities with C and other languages through that [2]. [1]- https://github.com/carols10cents/rust-out-your-c-talk https://github.com/carols10cents/rust-out-your-c-talk [2] - http://jakegoulding.com/rust-ffi-omnibus/ http://jakegoulding.com/rust-ffi-omnibus/
  - rlnunes 10y ago
    linking a static lib with rust and linking with the final executable. other users posted the links I used :)
alexnewman 10y ago
They are both great languages but rust is clearly the one that experts in both generally prefer. I have some friends who make some strange arguments for c++ but I continue to be interested why people don't want to make the switch. That being said LEGACY
- esrauch 10y ago
  I would be careful about what you generalize from "experts in both generally prefer rust", as there is likely a survivor bias in there. Since C++ has been around much longer the situation is likely "many C++ experts try Rust, the ones that love it become Rust experts", basically if "preferring Rust" ends up being a soft prerequisite to becoming a Rust expert then those who are experts in both will prefer Rust. I also think there's a bunch of other factors that lead to a similar bias: general pride in favor of the less mainstream languages, for languages like Rust or Haskell it is probably the case that more of the code in that language is written by "hardcore" people, which means code written in that language is higher quality (but not necessarily through any intrinsic benefit of the language, instead through a selection of who is writing that language).
  - fiedzia 10y ago
    > not necessarily through any intrinsic benefit of the language, instead through a selection of who is writing that language I'd say that such selection is intrinsic benefit of the language.
    - esrauch 10y ago
      I just meant to point out that if broad usage actually implies worse average code, then the same thing would happen if rust "wins". You can't use it as an argument for what should win since "has won" will always lead directly to a "shouldn't be winning" argument.
- sidlls 10y ago
  I have just a couple of points. First, please be careful with the "experts" broad brush. Not all, and possibly not most, experts will agree on many things. Moreover, actual experts will understand that there are pros and cons that are context dependent. I would hesitate to label as "expert" anybody who categorically prefers one over the other for all cases. That's more like zealotry than expertise. Second, for my part the biggest hurtles are in two parts. One is that at the boundaries of speed versus provable safety. At some point I don't need and can't afford the cycles added by boundary checks and other Rust guarantees, and the mechanisms provided to mitigate them are as cumbersome as writing (unprovably) safe C++ code (e.g. "const&", "std::move" and other similar constructs) compared with the equivalent Rust. The other is a more a branding problem: gratuitous maligning of C++ is problematic, and projects a sort of arrogance that I find subjectively distasteful.
JoshTriplett 10y ago
I find this comparison much easier than comparing C and Rust. C has an extensive and still unparalleled set of libraries available using the C calling conventions; both C++ and Rust can call those libraries but often want a translation layer that adapts to the conventions of the language. C++ and Rust both have extensive libraries of their own; while C++ has been around longer, you'll still often find yourself needing to use a C library because a native C++ library doesn't exist. (It doesn't help that C++ has gone through several ABI changes, and still doesn't reliably have a cross-compiler compatible ABI the way C does; even clang++ and g++ have had various incompatibilities, and still prefer separate C++ standard libraries. C remains the reliable ABI for libraries.) While I'm impressed with the changes in modern C++11/14/17, it has both the feature and problem of still including classic C and C++. There's a reasonable subset of C++ to program in, but nobody can quite agree on what that is, and a codebase can't easily enforce that. And C++ is still a very large language, with quite a bit of surface area in the language itself; I prefer a smaller language with a large library ecosystem. Rust is still quite young. It's incredibly fun to program in, has the most welcoming community I've ever seen, and can help you write safe, expressive, high-performance code. (Tip: check out the "rayon" crate for incredibly easy parallelism.) It has an extensive library ecosystem, and a robust FFI to call (or be called by) C code. However, depending on what you're doing and and how many boundaries you're pushing, you may find some corners of the language still under active development; for instance, if you want to embed some Rust code into a broader build system that builds various other components under other languages, support for that just went into Cargo. If you're writing pure Rust code, or Rust code that calls out to C, you should find the language and ecosystem ready now. If you're trying to embed Rust into an existing project, expect to play with various experimental bits for a while.
- pritambarhate 10y ago
  >> I prefer a smaller language with a large library ecosystem I think this is the reason why Java is so popular and Go is becoming increasingly popular. The average programmer can succeed with combination and become productive faster.
vvanders 10y ago
Long time C++ dev here(~15 years) currently loving Rust. Someone can probably put together a more eloquent comment however here's my top marks. 1. No memory corruptions/null pointers. Legit holds up to the promises here. 2. The path of least resistance is single-ownership which is far and away the best way I've seen to structure C/C++ applications. 3. Cargo: Pure awesome. Simply one of the best dependency management/build tools I've used. 4. Dead simple x-platform support. Windows, Linux, all just works. Heck I just built an android arm-eabi target yesterday on windows with no NDK/etc. 5. Tagged unions, pattern matching. The best effing iterator class I've seen bar none. Once you've used these you don't want to go back. 6. Great built-in unit testing support(combines with Cargo above). 7. Amazing community, no ego and tons of people happy to help. I still work regularly on C++0x11 codebases but any greenfield stuff I've moved over to Rust fulltime. I still like C++ but it's so much more painful to use. Heck just earlier today I got bit by <locale> not compiling on OSX due to some obscure compiler differences that worked on MSVC and GCC. There's certainly good improvements coming to C++ but they have to support so much legacy code that I don't think they could ever make the large breaking changes that Rust has to produce a better experience.
- StavrosK 10y ago
  I've only used Rust lightly, but can someone explain what Cargo does differently from pip-tools? As far as I can tell, you have two files in both systems: One with the dependencies you'd ideally like to use, and one with the ones you actually used (and tested with). That way, you can update when convenient, but people who get your software have an exact known good environment. What makes Cargo that much better than pip-tools?
  - nolemurs 10y ago
    When people talk about `cargo` being awesome, they're comparing it to the similar tools for, say C++ or C or other systems programming languages. No one is comparing `cargo` to `pip-tools`.
    - computerphage 10y ago
blub 10y ago
Wrong place to ask the question. HN has a high proportion of people with an unusual interest in trying out programming languages and I would say the average visitor doesn't particularly like C++. From my point of view, Rust doesn't offer any benefits that would justify a switch. I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me. Furthermore, I think many developers obsess about languages and keep searching for a perfect language that doesn't exist and even if it did wouldn't have a big impact on productivity and the business anyway. The major challenges in organisations are of a social or process nature. They're also biased in a surprising way by social factors such as who created a PL or the community. Meanwhile PHP, Java, C++ and C# and C make the world go round. Key questions for me when evaluating whether to learn Rust (or any language): * can I get a good job programming in this? Without moving to another country or continent. * is my industry showing interest in it? * is any industry showing interest? The answer to all these questions seems to be "no".
- vvanders 10y ago
  I don't think you can unequivocally dismiss Rust, we've seen Dropbox and other companies pick it up(just yesterday Facebook announced a Mercurial alternative written in Rust). As with each case, it depends. If you've got a well scoped project that is happy with a C ABI(or just stand alone exec) I think there's a compelling case for Rust. I'd also argue if you're looking for top candidates having Rust in-house could be a perk rather than a negative.
  - FreeFull 10y ago
    To be more accurate, they didn't announce an alternative to Mercurial, but rather new Mercurial server software.
    - vvanders 10y ago
      Yup you're right, I should have been a bit more explicit there, meant to say backend replacement.
peterhj 10y ago
Rust has been pretty critical to me for getting my work up and running with minimal debugging (I'm in CS grad school, working on deep learning and optimization). I'm super productive programming in Rust, which is also generally a pleasure to write in. Just last week I had to land a pretty major refactoring (swapping out a single wrapper type for a differentiable "operator" with an implicit operator graph instead). It basically just worked out of the box as soon as I got it to compile. Definitely something to be said for working _with_ the compiler and its messages on moving, borrowing, mutability etc. (Incidentally, if I had to program exclusively in C++11/14, thanks to Rust I'd have become much better at programming in C++.)
- thecity2 10y ago
  Curious since you say you work on deep learning/optimization. I'm a data scientist who does most everything in Python, but I've been interested in learning Rust. What is the state of "data science" toolkit for Rust at this point? For reference, I regularly use sklearn, Pandas, and Spark and would be looking for similar tools.
  - peterhj 10y ago
    I'm not sure that there's a mature Rust alternative to "all of the above" quite yet. Some things that I've had to build for my own work (not always "built," sometimes I just wrote FFI bindings) include: * N-D dense arrays, fashionably simply called tensors these days ;) (this I wrote from scratch to suit my own needs, but there are several implementations of this in Rust, as well as in C++) * linear algebra (bindings to BLAS, LAPACK etc.) * numerical integration (bindings to GSL or QUADPACK) * optimization and machine learning (this I work on day-to-day) * neural networks (I also work on this) * multicore/manycore/GPU/distributed support (and this) There's also the more practical aspects of using Pandas/iPython (Jupyter)/Spark for data science, including ETL, interactive work, and plotting, which IMO are not quite there yet in the Rust ecosystem. But I think that a lot of the pieces are there, e.g. bleeding fast CSV parsing libraries (https://github.com/BurntSushi/rust-csv https://github.com/BurntSushi/rust-csv), and what's left is the important last mile of bringing these things together in ergonomic libraries or frameworks.
fiedzia 10y ago
Features and libraries aside, Rust (compiler and language) has 6-week release schedule, open and well-working update process and 0 decades of backward compatibility to satisfy. I don't see C++ improving on that anytime soon.
- sitkack 10y ago
  Rust has 0.1 decades of backward compatibility to satisfy.
throwsincenotpc 10y ago
> But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether. There is no "ignoring legacy C++", when you will have to deal with this or that library written 10/15 years ago. C++ is a language where you can't just ignore some parts of it just because they are inconvenient. As for C++ vs Rust, Rust is memory safe, C++ is not and will never be despite all the bells and whistles it gets.
- ar15saveslives 10y ago
  What is "memory safe" for you? If you use C arrays and raw pointers in your C++17 code, it's definitely not memory safe, but the main problem is that it's not modern C++.
  - steveklabnik 10y ago
    Even modern C++ isn't memory safe. Most straightforward example is to move a uniq_ptr, which makes it a nullptr, ready to be dereferenced and cause UB.
    - ar15saveslives 10y ago
      How does it happen? Non-const unique_ptr& used as a function parameter?
      - steveklabnik 10y ago
        http://www.steveklabnik.com/uniq_ptr_problem/ http://www.steveklabnik.com/uniq_ptr_problem/
        ar15saveslives 10y ago
        I can simplify your example: unique_ptr<int> p; auto n = *p; // C++ kills!
pjmlp 10y ago
My favourite languages are from the Wirth and ML family of languages, so I really like Rust. On my daily work I get to use JVM, .NET and C++. Although my C++ usage is restricted to giving a little help to JVM or .NET applications, if at all required, which happens very seldom. Here is where I still see Rust lacking, due to the language being young. On those platforms the vendor's tooling supports mixed debugging, out of box integration with their platform libraries and a few other goodies. For example, for UWP applications Rust tooling is still catching up with C++/CX and C++/WinRT. Modern C++ does feel like a rejuvenated language, but the problem is that you require a team that is willing, or able, to force it across their code. Otherwise you just get a mix of C++98, C++03, C++11, C++14, C++17, depending on which library you are looking at. Not to mention having to get your head around meta-programming tricks like SFINAE, as workaround for many of the C++17 features. So although Modern C++ feels good, there is the question when one takes a C++ at random company X, how much they are allowed to actually use from it. So I think a reboot into new systems programming languages is required, and Rust is one of the possible candidates. Which will surely get its place.
jdc2172 10y ago
Hope I don't get burned for saying it, but lack of real IDE support in rust is pretty annoying. With tools like racer you can still be productive, but things like rename refactoring or searching for uses of functions are things I miss most from languages like Java or go, which have good support. There's been some talk for a long time of a rust oracle for code indexing (to support ide use), but there hasn't been much progress (or interest?).
- steveklabnik 10y ago
  There was just a huge announcement yesterday: https://news.ycombinator.com/item?id=12739015 https://news.ycombinator.com/item?id=12739015
bjourne 10y ago
C is still significantly faster than Rust which follows that C++ is too. So unless Rust is able to produce binaries on all major platforms that are as fast as C++, people who need to squeeze out as much performance as possible are not going to drop the language.
- astrodust 10y ago
  Some people would prefer non-buggy, unlikely to crash code than fast but unstable and hard to debug code. Rust's promise is if it compiles it's probably good code, as that compiler is exceptionally picky. Most common C++ errors that cause "undefined behaviour" are not possible due to the strict checking.
- dpc_pw 10y ago
  Rust will be if is not already faster than C. Especially in real-life projects. One example would be https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep Aliasing rules in C make some optimizations not possible in C. Good luck putting that `restrict` everywhere to compensate. Generics with static dispatch makes it possible to get a code that is way better than what a sane person can write with C's preprocessor. Practical developer will very often sacrifice performance for sanity in C codebase. Memory safety makes it easy to write correct, reliable multithreaded programs in Rust and actual package manager makes it practical to reuse well-written and optimized code. Even if there are some microbenchmarks where C gives better results, it's because Rust version doesn't "cheat" by using `unsafe` constructs. Essentially in Rust one can write functionally exactly same code that C uses, including inline asm etc. which is useful for performance-critical libraries that wrap it in safe abstractions, but would be frowned upon in a tiny synthetic benchmark program that is supposed to benchmark idiomatic code.
  - bjourne 10y ago
    It is not already faster and there are benchmarks that proves that. Check out of the The Computer Language Benchmarks Game, for example. Lots of language communities make the claim that "their" language either is or will eventually be faster than C. Haskell, Julia, Go, Java, Swift... But the proof of the pudding is in the eating and so far none of these safer languages has beaten C.
dpc_pw 10y ago
I am/was a embedded dev, been using C/C++ since ... more than 15 years. I do C++/Go at $dayjob and I'm in love with Rust. I've written quite a bit of comments before on Rust, since it's not the first time someone asks similar question. You can read my past comments: https://news.ycombinator.com/threads?id=dpc_pw https://news.ycombinator.com/threads?id=dpc_pw Just to sum up, IMO: Rust blows C++ out of the water on almost everything. It's not established enough so there are almost no jobs, and there's a learning curve, lack of tools, slow compilation, business reasons, etc. so you can't just blindly use Rust over C++, but when you can and have time to learn: go for it. The existing tooling is amazing, community is awesome, you will learn really interesting stuff, save time on debugging. As for C++17 features... I don't really care anymore. C++ is death by thousands little cuts (undefined behavior is my "favorite") it's not going to change much anyway.

vvanders 10y ago

I'm not super-familiar with pip-tools however I'll try and explain what I like about Cargo. You're right on the dependencies, there's a lock file to make sure you get the exact build environment. So from a dependency management perspective it sounds similar. What I like about Cargo is it's just slightly opinionated about how you want to build a Rust project. Creating a new project is as simple as "cargo new myproject" and boom, away you go. Same thing with unit testing, running all tests in a Rust project is as simple as "cargo test". If you've worked on a moderately large C/C++ codebase you'll know that those two things alone can be a huge source of annoyance. It also makes it really easy to install Rust-based tools like racer/rustfmt/etc with "cargo install <tool>" which pulls the source, builds and puts the executable on your path. In short, all the annoying stuff around project management that in C/C++ is neatly handled into a few short commands. In my mind it's a huge productivity win.

StavrosK 10y ago
Ah, I see. The main difference I can see is that it's opinionated, because everything else can be done by pip too (you can install utilities right in your path with it). I agree that being opinionated is a big help. Everyone in Python-land uses virtualenv and pip, but it would be great if (as is actually happening now), they were bundled with the language and were the One Blessed way of creating a new project: virtualenv myenv source env/bin/activate pip-compile requirements.in pip-sync requirements.txt Rust does get a few benefits from being statically linked, but yes, I see now that people compare cargo to mostly C/C++ tooling, and not to something like Python, thank you.
- dpc_pw 10y ago
  So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install? `pip` and Python are riddled with problems. Native modules fail to compile all the time and since Python is so slow, it requires a lot of native code. python2 vs python3 share `PYTHONPATH` and `virtualenv` is inheriting it: http://stackoverflow.com/questions/24583777/why-does-virtualenv-inherit-pythonpath-from-my-shell http://stackoverflow.com/questions/24583777/why-does-virtual... which leads to many weird problems. Not to mention some python stuff is not available on `pip` (like PyQt, last time I tried). Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D Python software really works only in it's developer sandbox, or when very carefully prepared by Linux-distribution maintainers. Otherwise it's a mess. Part of the reason why Docker got so popular was because it solved an impossible task of running several separate programs written in Python reliably side by side, on many boxes. Since it works reliably only in developer's sandbox, we now ship the whole sandbox and call it "application container". I've gave up on using any software written in Python on my boxes. I just avoid it. Not to mention that Python software rarely works reliably...
  - dom0 10y ago
    I won't bother replying to most of what you said (bit tired), just this one here: > Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D You don't need to activate a virtualenv to run an application from it. Eg. some_virtualenv/bin/some_binary just works, regardless of other active virtualenvs or what Python/Java/C program invokes that. And maybe this bit here: > So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install? The commands he mentioned would be used to create a new project, not to install anything.

pslam 10y ago

* can I get a good job programming in this? Without moving to another country or continent. Yes, there are many large companies which are either actively deploying Rust, or planning to. Easily found if you search. * is my industry showing interest in it? Yes: security, high reliability, availability and safety oriented industries. Any industry looking to get themselves out of the entrenchment of C/C++ but still needs at least one of the major reasons why it persists. * is any industry showing interest? I haven't found any industry, primarily focused on software development, which isn't interested. I've been actively poking around to see which way the wind is blowing. I honestly haven't come across any industry which would actively say "No we're good with C", other than those were software is an annoyance which they grudgingly have to be involved in.

hacker_9 10y ago
Downvoted because no references to back up anything you are saying. I also tried doing a quick search on stackoverflow jobs and only got back 5 results [1]. [1] http://stackoverflow.com/jobs?sort=i&searchTerm=rust http://stackoverflow.com/jobs?sort=i&searchTerm=rust
- kibwen 10y ago
  The "Friends of Rust" page here lists organizations who have voluntarily chosen to advertise their production usage of Rust: https://www.rust-lang.org/en-US/friends.html https://www.rust-lang.org/en-US/friends.html Furthermore, I attend Rust meetups all over the country and invariably meet people using Rust for various tasks at their job, even if their company doesn't choose to deliberately advertise itself as a Rust shop. We also have a large internal list of contacts at companies using Rust (publicly or otherwise) that we use to schedule periodic conference calls to discuss the needs of production users in order to prioritize language development (e.g. Dropbox and Mozilla really, really want faster compile times, which is why that's been a determined focus for this cycle). Overall we're quite encouraged by how many folks are willing to use Rust in a production capacity considering how young and unproven the language still is. :)
  - EpicEng 10y ago
    >Furthermore, I attend Rust meetups all over the country and invariably meet people using Rust for various tasks at their job, even if their company doesn't choose to deliberately advertise itself as a Rust shop. Shocking that you would find people using rust at rust meetups. I'm sure they're a good representation of the programming sector as a whole.
    - kibwen 10y ago
      No need to be so dismissive, my friend. The parent poster asked for references of people using Rust professionally, and I can confirm that I have spoken to many who do.
      - EpicEng 10y ago
        It's a bad reference, so I dismiss it. To be extreme, you may as well say the earth is flat because you met a bunch of people at a local gathering of the flatlander society who believe it to be true. Obviously people are going to be enthusiastic about rust if they're taking time from their weekends to go hang out with others to talk about it. It's just an irrelevant data point.
- pslam 10y ago
  This is not wikipedia, and we don't need [Citation Needed] for everything we say. As you point out yourself, you can easily find at least 5 results. You can also easily find references for everything else I say. The standard here is not to LMGTFY every few words.
jguegant 10y ago
Find me an interesting job in Stockholm requiring Rust and I am your man!
human_error 10y ago
This is rubbish. You make huge claims without providing a single proof.

MichaelMoser123 10y ago

> I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me. May i ask why memory issues are not a pressing issue for you? having to hunt down memory corruptions / access to dangling pointer / memory leaks is a pretty frequent occupation for me (as a C/C++ developer). There are tools like valgrind that help, but well, it is a pain to deal with these issues.

jguegant 10y ago
I don't think that bulb ever dismissed entirely the idea of learning Rust for fun or for acquiring knowledge, did he?
blub 10y ago
I tend to think carefully about lifetimes, resource ownership and writing secure code. I am careful with threading, use language idioms to enforce safety and also use tools (such as valgrind, but also static analysis) to check the code. This is not as reliable as Rust's compile-time safety checks, but in practice it works well enough for me. I don't think this is typical for all C++ projects or programmers e.g. I am not particularly impressed by the (little) Firefox code I've seen. I hope C++ continues to evolve safety features and get closer to Rust's guarantees. I don't think automotive or aviation will switch too soon.
- Yoric 10y ago
  Out of curiosity, do you have (open-source) examples of C++ projects that do it right? In my numerous-though-irregular years as a C++ programmers, I haven't seen any project producing code that's convincingly safe. I won't list all the pitfalls of C++ here, but, well, who doesn't have war stories of bugs-because-of-aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-pointer-is-still-being-used-after-its-mutex-has-been-released, bugs-because-collection-has-somehow-been-mutated-during-traversal, etc? I have reached the point where I feel I can't trust any non-trivial C++ code, so I gladly switched to Rust for all my new non-webdev projects. But back to the question, I would be really happy to see convincingly safe C++ subsets in action. I certainly hope that this would improve my life as a C++ developer, at least for future projects. As a side question, I wonder how many C++ developers actually produce such code.
  - blub 10y ago
    Don't have a link to such a project, I didn't really look. I am seriously considering starting one though, perhaps it's necessary.
    - Yoric 10y ago
      I am genuinely interested. Also, I just realized that doing this right might require dropping lots of legacy C++ code, more or less as would starting in Rust.
- babyrainbow 10y ago
  >I tend to think carefully.. What about a team? If you are leading a team of programmers, would you rather use Rust (where finding if the code is doing anything unsafe using a simple grep) or C++ where finding dangerous code is a lot harder? I think the point of using langauges like Rust and Haskell only comes into play when the development is done by a team. It is one thing to hope that every one in your team is as disciplined as yourself (including yourself on a bad day), and knowing for certain that the language won't allow bad stuff to happen...
  - blub 10y ago
    Depends on the team. If they're not experienced writing safe C++, I'd go with a safer language (e.g. Java) or teach them if that's not possible. But this also depends a lot on the project, usually it's the case that C++ is the only option available. We can't start using any languages we want, we have to consider industry standards, resource availability and other constraints.
EpicEng 10y ago
Probably because people with experience know how to handle these things up front so that they don't occur. I've been writing C and C++ for a decade now and for the last 6 years or so i have had very few issues which stem from any of the things you mention.
- MichaelMoser123 10y ago
  > Probably because people with experience know how to handle these things up front so that they don't occur. bla bla bla. especially if you are dealing with a large code base with shifting requirements, where the code has been written over a long time by a lot of people; in a real world system you just can't make these assumptions regarding 'skill' at all. Even skilled people will have to deal with issues like invalidated iterators / containers that have been modified in non obvious ways / lots of other goodies as well. there are a lot of projects/products like this, my guess is that this is the case with the majority of projects.
  - MichaelMoser123 10y ago
    another example that i had the other day: lets say you have a cache of some sorts, now you keep adding entries to the cache without deleting them, in the end it blows up because it is out of memory. Now technically it is not a leak, but the result is that of a leak. Now good luck solving that with smart pointers and reference counting, etc.
quicknir 10y ago
In legacy codebases, this is common, and I agree this is very painful. But in modern C++, it's pretty easy to write code that doesn't leak or dangle references. Don't use new, don't use delete; no memory leaks (barring cycles w/ shared_ptr). Avoid raw pointers in favor of references, and there are only a couple of rare cases where you can have something dangle. In addition, the new sanitizers (asan, msan), do what valgrind does, but are about 10 times faster, that is they only slow your code down 2-3x. So you should be running it on your unit tests on a nightly basis, further catching any bad memory issues. On a green field project, you can write code like this and have processes like this from day one, and memory safety is not going to be something you spend much time on. I've worked on C++ codebases where I just never spent any time on this stuff, at all.
quicknir 10y ago
In legacy codebases, this is common, and I agree this is very painful. But in modern C++, it's pretty easy to write code that doesn't leak or dangle references. Don't use new, don't use delete; no memory leaks (barring cycles w/ shared_ptr). Avoid raw pointers in favor of references, and there are only a couple of rare cases where you can have something dangle. In addition, the new sanitizers (asan, msan), do what valgrind does, but are about 10 times faster, that is they only slow your code down 2-3x. So you should be running it on your unit tests on a nightly basis, further catching any bad memory issues. On a green field project, you can write code like this and have processes like this from day one, and memory safety is not going to be something you spend much time on. I've worked on C++ codebases where I just never spent any time on this stuff, at all.
sitkack 10y ago
And it sounds like he works in the auto industry. This is pretty depressing that the paycheck weighs more heavily than the safety factor. Toyota killed people with their bad code.
- blub 10y ago
  From the little that I know, safety-relevant code might be modeled in a high-level language that generates C. I don't work directly on safety-relevant features, but I'm sure there are other processes and practices in place. Some bad news for you though: all automotive companies typically use the same tools and processes. Aviation is also like that. And they use a ton of C and C++.
  - sitkack 10y ago
    We had our chance and lost it, the DoD was doing great things with Ada. But 1) the compilers sucked 2) they were hard to get ahold of and 3) there wasn't nearly as much training material on how to use Ada well. Then the DoD acquiesced on Ada and permitted embedded dev in C/C++. I am totally fine with a high level tool emitting C. C is a fine portable target. But the high level system should pass some provable rigor.

the_why_of_y 10y ago
While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.
- Const-me 10y ago
  Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.
  - burntsushi 10y ago
    Rust's regex library uses manually vectorized code to speed up its search algorithms, so it follows that Rust's type system is more than OK with such things.
    - Const-me 10y ago
      They were lucky. Those regexps were OK only using a single register representation, u8x16. That’s not always the case. To write efficient SSE code, you need to understand __m128i is a just a hardware register, and use whatever representation you need for particular instruction. Example: http://stackoverflow.com/a/17355341/126995 http://stackoverflow.com/a/17355341/126995 The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2
      - burntsushi 10y ago
        It's not impossible at all. You can use the raw intrinsics in Rust just like you'd use them in C if you want to. > The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2 That's false. It might be impossible to implement that code safely using the current simd crate as is (which is not in the standard library), but the simd crate is an abstraction over the raw intrinsics and isn't blessed by the language. You can reach in and use the raw intrinsics (or unsafely cast between SIMD types). If you look more closely at the SIMD algorithm in the regex crate I wrote, you can see that I'm already doing this (to convert from an `&[u8]` to an `u8x16` without bounds checks). Popping up a level, I can understand why this is not obvious from an outside observer. The SIMD story on Rust is very much still evolving, and we don't have it all completely worked out yet. When we do, I predict it will be awesome. :-) I have a whole bunch of ideas on how to use it to improve text search even more!
  - steveklabnik 10y ago
    LLVM already auto-vectorizes sometimes, and you can still drop down to `unsafe` to write explicit SIMD (though it's not yet stable).
  - the_why_of_y 10y ago
    So very fast code in C is not actually C code, but written in a non-standard extended C dialect that is also platform specific - thanks for clarifying. I'm curious if there is a way to limit the entries in the Benchmark Game to just those that actually use only the language standards, where those exist...
    - burntsushi 10y ago
      To be clear, using SIMD doesn't require some "non-standard extended C dialect." We very much want a better SIMD story on Rust, and the benchmark game entries should definitely be allowed to use SIMD. SIMD will get you into platform specific woes unfortunately, but that shouldn't stop us. :-)
    - Const-me 10y ago
      What are you talking about? Intrinsics are perfectly valid C99 code. __int64i is a union with 8 different arrays in it, and intrinsics are library functions.
      - the_why_of_y 10y ago
        The words "SIMD", "intrinsic", "__m64", "__m128" do not occur in the C11 draft text; the word "vector" occurs once in example code for an array-with-length struct. http://www.iso-9899.info/n1570.html http://www.iso-9899.info/n1570.html Intrinsics are not library functions - they would hardly provide the desired performance benefit if they were. Intrinsics are "magic" functions that the compiler has built-in support for, and thus I would call them language extensions. For example from GCC header avxintrin.h: extern __inline __m256d __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm256_permute2f128_pd (__m256d __X, __m256d __Y, const int __C) { return (__m256d) __builtin_ia32_vperm2f128_pd256 ((__v4df)__X, (__v4df)__Y, __C); } Over here the word "__builtin_ia32_vperm2f128_pd256" occurs in the "cc1" and "cc1plus" binaries and "avxintrin.h", but nowhere else. Notably there is no externally visible definition.
        Const-me 10y ago
steveklabnik 10y ago
There's been a lot of variance on the benchmark game lately since things are so close; a couple of months ago, Rust was #2 overall, beating out C++ and just a tad slower than C. The areas where Rust lost the most were because explicit SIMD isn't stable yet. We also upgrade LLVM regularly, and that can cause some fluctuations from time to time. (Rust is currently beating C on one benchmark, within a few tenths of a second on a few more, and then way slower on the SIMD-reliant ones)
- burntsushi 10y ago
  Enabling SIMD on regex-dna is going to help a lot there too. :-) (I hope.)
- bjourne 10y ago
  But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is still significantly faster than Rust which follows that C++ is too" That is still true because we are discussing the current state of the languages and what you wrote does not affect that. Btw, the last time this topic was discussed we measured the performance using a microbenchmark. Here is the C version: https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9e5b7 https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9... None of the Rust aficionados were able to produce a Rust program (using the nightly build of Rust even) that came close.
  - steveklabnik 10y ago
    Yes, but you then also went on to say that no language will ever do it. Rust _has_ consistently beaten C on many of these benchmarks in the past, and continues to remain very close in the ones that it's not. I actually don't think microbenchmarks are a good way to think about performance anyway. There's two reasons: First, Rust's safety guarantees let you get away with more dangerous things. Consider scoped threads, or non-atomic reference counting.[1] You _could_ write this in C, and you'd do so for a microbenchmark, but not for a real codebase, as it's far too dangerous. Or, you might do it, but end up with bugs that you don't detect, that aren't there in the Rust version. 1: http://blog.faraday.io/saved-by-the-compiler-parallelizing-a-loop-with-rust-and-rayon/ http://blog.faraday.io/saved-by-the-compiler-parallelizing-a... Secondly, microbenchmarks are often "can the best person at language X write something faster than the best person at language Y"? I don't think that's nearly as interesting as "When an average programmer of languages X and Y write a program, which is faster?" Rust's default patterns and style is already extremely fast. It's not a guarantee, mind you, but for real-world usage, it's the average case that matters more.