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

131–140 of 182 posts

Re: Rust is Software's Salvation

#131

Post by pjmlp »

stcredzero wrote: post #54
spacelizard wrote: post #39

Earlier quoted context omitted.

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…

I would say it is a matter of quality in computing related degrees.

My university did a pretty good job teaching the ways of the past.

Sadly things seem to have changed for the worst in the last 20 years.

Re: Rust is Software's Salvation

#132

Post by pjmlp »

spacelizard wrote: post #82
vvanders wrote: post #46

Earlier quoted context omitted.

I think you'll find a lot of Rust's supporters actually come from a Systems Programmers background who've felt the pain before. I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well. All my green-field cod…

I have too but I don't see any magic in Rust's borrowing beyond what you would get with using shared_ptr, weak_ptr and move semantics in C++11. Yeah there is a certain class of errors that the Rust compiler will check that will still give you a segfault in C++. But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effec…

The magic is that there is no way to enforce that in modern C++, in spite of current attempts.

There will always be that compiler or team that doesn't have any kind of reviews, static analysis, making use of binary libraries or legacy code.

Hence why safety at language level is much better than third party tooling, as tools can be ignored.

Re: Rust is Software's Salvation

#133

Post by pjmlp »

wongarsu wrote: post #62
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.

>Rust claims to be faster than C and safer than C at the same time. That's not possible. Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fas…

Attempted multiple times, always ignored by the C crowd.

Re: Rust is Software's Salvation

#134

Post by inimino »

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.

I notice you didn't mention C/C++ which are certainly mainstream and the most likely targets for Rust to try to displace.

Re: Rust is Software's Salvation

#135

Post by coldtea »

spacelizard wrote: post #39
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…

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…

>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

Any ideas about how to add this small "incremental improvement" of Rust-like safety to C, for example?

Re: Rust is Software's Salvation

#136

Post by coldtea »

stcredzero wrote: post #54
spacelizard wrote: post #39

Earlier quoted context omitted.

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…

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

No. In fact even in the actual field of "wheel manufacturing", we have been re-inventing the wheel since for ever.

Those who don't like "re-inventing the wheel", would they rather use stone or wooden wheels for their cars? Or perhaps some of the crude early metal ones? Or they rather use the re-invented modern mix of alloys and plastic?

Re: Rust is Software's Salvation

#137

Post by coldtea »

stcredzero wrote: post #110
bjz_ wrote: post #108

Earlier quoted context omitted.

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

That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better. Not always. Pry debugging Ruby can be pretty awesome but still often leaves a lot to be desired compared to the VisualWorks Smalltalk debugger+environment. Then there's the One Laptop Per Child project. How many developers were trying to recreate things that already existed in Smalltalk? What if they could've free…

>Not always. Pry debugging Ruby can be pretty awesome but still often leaves a lot to be desired compared to the VisualWorks Smalltalk debugger+environment. Then there's the One Laptop Per Child project. How many developers were trying to recreate things that already existed in Smalltalk?

How many Smalltalks were not closed source and with commercial IDEs and toolsets?

Re: Rust is Software's Salvation

#138

Post by 101023810 »

This is a very strange statement. I bet that the compiler can't prove "within-array-bounds" for about 99% of the algorithms in CLRS, but those algorithms are well-written (and have proofs themselves).

None of this matters of course: The hipsters (at least publicly) have taken over Rust and are ruining it for everyone.

EDIT: Downvoting by an idiot hipster within seconds.

Re: Rust is Software's Salvation

#139

Post by coldtea »

pjmlp wrote: post #131
stcredzero wrote: post #54

Earlier quoted context omitted.

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…

I would say it is a matter of quality in computing related degrees. My university did a pretty good job teaching the ways of the past. Sadly things seem to have changed for the worst in the last 20 years.

>My university did a pretty good job teaching the ways of the past.

That's because the past then was still modern.

Re: Rust is Software's Salvation

#140

Post by coldtea »

spacelizard wrote: post #82
vvanders wrote: post #46

Earlier quoted context omitted.

I think you'll find a lot of Rust's supporters actually come from a Systems Programmers background who've felt the pain before. I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well. All my green-field cod…

I have too but I don't see any magic in Rust's borrowing beyond what you would get with using shared_ptr, weak_ptr and move semantics in C++11. Yeah there is a certain class of errors that the Rust compiler will check that will still give you a segfault in C++. But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effec…

>But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effective in either Rust or C++, or Golang, or C99, or what have you

Who said it does? And why would it have to?

It'a just about catching those "certain class of errors that the Rust compiler will check that will still give you a segfault in C++".

Plus a nicer looking language, with a more modern design.

Post reply on HN