Live data from Hacker News

Rust is Software's Salvation

redox-os.org

171–180 of 182 posts

Re: Rust is Software's Salvation

#171

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…

Programming isn't hard, it is super easy. Most of the things we ask machines to do are sequences of simple steps. It's so easy in fact that children do it successfully with little training. Programming well can be hard but only because of the limitations of our current tools. Rust is a good step in the direction of safer systems programming and the people who are hyped about Rust are the smartest people in the room,…

That's like saying painting isn't hard it's easy. Children do it all the time with just their fingers. Painting a Mona Lisa is hard but only because we don't have good tooling.

It's a vast oversimplification of the real issues while ignoring the reasons programming or are hard.

Re: Rust is Software's Salvation

#172

Earlier quoted context omitted.

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

Again, I get where you are going with this. Rust isn't the only solution. There are mechanisms that can be used in C++ to make a program memory safe by construction. I'm not even saying that Rust isn't a good solution. (I am saying I don't like the syntax...I'm sure I could get used to it at some point.) I just get very wary when something has this kind of "evangelism" behind it. That's all. I'm really looking forwar…

The disconnect you two have is that C++ doesn't force you to always use those safety features. Furthermore due to reasons that are entirely non non-technical in nature will never force you to use them. The reason Rust exists is to solve that problem and the result is that an entire set of bugs, that have plagued developers in the target C++ domain for ages, are literally impossible.

ADT's have been known to be a superior way to express state machines for ages but C++ for both technical and non-technical reasons will never actually get them. Rust solves this problem by starting over.

Re: Rust is Software's Salvation

#173

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.

We've banned this account for trolling. Please don't create accounts to break HN's guidelines with.

We detached this subthread from https://news.ycombinator.com/item?id=13282028 and marked it off-topic.

Re: Rust is Software's Salvation

#174
post #173

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.

We've banned this account for trolling. Please don't create accounts to break HN's guidelines with. We detached this subthread from https://news.ycombinator.com/item?id=13282028 and marked it off-topic.

please take your life somewhere else.

Re: Rust is Software's Salvation

#175
post #34

Earlier quoted context omitted.

Many of those failures were more political than technical. For example, the internal wars between Windows and DevTools divisions at MSFT, were the biggest reason for Longhorn's failure. MSR with Midori has proven the viability of using C# for systems programming, when no politics are in play and everyone is focused on technical improvements.

Has Longhorn failure been documented publicly ? I'd love to read about it in details.

Yes, kind of.

This is my personal view of the matter, based on MS blogs, talks, papers and how their technology has been presented to those more MS savy.

https://news.ycombinator.com/item?id=11828585

If you follow the OP of the comment there is another view being presented.

There are lots of conspiracy theories about what went wrong, regardless how much truth each one has, the real matter is that politics played a bigger role than technical issues.

Re: Rust is Software's Salvation

#176

Earlier quoted context omitted.

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?

Back in those days we just bought our tools.

Re: Rust is Software's Salvation

#177
post #60

Earlier quoted context omitted.

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

"Integer between 0 and n-1 inclusive" is the type of valid indices for an n element array. The trouble is most languages don't have type systems that allow expressing that.

The Pascal family are such languages.

Re: Rust is Software's Salvation

#178
post #19

Earlier quoted context omitted.

>It's worse than the phase Java went through when it hit its peak. As a person who lived through the 1990s Java hype and had a bookshelf full of the official Java books (Addison-Wesley white books)[1], the Rust evangelism is nowhere near that level. To refresh the memory, 1990s Java evangelists predicted: 1) C/C++ would become obsolete because in the age of abundant desktop resources (cpu power and more RAM), the GC…

Java/Sun really could've been a serious threat to Microsoft. Microsoft knew this, which is why they rushed to create a competitor (.NET).

They were actually doing it with COM, just decided to go with a VM instead because of that.

Now we have UWP as that idea was brought back to life.

Re: Rust is Software's Salvation

#179
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.

Same here, I only dabble in Rust, but still looking forward to get an improved experience.

Every time a new release happens, it takes around one hour to update all VSCode related tooling.

Re: Rust is Software's Salvation

#180
post #128

Earlier quoted context omitted.

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

Go is fast. D is fast, but its compile time meta programming features can make it arbitrarily slow. Java, Python, etc actually compile at run time so the comparison is invalid. You can measure the full iteration speed, but then image based wins (Smalltalk, Common Lisp).

AOT compilers for Java do exist and are quite fast.
Post reply on HN