Ask HN: What is the state of C++ vs. Rust? | Hacker News Reader

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

154 pointsmanaskarekar154 comments

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.

View on HN

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.

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?

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

First of all, I agree that cargo blows the C/C++ tools out of the water in terms of ease of use. But I think it's even easier than newer stuff too. It's by far the best dependency manager I've used.

I haven't used pip-tools, but I have used pip, npm, bower, and other more modern dependency mangers that work for non-systems programming languages. Cargo has never given me any trouble. Pip has occasionally given me weird issues about things not being installed in the right places or on my path. NPM regularly required `rm -r node_modules` and starting from scratch. Bower has had the same trouble as npm. It's not that these tools don't work for me, I've always been able to google the error message and find someone with the same problem. It's that Cargo has never given me an error message that wasn't my fault like "This package doesn't exist" when it's a typo. It just works.

Hmm, I've had problems with npm too, but none with pip. The trick there is to make sure you're working in the virtualenv of your project, by activating it or using something like virtualfish or the bash equivalent (virtualenv-wrapper, I think).

One problem with pip is that it requires tricks. But seriously, I avoid using python mostly due the headache when trying to use pip. But I'm sure without pip python would be a real hell.

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.

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.

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

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.

One thing that's nicer is that because Rust is a compiled language, Cargo produces a (statically-linked) binary. Python and your Python environment always needs to be set up on the machine that you're going to run it on.

statically-linked by default except for on Linux where it links to glibc dynamically by default IIRC, but going fully static there is easy, and going fully dynamic is easy too.

fully static (including libc) can cause a lot of trouble on Linux.

Static binaries (with system libc) on Linux are okayish, if all the systems are the same distro, or at least have a libc of the same vintage, but breaks frequently if you try to go further (eg. deploying to LTS distros like deb oldstable, centos, ...).

Doesn't really compare to eg. Windows, where you just bundle the MSVCRT with the installer and unless you're API incompatible the application will just work everywhere.

That's why on Linux, by default, Rust link everything statically except the libc. But you sill can make a fully static executable by using the "musl" target.

>I still work regularly on C++0x11

... but that's not due for another year!

The C++ compiler teams have done heroic work to get their implementations on-track and have been ahead of the spec for several years now.

Many compilers are already supporting a number of C++17 features, and by the time the spec is out it might be almost complete for most major vendors.

http://en.cppreference.com/w/cpp/compiler_support

0x11 == 17

That's not a code name I've ever heard of: https://en.wikipedia.org/wiki/C%2B%2B17

C+0x was what turned into C++11. The 0x part was just a placeholder for 08 or 09, but it actually ended up taking a few years longer to ratify.

Maybe people confuse C++11 with C++0x to get C++0x11.

Yes, the OP used C++0x11 when he probably meant either C++11 or C++0x. By chance, C++0x11 happens to be the hex encoding of the next expected C++ revision. My admittedly content free joke was an attempt at pointing out the error.

Yeah, never can tell how literal people are being around here.

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

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.

To be more accurate, they didn't announce an alternative to Mercurial, but rather new Mercurial server software.

Yup you're right, I should have been a bit more explicit there, meant to say backend replacement.

I specifically said industry because projects come and go.

Yes, there are dozens of companies doing some project in Rust. That's true for almost any programming language.

I am guessing that it's going to be another 5-10 years until I would need to seriously consider learning Rust, assuming it will be able to break into the mainstream.

Safety-wise it could make sense for my industry, which seems to be overwhelmed by C and C++ (see Toyota).

Industry is great if you want to make safe, slow bets. PG's essay on lisp is a great example of why you may not want to follow industry.

However, the point I was making is there's not a binary switch between C/C++/Rust. There's a great interop/FFI story that allows a targeted/gradual adoption.

I know it's kind of hallowed ground around here, but IMO that essay has one of the highest ratios of survivor bias to good advice that I've ever seen.

To sit on the sidelines and wait till the technology and market matures is a smart decision. There's a lot of new things popping up, and not everything sticks. This is particularly true if you're running a business and you need to pick the right tech.

Learning a new language though is not a wasted effort, even if eventually the language becomes obsolete. It only takes a few days to get going with something new, and the lessons learned are useful regardless of if you use the language in the future or not.

But to say that there's no interest at all is pretty ridiculous, and there's plenty of people looking at rust and deploying it. That last statement made me feel you might just be a bit burnt out by change in general. Don't lose perspective. Going out of your comfort zone might be exactly what you need.

But one doesn't pick what to learn just between several languages, in fact I think they're a pretty poor investment after a certain count. When learning Obj-C I didn't get much out of it. I like several Swift idioms, but it was hardly worth it to learn a language for that.

In contrast I finished an architecture course recently that I expect will bring me 10x value of knowing both of the above languages.

Please see my answer to vvanders regarding interest vs industry interest.

What's the architecture course? I've been meaning to move from learning languages and APIs to learning more "lasting" things.

It was a course based on the book Software Systems Architecture by Rozanski & Woods. The trainer was Rebecca Wirfs-Brock.

Reading the book should be a very useful first step when learning about architecture.

If one decides to go to the course it's essential that there are also experienced architects participating and that one has an architectural case study that can be discussed.

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

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

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

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

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

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.

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.

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.

Find me an interesting job in Stockholm requiring Rust and I am your man!

This is rubbish. You make huge claims without providing a single proof.

Sorry but that's bullshit. C++ is just a dinosaur plagued with issues inherited by design decisions made before most of people here were born. Trying to replace it has nothing to do with looking for a perfect language.

Rust could have absolutely 0 memory safety features over C++ and it would still be a massive improvement over the mess that is C++ package management and build systems with Cargo. Same is true for many other features. It's not quite there yet in terms of maturity and adoption but there's significant momentum and interest from big players that learning it now will likely put you in demand in a few years.

That would be true if changing programming languages or adding new languages would be zero-cost. Then we could iterate fast to some close-to-ideal language.

This black and white thinking is just a sign of immaturity, not of knowledge of a deeper truth.

All mainstream languages are capable of delivering business value. I happen to prefer certain characteristics that led me to C++, but I also found Java to be quite fine. I don't think I'd mind doing PHP or even JS for an interesting project. I've done both in the past.

I'm not saying we should be completely dispassionate about our tools, it's normal to have likes (I do like C++). But hating languages is rather pathetic and unhealthy.

I don't hate C++, saying rust offers nothing other than memory safety is just wrong, just by being a modern language with zero cost abstractions with stuff expected of modern languages such as modules, package management, sane build system, potential for lower compile times, etc. It's not hard justifying costs of migration when considering C++ problems if something replaces it adequately. Rust has the potential to do that.

Whatever happened to learning something to broaden your view? I doubt I'll get a job in Clojure anytime soon - but learning it has been the biggest eye opener to me as a programmer in the last 5 years.

> The answer to all these questions seems to be "no".

In conclusion you shouldn't be learning it and good luck to the company trying to hire people for Rust positions?

You're saying you should only learn what the industry is pushing towards. The thing is that the industry is pushing towards what sort of talent they can acquire - this is a vicious cycle.

Learning something to broaden my view is one of my favourite things to do. Except "something" is not a programming language.

If there's a worthwhile project that I want to contribute to, I will learn Rust. At least in automotive the industry is not necessarily pushing towards specific tools, they have constraints that limit choices to particular languages.

Not that long ago, the idea of trying to get into the automotive industry with a web background would have been laughable. Now, I frequently get inquiries from auto companies interested in my JavaScript experience, despite the fact that I left the Detroit area a few years ago. Even the auto industry changes when faced with a better way to do things, and its constraints actually seem to align well with Rust's core design principles. All it takes is a first mover.

They will use JS where it makes sense, e.g: web UIs to drive some background components. These are new projects.

Let's see if that first mover decides to show up.

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

I don't think that bulb ever dismissed entirely the idea of learning Rust for fun or for acquiring knowledge, did he?

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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.

  > HN has a high proportion of people with an unusual 
  > interest in trying out programming languages

Which is precisely why it makes sense to ask this question here. :P

In that case one could save some time posting the question about non-mainstream language X and just learn X. End result would be the same. :)

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.

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

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

For those not aware of it, 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.

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.

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

There are libraries (I didn't downvote you but I suppose that is why as simple googling shows that) [1].

That being said one would argue if you are going the microservices route you shouldn't need an exceptional amount of routing anyway. You only need to really handle raw HTTP for the most part (also I would not say HTTP is the end all for microservices... I have been using a Rust AMQP library with some success [2]).

Also although Go has green threads it is still debatable if that is the right way or golden way particularly when so many backends like databases (e.g. postgres) can't handle async (tons of connections) anyway. Old school one thread per request libraries in Java like dropwizard can still do fairly well. I think Rust made the right choice with native threads and hopefully some interesting green thread or reactive libraries will come forth soon (or already here ... haven't googled it).

Also I'm just not sure I really buy into Go's channels but that is just a personal opinion at the moment.

[1]: https://youtu.be/pTQxHIzGqFI?t=964A

[2]: https://github.com/Antti/rust-amqp

When you need to handle a lot of concurrent connections (from your clients, not to your database), Go green threads are invaluable (better than OS threads because a goroutine requires only 2 KB; and better than callbacks). They are also very useful to express concurrent algorithms.

Surprisingly, it's already not that painful. I recently wrote a tiny JSON service with Iron and Diesel and it wasn't that much longer or complex compared to Go. The biggest headache was figuring out how Diesel works, and it would have been a lot easier using raw queries with something like rust-postgres (which would be the way to go in Go or Node). Once the ecosystem matures a little bit more I don't see why Rust would be a bad choice.

Macros 1.1 should make working with Diesel easier for the programmer, compared to the incompatible compiler plugin APIs.

I think the sweet spot with rust might leveraging metaprogramming, for instance, generating a REST database API from a schema and having the resulting code compile to something faster the most languages like python or ruby, and at least on par with Go, Java, or swift.

> Building something in Rust would be much more painful.

Go may have more of those things and it may be easier to find copy-pastable examples for them, but rust has them too, and its not painfull. The things you mentioned are there and are working fine.

I assumed that agentgt meant "up for grabs" in the sense of "not yet dominated by any one language", which is true. Go and Java are both big presences in that space, but neither is dominant. A language with the expressiveness of Java and the memory use of Go could be a strong challenger, and Rust is already better than that.

I'm not a RUST chap, but came across this the other day:

http://www.arewewebyet.org/

I've done most of my web service work in either Java or Go, but I'd like to give Rust a try for comparison at some point.

Rust people may have better insight into this, but it seems like that site is outdated and in need of an update.

Edit: I meant to say that I have heard from many of them that the content of that is outdated and in need of an update. There was talk of the community taking it over but I don't have the latest on that.

Dot org is the takeover of the old dot com, which is what you were thinking of.

Okay, there was an attempt made to get the .com redirected?

It currently does.

Okay, sorry for the confusion.

It's all good! It was wrong for a very long time. This is a recent development.

Regarding microservices; it's my hopes https://github.com/fractalide/fractalide moves into this space.

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

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.

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), and what's left is the important last mile of bringing these things together in ergonomic libraries or frameworks.

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

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.

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.

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

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

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.

How does it happen? Non-const unique_ptr& used as a function parameter?

http://www.steveklabnik.com/uniq_ptr_problem/

I can simplify your example:

  unique_ptr<int> p;
  auto n = *p; // C++ kills!

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

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?

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/

More information about platform support can be found here: https://doc.rust-lang.org/book/getting-started.html

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

[2] - http://jakegoulding.com/rust-ffi-omnibus/

linking a static lib with rust and linking with the final executable. other users posted the links I used :)

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.

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.

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.

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.

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

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.

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

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.

I think culture will do its thing here.

Getting into C++ now is harder then getting into Rust.

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.

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.

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.

but the companies that they want to work for have codebases in C++

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.

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

There was just a huge announcement yesterday: https://news.ycombinator.com/item?id=12739015

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.

Rust has 0.1 decades of backward compatibility to satisfy.

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.

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.

Rust will be if is not already faster than C. Especially in real-life projects. One example would be 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.

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.

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.

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.

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.

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

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!

LLVM already auto-vectorizes sometimes, and you can still drop down to `unsafe` to write explicit SIMD (though it's not yet stable).

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

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

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

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.

I don’t know why authors of GCC invented that non-standard extended C dialect, you better ask them.

In Visual C++, the prototype of that intrinsic is valid C99 code:

    extern __m256d __cdecl _mm256_permute2f128_pd(__m256d, __m256d, int);

Which library contains the definition of "_mm256_permute2f128_pd"?

The likely answer is "none", as these are built-in to Visual C++ in a similar way to GCC, with only superficial differences such as an apparent lack of indirection to some __builtin_foo.

https://msdn.microsoft.com/en-us/library/26td21ds(v=vs.100)....

"An intrinsic is a function known by the compiler that directly maps to a sequence of one or more assembly language instructions. Intrinsic functions are inherently more efficient than called functions because no calling linkage is required."

https://msdn.microsoft.com/en-us/library/y0dh78ez(v=vs.100)....

"The use of intrinsics affects the portability of code, because intrinsics that are available in Visual C++ might not be available if the code is compiled with other compilers and some intrinsics that might be available for some target architectures are not available for all architectures."

I know how intrinsic work, thanks. Use them a lot in C++.

C99 language spec says nothing about the things you’re talking about. It only specifies the language, not how C compilers implement various features.

From the programmer’s point of view (except when the programmer works on the compiler itself), intrinsics are just C library functions, only inline, and very performant if done right. Fully compliant with C99 and C++ language specs.

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)

Enabling SIMD on regex-dna is going to help a lot there too. :-) (I hope.)

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/4599a387d24c80906475b26b8ac9... None of the Rust aficionados were able to produce a Rust program (using the nightly build of Rust even) that came close.

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

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.

No, I didn't say that no language will ever beat C. I can't predict the future. Rust has not beaten any highly optimized microbenchmarks that I know of. Like it beats C on the mandelbrot benchmark, but is then beaten by Swift, suggesting that the C implementation isn't very good (http://benchmarksgame.alioth.debian.org/u64q/performance.php...).

The reason we have micro benchmarks is because it is so hard to reason about the average case. Yes, code written in Rust could on average be faster than C due to its safety features. But so could Python, Java or Haskell so we're back were we started and can't say anything about relative language performance.

It's a small niche, yes, but some people absolutely need to squeeze out every gram of performance, and they should continue to prefer C over Rust.

(The C Mandelbrot program is considerably less extreme.)

> The areas where Rust lost the most were because explicit SIMD isn't stable yet

That was last year, before rustc 1.0.0-alpha

> There's been a lot of variance on the benchmark game lately

With Swift, because programs written for Swift 2.0 failed with Swift 3.0

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

I guess you missed this in the sibling, but ripgrep does this today, and it works on Windows, Mac and Linux, and should be as fast or faster than GNU grep. See benchmarks: http://blog.burntsushi.net/ripgrep/#single-file-benchmarks See binaries: https://github.com/BurntSushi/ripgrep/releases

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

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

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

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.

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.

Most of Rust's guarantees are provided at compile time and have no overhead, just to be clear.

Yes most, but not all.

Out of curiosity, have you hit examples in which the runtime cost of Rust's safety was problematic – and couldn't be worked around without losing either safety or clarity?

The most obvious case is bound checking. If you have a code with direct array indexing you have to use unsafe code or loose a little bit of performance.

The Rust team puts a lot of effort into not gratuitously maligning anything, including a "competitor" language like C++: discussions of other languages try to be as factual as possible, and, Rust is very happy to adopt the good ideas of them (and of course acknowledge this), e.g. Rust's closures are modeled after C++11's lambdas.

As with anything, some people who like Rust might get a bit enthusiastic about discussing its benefits compared to other languages, but this is frowned upon and IME usually called out, especially in spaces with some sort of "official" Rust moderation presence.

> The Rust team puts a lot of effort into not gratuitously maligning anything

Anecdotally, Rust developers are the only group I've interacted with that consistently focus on the positives of other languages when discussing different features or concepts, while acknowledging the tradeoffs and clearly outlining the reasoning behind Rust's choice.

Reply on news.ycombinator.com