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

Rust is Software's Salvation

redox-os.org

Post reply on HN
Print view View original

71–80 of 182 posts

Re: Rust is Software's Salvation

#71

Post by joshmarlow »

rubiquity wrote: post #6

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…

Why dear Sir, it almost sounds like you are suggesting that there is no silver bullet!

Re: Rust is Software's Salvation

#72

Post by kmicklas »

jstewartmobile wrote: post #69
kmicklas wrote: post #65

Earlier quoted context omitted.

These piles of money don't seem to be amounting to much because rust is still an objectively far superior language. Google is not a language company and doesn't hire good language people so I don't see this changing. Disclaimer: I work for Google

No argument on superior, it's just that superior doesn't win the day. Look at C++. Look at JavaScript. It would be surprising if the industry made the better choice for a change.

Yeah but unlike, say, Haskell, Rust seems to have good enough momentum from the right crowds.

Re: Rust is Software's Salvation

#73

Post by comex »

kstrauser wrote: post #52
w8rbt wrote: 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.

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

Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but they're hardly unique in that respect.) Go has a runtime that makes it cheap to spawn lots of threads, but it's not doing any super high level optimization or abstraction either (quite the opposite). I don't know about Erlang.

Re: Rust is Software's Salvation

#74

Post by youdontknowtho »

Ar-Curunir wrote: post #61
youdontknowtho wrote: post #31

Captain Obvious here with a public service announcement: Rust's safety guarantees dont extend to logic or protocol implementation problems or misconfigured security settings.the part of the article about service providers leaking creds or other info...Rust all the things and that will still happen. Some of this stuff is just too much. Also, why not work on lifetime and memory safety in a c based language? Rust looks…

There are ways to prevent some logic/protocol problems at the type level using rust: https://hoverbear.org/2016/10/12/rust-state-machine-pattern/ https://blog.tarn-vedra.de/posts/phantom-types-for-safe-apis... https://insanitybit.github.io/2016/05/30/beyond-memory-safet... https://scribbles.pascalhertleif.de/elegant-apis-in-rust.htm... Some libraries use such features to prevent certain kinds of nonce-reuse during en…

I get what you are saying. "Software's Salvation" might require more than compile time type checking.

I'm a huge strong typing fan! I'm just saying, type systems can get you a long way toward correct construction. (Or correctness by construction...) The issues with the software/computing world are bigger than array bounds checking and type correctness.

Re: Rust is Software's Salvation

#75

Post by Taniwha »

All of us who get the compiler writing bug make a toy language or two, I know I did, way more than two, usually it was taking some great idea and running with it .... there is a basic problem that there's a lot more aspiring compiler writers than there is public mindshare for learning new languages .... for every new language you see blooming there's 20 that didn't get the attention to get more than 2 adherents, and for every adopted language being commonly used there's another 10 of those new blooming languages that will blaze and die .... only to have its one great idea find its way into C++ 5 years from now.

I don't write new languages any more, I figured this out 20 years ago, it's something that is very very hard to suceed at, and rather a crap shoot.

The same goes for OSs.

Oh, and BTW, functional languages, the very best thing since sliced bread, for, what? the third time around now?

Re: Rust is Software's Salvation

#76

Post by burntsushi »

comex wrote: post #73
kstrauser wrote: post #52

Earlier quoted context omitted.

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

Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but t…

rayon probably deserves a mention here: http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo...

(It's not built in, but that's a good thing IMO. :-))

Re: Rust is Software's Salvation

#77

Post by eropple »

jstewartmobile wrote: post #69
kmicklas wrote: post #65

Earlier quoted context omitted.

These piles of money don't seem to be amounting to much because rust is still an objectively far superior language. Google is not a language company and doesn't hire good language people so I don't see this changing. Disclaimer: I work for Google

No argument on superior, it's just that superior doesn't win the day. Look at C++. Look at JavaScript. It would be surprising if the industry made the better choice for a change.

Hmm--with some edge-case exceptions that never got a strong push outside of some niches (Ada comes to mind, where it achieved some traction in DoD circles), I wonder if C++ wasn't the superior choice given its time and place. By no means is it perfect, but in the early to mid 90's there weren't many competitors with a similar feature set that had anybody pushing hard behind it. To my mind it seems not dissimilar.

If I have to write native code, right now it'll be C++ precisely because it's able to express complex problems with a high degree of getting-it-right (because while I would never claim to understand C++, I feel confident in my understanding of the subset of C++ that I use). I really like Rust and look forward to it being a better fit for what I want to do, and every time I look at it it's getting closer.

Re: Rust is Software's Salvation

#78

Post by senko »

steveklabnik wrote: post #63
Thaxll wrote: post #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.

We have a lot of Ruby/Python/JavaScript developers using Rust. They handle it just fine.

Are they really the target audience, though? Do they need it?

To an outside observer (me), seems like Rust evangelicism tries to cast a too wide net, ending in "meh" response from many.

Re: Rust is Software's Salvation

#79

Post by Ar-Curunir »

youdontknowtho wrote: post #74
Ar-Curunir wrote: post #61

Earlier quoted context omitted.

There are ways to prevent some logic/protocol problems at the type level using rust: https://hoverbear.org/2016/10/12/rust-state-machine-pattern/ https://blog.tarn-vedra.de/posts/phantom-types-for-safe-apis... https://insanitybit.github.io/2016/05/30/beyond-memory-safet... https://scribbles.pascalhertleif.de/elegant-apis-in-rust.htm... Some libraries use such features to prevent certain kinds of nonce-reuse during en…

I get what you are saying. "Software's Salvation" might require more than compile time type checking. I'm a huge strong typing fan! I'm just saying, type systems can get you a long way toward correct construction. (Or correctness by construction...) The issues with the software/computing world are bigger than array bounds checking and type correctness.

> The issues with the software/computing world are bigger than array bounds checking and type correctness.

Annoyingly, these bugs still bring down our systems in an age when we're on the verge of self-driving cars. Can you imagine that? Your car can crash because somewhere a programmer messed up a simple bounds check.

By removing the possibility of these small annoying bugs, you leave the programmer free to focus on the big picture. That is the entire point of abstraction, and a language which strives to provide these abstractions at no cost to performance is inherently better than one that

a) doesn't provide these abstractions

b) doesn't provide mechanisms to handle the unabstracted layer safely.

Re: Rust is Software's Salvation

#80

Post by jstewartmobile »

This may be wishful thinking, but to echo Alan Kay, I have been hoping that with the stalling of Moore's law we'd start being a little more thoughtful about the instruction set architecture (like the B5000) so that we can do safe and performant things in higher-level languages.

I like Rust. I just don't think doing things in a better C than C is going to yield as much of a payoff as these guys think it will.

Post reply on HN