Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

viva64.com

Post reply on HN
Print view View original

31–40 of 66 posts

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

#31

Post by pjmlp »

steveklabnik wrote: post #29
dleslie wrote: post #24

Earlier quoted context omitted.

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.

Indeed, it is called HPC# and from what I understood during the interview with Miguel at Unite, Unity developers also contributed to the design of low level programming features from C# 7.x, and the ongoing ones for C# 8.0.

There are a few well known former developers from Insomniac Games working on the project.

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

#32

Post by mwkaufma »

steveklabnik wrote: post #29
dleslie wrote: post #24

Earlier quoted context omitted.

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.

Yes, it's much like asm.js -- the code works as plain C# but can also be fed through their "burst compiler" to produce optimized native binaries: https://unity3d.com/learn/tutorials/topics/scripting/using-b...

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

#33

Post by bjourne »

I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.

I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. They are however not as fast as those using unsafe parts of the language. You will never get the same kind of total safety as you get in, say, Python because Rust doesn't do overflow checking. It does in debug mode, but you are strongly encouraged to distribute binaries in release mode since the speedup is substantial.

Offering safety and programming ergonomics for performance is a crappy trade.

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

#34

Post by maxxxxx »

crimsonalucard wrote: post #11

So basically C/C++ will never die because of ubiquity. It's like gasoline and oil. Both will always be the dominant energy paradigm because of ubiquity and because of habit.

"Never" and "always" are dangerous words. Things sometimes change very quickly.

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

#35

Post by staticassertion »

bjourne wrote: post #33

I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc. I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. Th…

Alternatively, Python could easily be argued as being radically unsafe compared to Rust, given the many, many libraries that call out to C and the ease of exploiting C libraries loaded by CPython.

https://hackernoon.com/python-sandbox-escape-via-a-memory-co...

I'd say more people have had to jump into "unsafe" Python than have had to jump into "unsafe" Rust.

As for overflow checking, that won't lead to unsafety on its own, just panics (it's defined to wrap in release).

Your post conflates all sorts of issues and lacks nuance.

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

#36

Post by saagarjha »

fhrow4484 wrote: post #5

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…

> rust is not that fast

I thought Rust was pretty competitive with C++ in this respect?

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

#37

Post by saagarjha »

bjourne wrote: post #33

I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc. I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. Th…

> I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.

Someone needs to write the unsafe code so that the safe code can execute on top of it.

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

#38

Post by Thorrez »

bjourne wrote: post #33

I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc. I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. Th…

Is it possible to write an operating system or a browser if we forget about the languages you want us to forget about?

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

#39

Post by gameswithgo »

fhrow4484 wrote: post #5

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…

3 is better now with RLS 4 isn't true anymore

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

#40

Post by fhrow4484 »

saagarjha wrote: post #36
fhrow4484 wrote: post #5

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…

> rust is not that fast I thought Rust was pretty competitive with C++ in this respect?

Yeah, that's one of my biggest disagreement with the author, there's more discussion about it in this comment thread from staticassertion: https://news.ycombinator.com/item?id=18949036
Post reply on HN