Live data from Hacker News

Rust is Software's Salvation

redox-os.org

51–60 of 182 posts

Re: Rust is Software's Salvation

#51
post #45

Rust is an overly complicated language that made the exact same deadly mistakes that c++ made: takes too long to compile and is too complex. Yes I get it, you're working on the compile times. You will never bring them down to under 1 second regardless of amount of libraries used, let's just say this once and for all. I add two crates 'hyper' and 'postgres-rs' in a 500 line(!!!) program and it's STILL a 2.8 second com…

I don't know why you are down voted. Compile time is a Rust issue for me. I'm spoiled by D. However I'm not sure if borrow checking is inherently slow. The release notes are discouraging. 30% faster? Aim for 10 times faster. Maybe it is just the LLVM backend. It still is slow.

> Aim for 10 times faster.

What you aim for and what you achieve are different things. These things take time. We've been getting faster every release. 10x faster within a single six-week period is not realistic.

(Borrow checking is not generally the slowest part; it's the codegen. Which is LLVM. But also is the IR we feed to LLVM.)

Re: Rust is Software's Salvation

#52
post #16

The amount of hype Rust is getting is not going to end well for Rust. This reminds me of Ruby during 2007-2010 where it went from Patron Saint to Scapegoat for every startup that failed using it. Ruby survived it, and I'm sure Rust will too, but that doesn't make it obnoxious for everyone else who inevitably gets swept up in the craze and crash. Programming is hard. Programming will always be hard. Better/newer tools…

I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.

That's just not true. C (in the hands of average programmers) is limited because it's not very expressive. There's no way to say "these 40 things can be run in parallel" or "run these 200 things asynchronously" in a standardized way. Very clever compilers can infer some autoparallelization situations, but I'm not away of anything that can auto-async a project that's not explicitly written that way.

That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do.

Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.

Re: Rust is Software's Salvation

#53
post #45

Rust is an overly complicated language that made the exact same deadly mistakes that c++ made: takes too long to compile and is too complex. Yes I get it, you're working on the compile times. You will never bring them down to under 1 second regardless of amount of libraries used, let's just say this once and for all. I add two crates 'hyper' and 'postgres-rs' in a 500 line(!!!) program and it's STILL a 2.8 second com…

I don't know why you are down voted. Compile time is a Rust issue for me. I'm spoiled by D. However I'm not sure if borrow checking is inherently slow. The release notes are discouraging. 30% faster? Aim for 10 times faster. Maybe it is just the LLVM backend. It still is slow.

D is not fast enough either, I only like Java (with the eclipse compiler), Golang and obviously the dynamic languages

Re: Rust is Software's Salvation

#54

The amount of hype Rust is getting is not going to end well for Rust. This reminds me of Ruby during 2007-2010 where it went from Patron Saint to Scapegoat for every startup that failed using it. Ruby survived it, and I'm sure Rust will too, but that doesn't make it obnoxious for everyone else who inevitably gets swept up in the craze and crash. Programming is hard. Programming will always be hard. Better/newer tools…

The echoes of Golang hype right now are somewhat ominous. A few years ago it was "concurrency primitives are going to change your life" and now it's "lifetime/ownership primitives are going to change your life." I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the…

A few years ago it was "concurrency primitives are going to change your life

Those, plus the total package of tradeoffs in Golang did for me, in terms of implementing a game server. The whole package really is game changing for what I'm doing.

I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement.

There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel?

But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before.

Luminaries of our field have been lamenting for decades that programming forgets its own history and discoveries. Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study?

If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.

Re: Rust is Software's Salvation

#55
post #29
post #16

Earlier quoted context omitted.

I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.

It is, especially if these checks are done at compile time, not at runtime.

Expect a blog post within four hours "Rust has solved the halting problem!"...

Re: Rust is Software's Salvation

#56
The reality is Rust will never be mainstream because 95% of the dev use php / ruby / python / java / c# and Rust is far too complicated to switch from those. That's where imo Go will prevail, it's a simpler language that is easy to use / learn.

Re: Rust is Software's Salvation

#57

The amount of hype Rust is getting is not going to end well for Rust. This reminds me of Ruby during 2007-2010 where it went from Patron Saint to Scapegoat for every startup that failed using it. Ruby survived it, and I'm sure Rust will too, but that doesn't make it obnoxious for everyone else who inevitably gets swept up in the craze and crash. Programming is hard. Programming will always be hard. Better/newer tools…

> Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well.

I don't think that the language creators are behind this in this instance, more over-excited users continuing the hype cycle. I definitely agree that it does a disservice to the language. I posted this on /r/rust[0]:

> Please don't push the hype train to far - our language, tooling and strong community does a lot of work to sell itself, and we will get a backlash if we are not up-front honest about Rust's problems. Ruby and Go are experiencing that now. Some languages are better than others especially in specific domains, but even the better ones are not silver bullets, and Rust is no different. I use Rust for some things because I feel the trade-offs are worth it.

Not all of us feel the need to sugar coat Rust.

[0]: https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwa...

Re: Rust is Software's Salvation

#58
post #3

How fast we forget Brooks. There is no silver bullet.

>There is no silver bullet.

There could be though. Maybe the successor language to both Rust v4.4 and C++26 will be named Silver Bullet. You never know.

Re: Rust is Software's Salvation

#59
post #9

I expect the rebuttal "Rust is Software's Doom" soon.

or "10 Reasons Why Everything You Know About Rust Is Wrong"... ;)

I'm waiting for when an earnest "Rust Considered Harmful", or perhaps a "Falsehoods Programmers Believe about Rust" shows up.

Re: Rust is Software's Salvation

#60
post #29
post #16

Earlier quoted context omitted.

I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.

It is, especially if these checks are done at compile time, not at runtime.

How can checks be done if the size is dynamic based on run-time data?
Post reply on HN