
Rust is Software's Salvation - k4rtik
http://www.redox-os.org/news/rust-is-softwares-salvation-17/
======
rubiquity
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 (and
sometimes influences from the old finally making it mainstream, like Standard
ML) make programming easier but not fool proof. It's misleading and harmful to
hype the crap out of any language.

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.

~~~
w8rbt
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.

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

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

~~~
prodigal_erik
"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.

~~~
pjmlp
The Pascal family are such languages.

------
youdontknowtho
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 like Klingon to me. functional-ish-
ness is really hot right now. (Like Hansel.)

There's this really sophomoric theme that this seems to be a part of that
keeps resurfacing here. its almost like a conspiracy of influences made the
wrong tech choice in the past and everything would be ok now if we used X.
Where X could be haskell, rust, os2, plan 9, lisp, lisp, lisp, go...theres
quite a few saviors out there they resurface every now and again.

~~~
Ar-Curunir
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://hoverbear.org/2016/10/12/rust-state-machine-pattern/)

[https://blog.tarn-vedra.de/posts/phantom-types-for-safe-
apis...](https://blog.tarn-vedra.de/posts/phantom-types-for-safe-apis.html)

[https://insanitybit.github.io/2016/05/30/beyond-memory-
safet...](https://insanitybit.github.io/2016/05/30/beyond-memory-safety-with-
types)

[https://scribbles.pascalhertleif.de/elegant-apis-in-
rust.htm...](https://scribbles.pascalhertleif.de/elegant-apis-in-
rust.html#session-types)

Some libraries use such features to prevent certain kinds of nonce-reuse
during encryption (one of the more common ways of screwing up encryption).
These constraints are checked at _compile-time_.

Such guarantees are not possible with weaker type systems like that of C.

~~~
youdontknowtho
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.

~~~
Ar-Curunir
> 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.

~~~
youdontknowtho
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 forward to seeing what Mozilla does in Firefox
with it.

~~~
agumonkey
Would you mind sharing other "correct by construction"
ideas/references/libraries you know ?

~~~
youdontknowtho
I was mainly talking about the C++ Guideline Support Library and GSL profile
"checkers" that have been in process for the last couple of years.

[https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-
gu...](https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-guidelines-
checkers-available-for-vs-2015-update-1/)

[https://github.com/Microsoft/GSL](https://github.com/Microsoft/GSL)

[https://www.youtube.com/watch?v=JfmTagWcqoE](https://www.youtube.com/watch?v=JfmTagWcqoE)

------
falcolas
The best defense is a good offense. What is scaring all of the Rust developers
and users so badly that they feel the need to go on such an offensive hype
campaign?

It's worse than the phase Java went through when it hit its peak.

I'll be honest. Until we start seeing some more balanced (frankly, I'd settle
for nuanced) discussion about the compromises made to get Rust's strengths,
I'm staying the hell away from it.

~~~
jasode
_> 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 would take care of all that

2) Java's "write-once-run-anywhere" JVM would render the Windows operating
system obsolete and weaken the evil Microsoft

3) Java applets so you could create rich dynamic websites in the browser

As we now know, none of that actually happened. Java is still a success but it
couldn't match the breathless press it initially received.

Yes, this particular Rust blog promising "salvation" seems to defy Fred
Brook's more conservative "no silver bullet".[2] But relatively speaking,
Rust's enthusiastic community is fairly tame.

[1] [http://imgur.com/a/8gLe4](http://imgur.com/a/8gLe4)

[2]
[https://en.wikipedia.org/wiki/No_Silver_Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet)

~~~
pjmlp
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.

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

~~~
pjmlp
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](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.

------
hubert123
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 compile time. Imagine if I
actually use Rust for real software and have 500k lines of code. I'm putting
my hopes on Jonathan Blow's Jai language.

~~~
qznc
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.

~~~
ekidd
> Maybe it is just the LLVM backend. It still is slow.

It's a combination of two things, as far as I know.

1\. The LLVM backend is slow.

2\. The Rust frontend has historically abused the LLVM backend badly, by
feeding it large amounts of barely optimized code. This is being worked on,
but it's going to take a while.

~~~
nialv7
> 2\. The Rust frontend has historically abused the LLVM backend badly, by
> feeding it large amounts of barely optimized code. This is being worked on,
> but it's going to take a while.

That's what I heard 2~3 years ago.

~~~
steveklabnik
Yes, it's taken a _long time_ to pay down the technical debt from writing a
compiler in itself for years. A huge step forward for doing so landed fairly
recently, MIR, so progress is being made. It's already resulted in significant
improvements, and will lead to more in the future.

------
pklausler
Rust has great potential to be a better tool for C and C++'s niches, and we're
all rooting for it, but for those tasks where a type-safe GC'd pure functional
language can be used, well, they still should be.

------
Thaxll
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.

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

~~~
senko
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.

~~~
steveklabnik
Who are you to say what someone needs or doesn't need?

In this specific case, as projects scale, extra performance is important. So
they've started deploying Rust services to address that need.

Like this post: [https://blog.sentry.io/2016/10/19/fixing-python-
performance-...](https://blog.sentry.io/2016/10/19/fixing-python-performance-
with-rust.html)

Look at that CPU graph. That's actual, important, business value.

> ending in "meh" response from many.

Most of this thread is complaining about people having a _too enthusiastic_
response to Rust, not too little.

~~~
senko
I didn't say Rust has no practical value, nor did I say what someone needs.

I commented on the fact that saying Rust is for _everyone_ you're watering
down your marketing message.

------
rl3
> _Better performance than C_

That's a bold, yet generalized statement.

~~~
falcolas
And, from most indications, incorrect. I think it's beat one C program on
Alloth's benchmark game in processing time, but has been beat in the others.

It performs on par with C++, on the other hand, for what that's worth.

~~~
steveklabnik
Remember that the benchmark game is a game, and it has rules.
[https://news.ycombinator.com/item?id=13267312](https://news.ycombinator.com/item?id=13267312)
is a recent thread about Rust and these rules on at least one benchmark.

Many of the others boil down to "explicit SIMD isn't in stable yet."

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

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

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

~~~
stcredzero
How Rust guarantees referential safety with One Weird Trick.

------
qwertyuiop924
That's a lot of hype.

I don't hate C, like some here, but I am receptive to the many objections to
it: it makes a lot of sense.

But I would be a lot more receptive to this particular attack on C (which is
pretty reasonable) if it wasn't so melodramatic: claiming that Rust will "save
software" and that C is some kind of garbage with no advantages of any sort.
Both are false (although the latter has some truth to it: C has many issues).

The truth is strongly in your favour: No need to stretch it.

------
kevlar1818
> A world where complete system crashes in software are as rare as car crashes

A hilariously wrong/misleading analogy in an otherwise compelling and
agreeable blog post.

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

~~~
rl3
> _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.

------
vatotemking
Even Rust folks disagree with the title of the post:
[https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwa...](https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwares_salvation/)

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

~~~
stcredzero
I think they're right, security wise.

~~~
jstewartmobile
I remember doing all sorts of "clever" arcane things to get a smooth high
frame rate for a program on my old IBM PC. Next generation, they have actual
graphics cards with overlays, easy vsync, and double-buffering where the
buffers can be swapped with a simple toggle instead of trying to find some way
to shuffle the bytes faster.

I was able to replace pages of "cleverness" with a few lines of code in the
same language.

These guys are very impressed with their improved hammer. It might not be the
best tool for the job.

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

------
AnimalMuppet
> Better concurrency than C++

That's... not saying all that much.

> Better performance than C

In 2014? Objection, your honor. Assumes facts not in evidence.

About problems with C:

> Maybe a bug in GCC outputted the wrong machine code

And Rust compilers will never have bugs?

> Maybe a race condition in Linux gave an unprivileged process the ability to
> tamper with your program

And writing your program in Rust is going to save you? Nope.

Now, in the previous two points, the claim may be that GCC/Linux is written in
C, rather than that my program is written in C. But a compiler written in Rust
can still output the wrong machine code, and the borrow checker won't save
you.

------
Dowwie
"better documentation than Python" \-- those are fighting words!

------
kazinator
_> Problems with C:

> [ ... ]

> Maybe a bug in GCC outputted [sic] the wrong machine code_

How does Rust protect against a bug in Rust outputting the wrong machine code?

> _Maybe a race condition in Linux gave an unprivileged process the ability to
> tamper with your program_

Too bad the race-condition free Rust OS that can replace Linux isn't here yet.

~~~
colemickens
It's no Linux replacement, but Redox OS blows my mind with the functionality
they have so far already.

