Live data from Hacker News

Rust Language, and Why C/C++ Will Never Die (2015)

viva64.com

21–30 of 66 posts

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#21
post #13

The question about C++ vs Rust boils down, to me, when the game developers finally decide to switch. Game developers are not wedded to languages, if something is 25% more productive they WILL use it. If game developers flip, Rust is going to displace C++. Embedded, unfortunately, is not a good canary. I still program all of my devices with C and not C++. C++ simply brings nothing to the table for the end user of an e…

Embedded. That’s when I’ll beleive Rust has made it as Rust is a direct competitor to ubiquitous C in this area.

When Rust approaches and gets an IDE like Segger/Rowley, KEIL, IAR, etc then I’ll beleive it’s happening. But currently supporting a few old chips and the cargo package system having some ambiguous entries for other chips tells me it’s not close yet.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#22
post #17

I'm reluctant to comment because the first iteration of this 'series' was fraught with blatant errors, from what I recall. > Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans. I've met hundreds of rust developers at this point and at no point in conversation has anyone ever expressed that we should be working to rewrite every C++…

> There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily. So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.

Not really, no.

His point was that fundamentally Rust will have overhead by being safe, and that it's necessary to drop into unsafe to match the performance of C++.

He takes this further, stating that if you're going to drop into unsafe for hot code, why not just use Java/Go and FFI into C++.

This is misleading or incorrect for a few reasons.

* Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date)

* The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD.

* His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code"

As an aside, Rust now has explicit SIMD, and there's progress being made on `const fn` (the contexpr equivalent) and int generics.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#23
post #17

I'm reluctant to comment because the first iteration of this 'series' was fraught with blatant errors, from what I recall. > Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans. I've met hundreds of rust developers at this point and at no point in conversation has anyone ever expressed that we should be working to rewrite every C++…

> There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily. So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.

Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#24
post #13

The question about C++ vs Rust boils down, to me, when the game developers finally decide to switch. Game developers are not wedded to languages, if something is 25% more productive they WILL use it. If game developers flip, Rust is going to displace C++. Embedded, unfortunately, is not a good canary. I still program all of my devices with C and not C++. C++ simply brings nothing to the table for the end user of an e…

Game development isn't what it was ten years ago; better tools have basically reshaped how games are made. C# is a serious contender for most-used language in game development, because the gains in productivity thanks to related tools easily make the performance impact worthwhile. Besides, hot points can always be rewritten in something faster.

Or rather, many game developers already switched to C#. Most every major engine has C# bindings to some degree.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#26
post #13

The question about C++ vs Rust boils down, to me, when the game developers finally decide to switch. Game developers are not wedded to languages, if something is 25% more productive they WILL use it. If game developers flip, Rust is going to displace C++. Embedded, unfortunately, is not a good canary. I still program all of my devices with C and not C++. C++ simply brings nothing to the table for the end user of an e…

We have some small amount of this happening:

Chucklefish’s new game is in rust.

EA: SEED has been using it.

Some people left SEED and started a new AAA studio (Embark) that’s all Rust.

Ready At Dawn has moved all development over and has even been releasing some open source. Their CTO has said some really nice stuff on Twitter, repeatedly.

Other rumblings and rumors.

We’ll see! Exciting times.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#27
Since 2015 Rust has grown and matured:

The article questioned whether Rust's design made sense. It looks like it's holding up. Major pieces of software have shipped. Projects analyzing language's soundness have found some bugs in libstd, but not any fatal flaws yet.

The article complained about Rust's speed. In the benchmarks game it used to be on par with Go, now (as far as the game goes) it's clearly faster than Go, Java, Fortran, Ada and Swift.

The article questioned whether anyone sane would write web servers in Rust. There are some nice web frameworks now. AWS officially supports Rust in Lambda. Futures-based ecosystem for async programming is growing. It's getting there.

The predicted huge mess of crates.io hasn't happened yet. crates.io is lucky to have npm a few steps ahead of it, so it can proactively prepare for growing pains that are coming.

The 2018 edition has shipped a new borrow checker that's easier to work with, more powerful and properly namespaced macros.

Of course C/C++ isn't going anywhere, but it looks like Rust is here to stay, too.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#28

Earlier quoted context omitted.

Not disagreeing, more curious, but isn't Fortran still in relatively common use in Scientific computing? I haven't gotten into that domain, but I guess it is probably far below where it was at it's peak. Maybe it is just that we are getting lots of languages good for certain niches, instead of one general purpose language dominating multiple niches.

Yeah, I'm not expert on Fortran use back in those time, it's just more used as an example of a language that at one point in time was much more popular than another. For instance the amount of Fortran code and libraries in 1979 was probably order of magnitude bigger than the amount of C code. Was there more general purpose language that C was competing with back in the time? I guess picking C as the old language and…

> Was there more general purpose language that C was competing with back in the time?

Plenty of Algol and PL/I variants.

C had an almost free OS with source code going for it, had UNIX been a commercial offering right from the start with a price tag similar to systems like OS/360 or VMS, and the outcome would have been completely different.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#29
post #24
post #13

The question about C++ vs Rust boils down, to me, when the game developers finally decide to switch. Game developers are not wedded to languages, if something is 25% more productive they WILL use it. If game developers flip, Rust is going to displace C++. Embedded, unfortunately, is not a good canary. I still program all of my devices with C and not C++. C++ simply brings nothing to the table for the end user of an e…

Game development isn't what it was ten years ago; better tools have basically reshaped how games are made. C# is a serious contender for most-used language in game development, because the gains in productivity thanks to related tools easily make the performance impact worthwhile. Besides, hot points can always be rewritten in something faster. Or rather, many game developers already switched to C#. Most every major…

The latest news out of Unity is really interesting in this regard; they switched from C++ to a restricted subset of C# for their hot loops, in my understanding.

Re: Rust Language, and Why C/C++ Will Never Die (2015)

#30

Wow that's a long article, I tried summarizing the main points. I think some of them have merit, but for the "technical reasons", I don't think I agree on most. Here are the points: 1 - there's a ton of existing c++ programs 2 - other have tried replacing c++ and failed (D for instance) 3 - no one will use Rust until it has cool IDE stuff and production ready libraries: a chicken and egg problem that Go was able to s…

D hasn't failed. Although personally I don't think being a better C++ is the direction D should be going for (I'd rather see it going in the direction of lower level Java/C#).

However due to market pressure from very important customers, Java and C# are getting better at low level programming, while enjoying the tooling and libraries.

While being merged into GCC mainline is an huge success for any programming language, D is still kind of looking for its space and competition is getting stiffer.

Post reply on HN