
Rust is mostly safety - awalGarg
http://graydon2.dreamwidth.org/247406.html
======
agentgt
I'm a lowly ancient Java programmer and I think Rust is far far more than
safety.

In my opinion Rust is about doing things right. It may have been about safety
at first but I think it is more than that given the work of the community.

Yes I know there is the right tool for the right job and is impossible to fill
all use cases but IMO Rust is striving for iPhone like usage.

I have never seen a more disciplined and balanced community approach to
creating PL. Everything seems to be carefully thought out and iterated on.
There is a lot to be said to this (although ironically I suppose one could
call that safe)!

PL is more than the language. It is works, community and mindshare.

If Rust was so concerned with safety I don't think much work would be done on
making it so consumable for all with continuous improvements of compiler error
messages, easier syntax and improved documentation.

Rust is one of the first languages in a long time that makes you think
different.

If it is just safety... safety is one overloaded word.

~~~
dom0
> In my opinion Rust is about doing things right.

On the other hand there is a quite dark cloud on the horizon with the stable
vs nightly split. You can't run infrastructure on nightly builds; or add
nightly builds to distributions.

~~~
kincardine
I'm sorry your comment has gotten the response it has.

The looming dark cloud of stable vs. nightly only looks like a dark cloud to
those outside the Rust community.

The article that made its way up Hacker News awhile ago
([https://news.ycombinator.com/item?id=13251729](https://news.ycombinator.com/item?id=13251729))
got pretty much no traction whatsoever in the Rust community.

~~~
robohamburger
I have found the split has only gotten better with time. It used to be most
package maintainers assumed you were using nightly/beta. The last holdouts I
see are diesel and serde which have instructions for using nightly. Even then
they realize no one wants to ship code on nightly so they provide directions
for making a building using stable rust. Once the procedural macros stuff is
stabilized they can stop.

I have been extremely pleased with the rust community and the rust
maintainers.

And no I was not paid by them to say this... :)

~~~
Ar-Curunir
From my impression, they'll be working with the stable compiler in a few
weeks.

------
rcthompson
I think Rust is mostly about safety in the same way that skydiving is mostly
about safety. Having safety features that you know you can rely on allows you
to take risks that you normally wouldn't in order to accomplish some really
awesome things.

(I guess in this analogy C is a parachute that you have to open manually,
while Rust is a parachute that always opens at exactly the right altitude, but
isn't any heavier than a normal parachute.)

~~~
zerofan
Have you done much skydiving? I used to go three days a week, for a couple
years, between 4-10 jumps a day at a place that had world class experts. My
experience is that only beginning skydivers are constantly preaching safety.
They go around (vocally) judging everything they see, and I think they do it
because it alleviates their own fear. Instructors would _teach_ safety, but
really only to their own students.

I think the safety aspect of Rust appeals to a lot of beginning programmers.
They can feel safer looking down their nose at us dangerous C or C++
programmers.

> Rust is a parachute that always opens at exactly the right altitude

This isn't a good metaphor. Frequently it's safer to pull higher, and on some
occasions, you're safer opening lower than you had planned... I think a canopy
that always opened at the prescribed height would cause many unnecessary
deaths. That doesn't say anything about Rust, one way or the other.

~~~
kibwen
_> I think the safety aspect of Rust appeals to a lot of beginning
programmers._

Is that a bad thing? All programmers start as beginners, and if C is too
painful to begin with then they'll learn via an easier language, and then
comfortably spend their whole careers using those easier languages. If we want
to expand the field of systems programmers organically, then we need to make
tools that don't punish beginning programmers.

 _> They can feel safer looking down their nose at us dangerous C or C++
programmers._

What makes you feel like anyone's looking down their noses at you? Every
language in history has been made to address the perceived flaws of some prior
language. Safety is a crucial selling point for a huge chunk of people, and C
and C++ have failed to appeal to this market. Just because safety isn't a
priority for you doesn't mean that the people for whom it is a priority are
suddenly pretentious.

~~~
zerofan
> > I think the safety aspect of Rust appeals to a lot of beginning
> programmers.

> Is that a bad thing?

The appeal to beginners is fine, maybe even a good thing, but the
condescending comments from beginners is a lot like listening to a teenager
who thinks they know everything.

> What makes you feel like anyone's looking down their noses at you?

There're are no shortage of obnoxious comments from beginning Rust users here
and on Reddit. If you can't see them, it might be because you're aligned with
that point of view.

A recent one implied the whole world is going to end because of Heartbleed-
like exploits. Don't they realize that despite the occasional high profile
exploits, the world is generally running just fine? Don't they realize that
the OpenSSL developers would've probably used pools of dirty memory to avoid
allocation costs and unsafe blocks to avoid bounds checking had they developed
that code in Rust? They got bit by sloppy optimization, and Rust isn't immune
to that. I really wish people weren't so afraid of everything that achieving
safety is their primary goal.

> Just because safety isn't a priority for you doesn't mean that the people
> for whom it is a priority are suddenly pretentious.

It's not pretentious if you make your own decision for your own project. It's
not even pretentious to spread the good word and say how much you like Rust.
It is very pretentious and condescending when you say something like in
Graydon's article: """When someone says they "don't have safety problems" in
C++, I am astonished: a statement that must be made in ignorance, if not
outright negligence."""

Are you going to stand by that sentence? You probably should, because the
newbies will love you for it, and it might help increase adoption of your
language. It really shouldn't matter if you alienate a few of us old-timers
who really don't have safety problems in C++.

To be clear, I like Rust. I've been following it for years, and I'm
disappointed that it's not an adequate replacement for C++ (which I really
don't like).

~~~
kibwen
_> There're are no shortage of obnoxious comments from beginning Rust users
here and on Reddit. If you can't see them, it might be because you're aligned
with that point of view._

Can you give me an example of a comment in this thread that you find to be
from a pretentious beginner? Alternatively, if you're calling the author of
this article a beginner, I can assure you that he isn't.

~~~
jibalt
The guy's a troll.

------
steveklabnik
I'll probably be writing a slightly longer response post to this later, but
for now... EDIT: here it is: [http://words.steveklabnik.com/fire-mario-not-
fire-flowers](http://words.steveklabnik.com/fire-mario-not-fire-flowers)

I think the core of it is this:

> Safety in the systems space is Rust's raison d'être. Especially safe
> concurrency (or as Aaron put it, fearless concurrency). I do not know how
> else to put it.

But you just did! That is, I think "fearless concurrency" is a better pitch
for Rust than "memory safety." The former is "Hey, you know that thing that's
really hard for you? Rust makes it easy." The latter is, as Dave[1] says, "eat
your vegetables."

I'm not advocating that Rust lose its focus on safety from an implementation
perspective. What I am saying is that the abstract notation of "safety" isn't
compelling to a lot of people. So, if we want to make the industry more safe
by bringing Rust to them, we have to find a way to make Rust compelling to
those people.

1: [https://thefeedbackloop.xyz/safety-is-rusts-
fireflower/](https://thefeedbackloop.xyz/safety-is-rusts-fireflower/)

~~~
GolDDranks
I would argue that if the Rust project would have just one mission statement,
it wouldn't be "create a safe systems programming language". It would be "move
towards a world where safe systems programming is the norm".

What's the difference? Both of the statements have the premise that Rust is –
and ought to be – a safe systems programming language. However, the latter
captures not only the REAL goal, but also the nuances and tensions: while
safety is indispensable, we must do something else too, for the programming
society to accept the safe tools we are trying to promote. That means
ergonomics, that means performance, that means ease of use, that means wide
availability – and that might also mean advocation of visions of a better
world, which is what this blog post of Graydon's does.

~~~
steveklabnik
I really, really like this. Thank you. Well put.

------
yjftsjthsd-h
I was surprised to see Ada in the list of unsafe languages, since it always
was sold to me as being designed for safety. A bit of searching leads me to
believe that Ada is better about memory even though it mostly uses types for
safety, and better enforcement of bounds on array access should solve overflow
issues regardless. Am I missing something?

~~~
pjmlp
Ada still requires manual heap management, although it can be mostly
automated.

So you might occasionally see the unsafe package being used to deallocate
memory, even though there are better ways to do it, e.g. controlled types.

The other point, is that Rust prevents data races via the type system, while
you can deadlock Ada tasks if the monitors aren't properly implemented.

~~~
jnbiche
> while you can deadlock Ada tasks if the monitors aren't properly
> implemented.

It's not clear to me if you're suggesting otherwise, but you can definitely
deadlock Rust as well (although it's true that Rust statically prevents data
races).

~~~
pjmlp
Ah, that was my understanding.

------
ocschwar
Rust is about letting the compiler slap you for your mistakes in the privacy
of your own Xterm, instead of letting Jenkins do it 10 minutes later, in front
of all your co-workers.

~~~
geodel
Maybe it will change in future. Currently slaps seems so hard that developers
are still smarting and not producing code for production

~~~
steveklabnik
Rust is being used in a number of places in production for a wide variety of
things: [https://www.rust-lang.org/en-US/friends.html](https://www.rust-
lang.org/en-US/friends.html)

~~~
geodel
I know and I would also try Rust if I can make some small but useful things at
work. But I mostly deal with various combinations of XML, SOAP, HTTP, LDAP
etc. Rust does not have anything over Java, which I use currently, in my
usecases.

~~~
nnethercote
It's perfectly reasonable to say "Rust isn't appropriate for my use case".
Your comment higher up was more along the lines of "Rust isn't appropriate for
anyone" which is far less reasonable.

~~~
zerofan
If you're going to put words in his mouth, you should make them much stronger
words. It's not a valid argument either way, but it'll seem more dramatic. (He
didn't say either of your quotes...)

~~~
tomjakubowski
I downvoted you initially, but changed to an upvote to hopefully ungrey your
comment.

The use of quotation marks on the Internet (especially on Internet discussion
forums) has become non-standard, and I can see how it could be confusing. I
think on HN that we tend to use _italics_ or email-style

> block-quoting

to indicate direct quotations of posts or user comments.

Quotation marks on forums like HN tend to be used either to mark dialogue
(things spoken out loud) or to mark paraphrased or "hypothetical" thoughts.
This is different from the use of quotation marks in formal English writing,
as described by Wikipedia [1]. Here, the quotation marks are used to separate
the "paraphrased thought" from the rest of the sentence.

I'm actually finding it hard to describe exactly how quotation marks are used
this way on the Internet; it's something I've just developed a "feel" for.

There's more discussion of this phenomenon here.
[http://metatalk.metafilter.com/23184/Should-we-keep-
quotatio...](http://metatalk.metafilter.com/23184/Should-we-keep-quotation-
marks-just-for-quotations)

[1]:
[https://en.wikipedia.org/wiki/Quotation_marks_in_English](https://en.wikipedia.org/wiki/Quotation_marks_in_English)

~~~
zerofan
Sorry, next time I'll say something like "If you're going to misrepresent his
intention" so as not to confuse a quoted sentence. And I won't use the word
"say", because clearly nobody says anything in a text forum. /s

I find it very obnoxious when people exaggerate what someone else said so as
to make it easier to contradict. I gather you don't have any problem with
that? Yet you do have a problem with people calling it out as bad behavior?
Are you sure you know why you're policing anything?

~~~
jibalt
He didn't misrepresent anything. You're the one doing all the misrepresenting,
exaggerating, and being obnoxious.

------
alkonaut
Its the safe _and_ performant that attracts me.

If you look at Rust from C then the point is safety, but if you look at it
from the other direction, e.g from F# then what attracts you is that you will
get the _same_ safety guarantees (and perhaps a few more) but without the GC
and heap overhead.

~~~
MichaelGG
Bingo. I've written high perf F# for a DB indexing and searching. The entire
time I was wishing for allocation-free inlined closures and stack allocation.
And for a few places, I'd really like an easy way to do asm or get really top
notch codegen (integer decoding). Rust seems a lot like a fast ML. Not quite
as concise as I'd like but worth it for the perf without being ugly mentally.

And the perf will surpass C in some situations due to abstraction. One popular
open source platform spends 30% CPU time on malloc and strcpy because tracking
ownership was so difficult and it wasn't obvious it'd be a hotspot. In Rust
that would be a non issue from beginning.

~~~
jules
You may be interested in MLton, which is an ML compiler that achieves high
levels of optimisation by aggressively specialising your code: generic
functions get specialised to the type and higher order functions get inlined
to eliminate closure allocation.

------
koja86
In case you missed that there's a big disillusioned C++ crowd out there.

Just hear the pain:
[https://news.ycombinator.com/item?id=13276351](https://news.ycombinator.com/item?id=13276351)

And some of them are watching you with great interest.

~~~
Ar-Curunir
And there's a tired security crowd watching Rust with great hope; C++ and C
have created innumerable security holes at the expense of "convenience".
Cryptographic libraries, codec libraries, image conversion libraries, OS
kernels, sandboxes, virtual machines, browsers, (the list is endless) have all
suffered glaring security holes from the lack of memory hygiene afforded by C
and C++.

Any time your code takes in untrusted input, it should not be written in an
unsafe language.

~~~
Animats
Exactly. Which is why I've been so critical, in Rust discussions, of the
excessive use of "unsafe". The reply is usually something equivalent to "it's
not unsafe the way I do it". Sometimes the claimed performance gain isn't
there. I had a link yesterday to a forum post where someone was complaining
that using an unsafe vector access function didn't speed up their program.
Optimizer 1, programmer 0.

(Early in my career, I spent four years doing maintenance programming for a
mainframe OS. Every time a machine crashed, taking a few hundred users off
line for several minutes, I got a crash dump, which I had to analyze and fix.
Most of the errors were pointer problems in assembly code. When Pascal came
out, I thought we were past that. Then came C. I had hope for SafeMesa, but
nobody outside PARC used it. I had hope for Modula I/II/III, but DEC went
under. I had hope for Ada, but it was considered a complex language back then.
Rust finally offers a way out of this hole. Don't fuck up this chance.)

~~~
Manishearth
I am still skeptical that "excessive use of unsafe" is actually a thing
happening in Rust. Almost all the unsafe I see is for doing FFI (either for
interfacing with a library or OS primitives). There's a bunch of it for
implementing datastructures and stuff, and _extremely little_ unsafe being
used "for performance". Off the top of my head nom and regex do this in a few
places, and that's about it. Grepping through my cargo cache dir seems to
support my assertion; most of the crates there are FFI (vast majority is FFI)
or abstractions like parking_lot/crossbeam/petgraph.

I agree that we should avoid unsafe as much as possible and be sure that
unsafe blocks are justifiable (with stringent criteria on justification). I'm
don't think as-is this is currently a problem in the community.

It's good to be wary though :)

~~~
Animats
You keep making that claim without backup. Two days ago I posted links to
extensive use of "unsafe" in matrix libraries. (Some of that code was clearly
transliterated from C. Raw pointers all over the place.) That's entirely for
performance; all that code could be safe, at some performance penalty.

I'd suggest using only safe code for whatever matrix/math library gets some
traction, and then beating on the optimizer people to optimize out more
checks.

~~~
Manishearth
I just gave you backup; I grepped my whole .cargo cache dir (both the one used
by servo and my global one). You have also made your claim without backup --
you have repeatedly claimed that this is an endemic problem in Rust, with only
individual crates (most of them obscure ones) to back it up, and I only
usually make my claim in response to claims like yours -- the burden of proof
is on you. Anyway, I do provide some more concrete data below, so this isn't
something we should argue about.

Marices fall under the abstraction umbrella IMO. This is precisely what unsafe
code is _for_. However, I totally agree that we should be fixing this in the
optimizer, with some caveats. Am surprised it doesn't get optimized already,
for stack-allocated matrices. I'm wary of adding overly specific
optimizations, because an optimization is as unsafe as an unsafe block anyway,
it just exists at a different point of the pipeline. If there's a general
optimization that can make it work I'm all for it (for known-size matrices
there should be I think), but if you have a specific optimization for the use
case imo it's just better to use unsafe code.

The raw pointers thing is a problem, but bad crates exist. They don't get
used.

I recently did start going auditing my cargo cache dir to look for bad usages
of unsafe, especially looking for unchecked indexing, since your recent
comments -- I wanted to be sure. This is what I have so far:
[https://gist.github.com/Manishearth/6a9367a7d8772e095629e821...](https://gist.github.com/Manishearth/6a9367a7d8772e095629e82184f05ad4)

That's a list of _only_ the crates containing unsafe code in my global cargo
cache (this contains most, but not all, of the crates used by servo -- my
servo builds use a separate cargo cache for obsolete reasons, but most of
those deps make it into the global cache too whenever I work on a servo dep
out of tree)

I've removed dupe crates from the list. I have around 600 total crates in my
cache dir, these are just the ones containing unsafe code.

Around a 70 of these crates use unsafe for FFI. Around 30 are abstractions
like crossbeam and rayon and graphs.

I was surprised at the number of crates using unchecked indexing and unchecked
utf8. I suspected it would be less than 10, but it's more like 20. Still, not
too bad. It's usually one or two instances of this per crate. That's quite
manageable IMO. Though you may want to be stricter about this and consider
those numbers to be problematic, which I understand.

I bet you're right that many of these crates can have the unchecked indexing
or other unsafe code removed (or, the perf penalty is not important anyway). I
probably should look into this at some point. Thanks for bringing this to my
attention!

~~~
Animats
I looked at a few.

"itoa" is clearly premature optimization. That uses an old hack appropriate to
machines where integer divide was really expensive, like an Arduino-class CPU.
It's unlikely to help much on anything with a modern divide unit.

"httpparse", "idna", "serde-json", and "inflate" should be made 100% safe -
they all take external input, are used in web-facing programs, and are classic
attack vectors.

Not much use of number-crunching libraries; that reflects what you do.

I'll look at some more later. How to deal effectively with incoming UTF-8,
especially bad UTF-8, may need some thinking.

~~~
dtolnay
I maintain two of the crates you called out so here is a bit more detail on
the use cases:

"itoa" is code that is copied directly from the Rust _core_ library. Every
character of unsafe code is identical to what literally everybody who uses
Rust is already running (including people using no_std). Anybody who has
printed an integer in Rust has run the same unsafe code. It is some of the
most widely used code in Rust. If I had rewritten any of it, even using
entirely safe code, it would be astronomically more likely to be wrong than
copying the existing code from Rust. The readme contains a link to the exact
commit and block of code from which it is copied.

As for premature optimization, nope it was driven by a very standard (across
many languages) set of benchmarks: [https://github.com/serde-rs/json-
benchmark](https://github.com/serde-rs/json-benchmark)

"serde_json" uses an unsafe assumption that a slice of bytes is valid UTF-8 in
two places. This is either for performance or for maintainability, depending
on how you look at it. Performance is the more obvious reason but in fact we
could get all the same speed just by duplicating most of the code in the
crate. We support deserializing JSON from bytes or from a UTF-8 string, and we
support serializing JSON to bytes or to a UTF-8 string. Currently these both
go through the same code path (dealing with bytes) with an unchecked
conversion in two important spots to handle the UTF-8 string case. One of
those cases takes advantage of the assumption that if the user gave us a &str,
they are guaranteeing it is valid UTF-8. The other case is taking advantage of
the knowledge that JSON output generated by us is valid UTF-8 (which is
checked along the way as it is produced).

Here again, both of those uses are driven by the benchmarks in the repo above
and account for a substantial performance improvement over a checked
conversion.

~~~
Animats
_" serde_json" uses an unsafe assumption that a slice of bytes is valid UTF-8
in two places. This is either for performance or for maintainability,
depending on how you look at it. Performance is the more obvious reason but in
fact we could get all the same speed just by duplicating most of the code in
the crate._

Could that be done safely with a generic, instantiated for both types?

~~~
dtolnay
Yes, that is what we already do. The two unsafe UTF-8 casts are the two
critical spots at opposite edges of the generic abstraction where the
instantiation corresponding to UTF-8 string needs to take advantage of the
knowledge that something is guaranteed to be valid UTF-8.

What we have is as close as possible to what you suggested.

As I mentioned, we could get rid of the unsafe code in other ways without
sacrificing performance. Ultimately it is up to me as a maintainer of
serde_json to judge the likelihood and severity of certain types of bugs and
make tradeoffs appropriately. There are security-critical bugs we could
implement using only safe code, for example if you give us JSON that says _{
"user": "Animats"}_ and we deserialize it as _{ "user": "admin"}_. My judgment
is that using 100% safe code would increase the likelihood of other types of
bugs (not related to UTF-8ness) and the current tradeoff is what makes the
most sense for the library.

From another point of view, performance and safety are synonyms in this case,
not opposites. If we use 0.1% unsafe code and perform faster than the fastest
100% unsafe C/C++ library (which is what the benchmarks show for many use
cases) then people will be inclined to use our 0.1% unsafe library. If we give
up unsafe but sacrifice performance, people will be inclined to use the 100%
unsafe C/C++ alternatives.

------
zpallin
I agree with the premise of the article.

However, I feel that Steve Klabnik is trying to dispel myths about Rust not
being anything "but" safety, to shape how other Rust developers talk about
Rust, not denying that Rust's central purpose is around being a safe language.

This is because there is a lot of miscommunication about Rust. A lot of people
who aren't immediately sold on the language walk away thinking it's slow (it's
not), it's complicated (not really), and not production ready (it actually
is). And that's because Rust developers don't know how to talk about Rust. I
am guilty, for one.

Since Steve is such a huge part of RustLang development, it's his duty to
direct the conscious effort to promote the language.

No reason to get into a debate over click-baity titles. :)

------
bassislife
The issue with safety is that nothing is really safe. Once you have some level
of safety in your programming language, you realize that there are still a lot
of other sources of hazard (hardware errors, programming logic errors etc.)

So I guess, it would be better to say that Rust is about decreasing
unsafetyness or whatever the correct word for that is.

edit: since I see posts about Go, this is evidently another approach toward
decreasing unsafetyness by providing fewer and easier to understand primitives
so that the programming logic is harder to write wrong. It might come at a
moderate cost for some applications.

~~~
rkrzr
> The issue with safety is that nothing is really safe.

There is a trade-off between safety and expressiveness. Clearly you can always
shoot yourself in the foot if your language is expressive enough (like any
Turing-complete language).

But I think that is beside the point here. This is about eliminating whole
classes of errors.

A good type system (e.g Rust's, Haskell's..) can eliminate _all_ type errors
from your programs.

A good memory model can eliminate _all_ unsafe memory problems.

There are also languages that can eliminate all data races from your programs.

All these advances in PL theory make it easier and safer to deal with hard
problems like concurrency, memory management etc. and thus allow us to focus
on what our programs can actually _do_.

~~~
paulddraper
> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors
> from your programs.

It depends what you call a "type error". Is calling `car` on a `nil` instead
of a `cons` a type error?

~~~
pavelludiq
In common lisp 'nil is of type 'null which is a subtype of 'list, which is a
union of the types 'null and 'cons so it wouldn't be an error. Other lisps
might chose to do it differently.

------
paulddraper
If you're a C++ programmer, Rust is mostly about memory safety.

If you're a Java programmer, Rust is mostly about tighter resource usage.

If you're a Python programmer, Rust is mostly about type safety and speed.

~~~
llogiq
I'm a polyglot programmer and for me Rust is mostly about the awesome
abstractions and the great community.

~~~
paulddraper
> If you're a Javascript programmer, Rust is mostly about the awesome
> abstractions and the great community.

;)

------
stcredzero
_I do not mean to pick on C++: the same problems plague C, Ada, Alef, Pascal,
Mesa, PL /I, Algol, Forth, Fortran ... show me a language with manual memory
management and threading, and I will show you an engineering tragedy waiting
to happen._

I think if programming is to make progress as a field, then we need to develop
a methodology for figuring out how to quantify the cost-benefit trade-offs
around "engineering tragedies waiting to happen." The fact that we have all of
these endless debates that resemble arguments about religion shows that we are
missing some key processes and pieces of knowledge as a field. Instead of
developing those, we still get enamored of nifty ideas. That's because we
can't gather data and have productive discussions around _costs._

There are significant emergent costs encountered when "programming in the
large." A lot of these seem to be anti-synergistic with powerful language
features and "nifty ideas." How do we quantify this? There are significant
institutional risks encountered when maintaining applications over time spans
longer than several years. There are hard to quantify costs associated with
frequent short delays and lags in tools. There are difficult to quantify costs
associated with the fragility of development environment setups. In my
experience most of the cost of software development is embodied in these
myriad "nickel and dime" packets, and that much of the religious-war arguing
about programming languages is actually about those costs.

(For the record, I think Rust has a bunch of nifty ideas. I think they're
going down the right track.)

~~~
runT1ME
> A lot of these seem to be anti-synergistic with powerful language features
> and "nifty ideas."

I think this is a pretty big myth that only applies to some of these language
features.

~~~
stcredzero
_I think this is a pretty big myth that only applies to some of these language
features._

If you admit that it applies to some language features, then it's not a myth
by definition.

In Smalltalk, #doesNotUndertand: handlers and proxies and unfortunate "clever"
use of message sends synthesized within custom primitives could result in
outsized costs. (It's where method_missing comes from in Ruby.) It's not that
you couldn't do powerful and useful things with those facilities. It's that
large projects that were around for years tended to accumulate "clever" hacks
from bright young developers with a little too much hubris. Often, those costs
would be incurred years after the code was written.

Yes, it only applies to some language features. But it clearly does apply to
some of them. I don't think it's easy to come by quantified costs for these.
Doesn't this strike you as a problem for our field?

------
geodel
The original Rust author make great points about safety. I think this new
thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in
industry as one of the major goal. Currently Rust is about Go's age but
nowhere close in usage. As the roadmap says "Production use measures our
design success; it's the ultimate reality check." I agree with that.

~~~
lmm
> Currently Rust is about Go's age but nowhere close in usage.

Citation? I see a lot of people talking about both, but not very many public
projects in either. Rust at least has a "killer app" on the way in the form of
Servo, whereas I haven't heard of any user-facing programs in Go.

~~~
SloopJon
FWIW, Go and Rust are 16 and 43, respectively on the TIOBE index:

[http://www.tiobe.com/tiobe-index/](http://www.tiobe.com/tiobe-index/)

A Github search turned up 2,658 Go repositories with more than 100 stars:

[https://github.com/search?l=go&q=stars%3A%3E100&type=Reposit...](https://github.com/search?l=go&q=stars%3A%3E100&type=Repositories)

compared to 348 Rust repositories:

[https://github.com/search?l=rust&q=stars%3A%3E100&type=Repos...](https://github.com/search?l=rust&q=stars%3A%3E100&type=Repositories)

Notably, Docker has more stars than Go itself.

Edit: you may also be interested in IEEE Spectrum's interactive list of the
top programming languages:

[http://spectrum.ieee.org/static/interactive-the-top-
programm...](http://spectrum.ieee.org/static/interactive-the-top-programming-
languages-2016)

With the default parameters, Go and Rust are 10 and 26, respectively.

~~~
hajile
It's also worth noting that you're a bit less likely to see rust users because
the kind of software that wants rust instead of golang tends to be the kind
that gets written by a large company with deep pockets and a preference for
closed source repositories.

~~~
kid0m4n
If only Go was useful in building closed source products. Google must not have
gotten the memo about Rust yet.

~~~
coldtea
Contrary to popular legend, Google is not particularly strong on Go use, and
it's not "THE official language".

It wasn't officially commissioned or officially adopted by Google to solve
Google's coding problems as some believe.

It was merely initiated by a small team in Google, as their proposal for
solving Google-scale coding problems. And has never been mandatory for new
Google projects etc.

Go is ONE of the allowed languages, from what I know, but tons of stuff is
written in Java, C++ and Python with no intentions of switching.

All those years, only a few, and basically trivial with respect to Google's
needs, use examples for Go have come out of Google-land (a proxy/balancer for
MySQL used in YouTube, Google Downloads caching, etc).

~~~
geodel
Why would they switch a perfectly working software code with something in Go?
Java is 15 year older than Go so obviously lot more code would be in it. More
interesting case is Dart as despite having 'official' Google support, industry
wide usage is rather tepid compared to Go.

------
jMyles
> countless lives lost

I have no doubt that people have had their lives ruined, or even died, as the
result of flaws in system programming, but is anyone actually tracking this?
Is it "countless?"

~~~
psyc
TDD: "If you're not doing this, you're not a real engineer."

Rust: "If you're not doing this, you're a murderer."

~~~
lotyrin
I'd really like to see an organization when evaluating tools or practices, do
an actual risk assessment even just once. Even a hand-wavy conversation where
we make 0th-order number-of-zeros estimates on any of the quantities involved
in making such a decision.

I'm a huge fan of thorough designs, engineering formalities and quantifying
application performance, but if we're building some fast food ordering app is
expected to increase sales by 10 percent as soon as it's done and there's no
risk from quality or availability or performance of the application (other
than the 10 percent extra sales, we expect people to walk in / drive thru like
normal if it under-performs on those metrics) then it's obvious the business
value is in launching a minimal implementation as soon as possible using tools
that optimize for productivity, not safety or performance.

Too often I see dogmatic pure functional TDD line of business app with
continuous deployment infrastructure that could break for two weeks at a time
without impacting anyone, or the copy-pasted-code-from-google-searches
business-critical application that loses money for every hour it's offline but
has no software development lifecycle or monitoring or alerting or anything.

------
pjmlp
> Modula-3, Eiffel, Sather

Nice to see these languages on Rust's team radar, specially Sather.

Just shows how you guys have researched prior work, congratulations.

~~~
steveklabnik
To be clear, Graydon doesn't work on Rust anymore, and hasn't in years. His
knowledge of the space is absolutely impressive, though. :)

~~~
nickpsecurity
Only inaccuracy I find is in his claim on safe concurrency in other languages.
It existed in Concurrent Pascal (used in Solo OS), Ravenscar Ada (widely
deployed), and Eiffel SCOOP (widely deployed). Rust isn't the first doing
this. It's just apparently the best at it in system space. Ada camp is making
a comeback, though, with ParaSail that looks interesting:

[http://www.embedded.com/design/other/4375616/ParaSail--
Less-...](http://www.embedded.com/design/other/4375616/ParaSail--Less-is-more-
with-multicore?page=0)

~~~
pjmlp
ParaSail development looks stalled since its main designer joined AdaCore.

Just my impression, anyone feel free to correct me.

------
progman
The author states: "A few valiant attempts at bringing GC into systems
programming -- Modula-3, Eiffel, Sather, D, Go -- have typically cut
themselves off from too many tasks due to tracing GC overhead and runtime-
system incompatibility, and still failed to provide a safe concurrency model."

Nim follows a different approach.

Details: [http://nim-lang.org/docs/manual.html#threads](http://nim-
lang.org/docs/manual.html#threads)

Benchmark (with Rust): [https://github.com/costajob/app-
servers](https://github.com/costajob/app-servers)

------
childintime
I think Rust is not about safety, but about reusability. Do you like to take
on a dependency on someone's code when it is in C? The answer is: roll your
own code. Rust means the end of that.

Rust means software that can be written once and used "forever". Thus it
enables true open source. In comparison C/C++ pay a mere lip-service, by also
giving you, along with the code, lots of reasons to worry.

This is the real innovation behind Rust.

~~~
oconnor663
To be fair to C, I think C's answer here is dynamically linked shared
libraries. They have lots of problems, but still they're very widely used.
Even Rust programs dynamically link libc by default.

------
Ar-Curunir
I think it's a bit funny that in an industry that (supposedly) prides itself
on "meritocracy", there are many people that refuse to use (or learn)
performant memory-safe languages, when memory-safe code is always better than
memory-unsafe code (in terms of resource usage, reduction of bugs, etc, etc.).

------
willtim
It's a shame there is no mention of ATS, which also attempts safe systems
programming usings an advanced type system.

------
dbcurtis
What about bare-metal options? Is there any development effort in that
direction?

Most of the C that I do these days is Arm Cortex-Mx work. Realtime cooperative
multi-tasking using an RTOS on the bare metal. It seems like Rust would be a
great option for that kind of work if the low-level ecosystem were complete
enough.

~~~
johnny22
[https://github.com/hackndev/zinc](https://github.com/hackndev/zinc) is one
effort in that vein. I'm not sure what else exists though.

~~~
dbcurtis
That actually looks very good. They are supporting STM32F4, which is one part
I use a lot. I see they are using the GNU linker (and presumeably binutils)
which makes total sense. No reason to reinvent all of that, and that tool
chain is robust.

------
pron
I completely agree. This is what I wrote on Reddit in response to Klabnik's
post:

Rust can make such an important contribution to such an important slice of the
software world, that I really fear that trying to make a better pitch and get
as many adopters as quickly as possible might create a community that would
pull Rust in directions that would make it _less_ useful, not more.

Current C/C++ developers really do need more safety. They don't need a more
pleasant language. Non C/C++ developers don't really need a language with no
GC. Now, by "don't need" I absolutely don't mean "won't benefit from". But one
of the things we can learn from James Gosling about language design is, don't
focus on features that are useful; don't even focus on features that are
_very_ useful; focus on features that are absolutely indispensable... and
compromise on all the rest. The people behind Java were mostly Lispers, but
they came to the conclusion that what the industry really, really needs, is
garbage collection and good dynamic linking and that those have a bigger
impact than clever language design, so they put all that in the VM and wrapped
it in a language that they made as familiar and as non-threatening as
possible, which even meant adopting features from C/C++ that they _knew_ were
wrong (fall-through in switch/case, automatic numeric widening), all so they
could lower the language adoption cost, and sell people the really
revolutionary stuff in the VM. Gosling said, "we sold them a wolf in sheep's
clothing". I would recommend watching the first ~25 minutes of this talk[1] to
anyone who's interested in marketing and maintaining a programming language.

If Rust would _only_ win over 10% of C/C++ programmers who _today_ understand
the need for safety, say, in the next 5-10 years, that would make it the
highest-impact, most _important_ language of the past two decades. In that
area of the software world change is very, very slow, and you must be patient,
but that's where Rust could make the biggest difference because that's where
its safety is indispensable. A few articles on Rust in some ancient trade
journals that you thought nobody reads because those who do aren't on Twitter
and aren't in your circle may do you more good than a vigorous discussion on
Reddit or the front page of HN. Even the organizational structure in
organizations that _need_ Rust looks very different from the one in companies
that are better represented on Reddit/HN, so you may need to market to a
different kind of people. So please, be patient and focus your marketing on
those that really _need_ Rust, not on those outside that group you think you
can win over most quickly because they move at a faster pace.

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

~~~
nickpsecurity
"Current C/C++ developers really do need more safety. They don't need a more
pleasant language. "

The number of C++ developers griping in HN threads about language-level
problems effecting their work tends to disagree. It's not as if they wanted
C++ to be designed that way. It was just only one with big companies' support
that had zero-cost abstractions for programming in the large & great
compatibility with C libraries. Many would love a better language. Matter of
fact, they tell us in Rust threads here.

" Non C/C++ developers don't really need a language with no GC."

They might benefit if the app is aiming for max performance (esp HPC), memory
efficiency (eg embedded), or minimal latency (eg real-time. From there, they
basically choose among C, Objective-C, C++, or Fortran. Rust has features
superior to those in terms of safety & abstractions. On HPC side, Julia is
already showing the kind of takeup a language can get if it's faster than
Python/NumPy but not C or Fortran.

"if Rust would only win over 10% of C/C++ programmers who today understand the
need for safety, say, in the next 5-10 years, that would make it the highest-
impact, most important language of the past two decades."

I agree. Let's hope it happens. With that on the demand side, we'd also see
tools like Frama-C, Saturn, Astree, and so on start popping up for the unsafe
part of Rust. On top of a shitload of libraries doing things the safer way
since community encourages it. It's really the network effects that matter in
programming languages. I think Rust might have good, network effects if it
takes off.

~~~
pron
> Many would love a better language. Matter of fact, they tell us in Rust
> threads here.

Absolutely, but my emphasis was on the difference between "love" or "want",
and "need". Switching a programming language is _extremely_ expensive, doubly
so in systems programming. Organizations won't pay the price for something
that doesn't make a _big_ impact. Unlike many other new languages, Rust does
have the potential to make a big, bottom-line impact, but that impact is
almost entirely due to safety.

> They might benefit if the app is aiming for max performance (esp HPC),
> memory efficiency (eg embedded), or minimal latency

I don't think max performance is an issue at all, nor even minimal latency
where you need it (there are realtime GCs, and GC languages do support arena
GC allocation in embedded and realtime settings, like realtime Java), but
definitely it's a big gain in memory efficiency.

But again, I said they could benefit. It's just that the main focus shouldn't
be on those that would benefit, but on those for whom the language is
indispensable, or _tremendously_ beneficial.

> I think Rust might have good, network effects if it takes off.

Absolutely, it's just that if you want Rust to really have an impact rather
than just be popular, you need that network effect to be in the right network,
and for systems programming, that network is not well represented on HN and
Reddit. While these venues are good for marketing, and while the message will
get to some of the most important crowd, it may have a negative effect as it
would attract many that don't _really need_ Rust, and if they end up making up
most of the community, they may slowly push the language in directions that
may make it less appealing to those who really need it.

~~~
nickpsecurity
"I don't think max performance is an issue at all"

I'll consider believing that when you remove both the performance-enhancing
aspects and their marketing from your company's products that appear to target
enterprise space of people using GC's and concurrency. Rust's safety w/out
performance hit affects those two, specific areas. I think they might be
interested.

Not to mention businesses doing analysis they want to happen faster, game
developers, real-time groups wanting _no_ runtime (or close to it), HPC that
definitely cares about max performance, and small (or cloud) companies like
those switching from Python to Go specifically due to lower costs from higher
performance. Maxing performance is always a benefit if you can tell them it
saves time or money but comes with the tools essentially free. That's actually
how a lot of better JVM's (esp AOT) were sold.

"(there are realtime GCs, and GC languages do support arena GC allocation in
embedded and realtime settings, like realtime Java)"

They're not default in these GC languages. We both know about them but most
people don't. I've been telling Java & C# developers about those things for
years with not one ever having heard of it before. Recently explaining to
people that think an OS can't be written in Go that both OS's w/ GC languages
& real-time, concurrent GC's existed. So, in their minds, there's horrid C/C++
w/ no safety, all these languages with GC's that have GC issues, and now a
safe language with no GC. It's a perception thing that gives Rust an advantage
over tech you described.

" but on those for whom the language is indispensable, or tremendously
beneficial."

I'll cede you that. This would almost solely be aimed at the C, C++,
Objective-C, and Fortran crowds. People stuck with caveman tools and unsafety.

"and for systems programming, that network is not well represented on HN and
Reddit."

Definitely true.

"end up making up most of the community, they may slowly push the language in
directions that may make it less appealing to those who really need it."

This is a real risk they should consider more. The best route would probably
be to send people to the sites, conferences, and companies heavily into C and
C++ for many use-cases. Get all this feedback they're getting from them at
least as much as the others if not more. That might inform the language design
in a way that addresses the risk you're bringing up.

~~~
pron
> Rust's safety w/out performance hit affects those two, specific areas. I
> think they might be interested.

:) Let me put it this way: if for some reason Rust ever takes a serious market
share from Java (or other similar languages) in the enterprise space, I will
surely be well into my retirement by then, so my interest isn't financial. I
was a C++ developer for many years, working on very large soft (and some hard)
realtime systems, and I was a Java holdout, but once most of the defense
industry switched, virtually nobody (including us) ever complained about a
performance decrease. So even if the claim that GCs adversely affect
performance in large, complex programs (where RAM overhead isn't an issue)
were true, the number of organizations that build software of that kind and
where this performance would matter more than in defense, is very, very small
(not to mention that most of the current performance deficiencies in Java are
not related to GC). If _that 's_ the kind of user that would be a significant
portion of Rust's userbase, then Rust is in trouble. Companies that sell
ultra-low latency GCs for a fraction of the cost it would take for enterprise
shops to adopt a language like Rust, are, well not exactly on their way to the
Fortune 500. The systems software space -- drivers, kernels, filesystems, and
the entire embedded space -- is at least one, if not two, orders of magnitude
bigger.

~~~
nickpsecurity
I wasn't saying you were shilling to dodge competition so much as better
performance is in your marketing material like many others. ;) I agree that a
lot of the space they should be targeting won't have a humongous difference
between a well-tuned GC and a typical, native implementation. You're right on
that.

"Companies that sell ultra-low latency GCs for a fraction of the cost it would
take for enterprise shops to adopt a language like Rust, are, well not exactly
on their way to the Fortune 500"

That's a good point. Switching costs would be huge in many of these
organizations. They'll make better inroads with something within their
existing stack (typical) or doing new projects in the improved language (also
typical). They're not rewriting all that stuff, though.

~~~
jjnoakes
With rust you don't need to rewrite though. Just integrate it a little at a
time.

~~~
nickpsecurity
Hopefully. With the legacy codebases or preferences, that means hiring people
that really know C or C++, training them for Rust, and maintaining two
codebases in one. It becomes trickier. Hopefully the incremental option works
well for Rust but it didn't with most languages & platforms.

------
djsumdog
This is a little off topic, but when I looked at his post I thought, "Wait ..
is that LiveJournel?" .. and yes it is apparently. Or at least a fork of it
called DreamWidth.

Interesting to see forks of older OSS Perl web apps still in use today.

~~~
xb95
Caveat lector: I'm one of the two founders of Dreamwidth.

Yes! Dreamwidth is a fork of the old LiveJournal code that is still being
developed by a small team of folks who would rather see a small site run in an
open, transparent fashion than be beholden to large corporate interests and
the whims of monetization.

We're a very happy little family and it's always exciting to see Dreamwidth
links end up on HN. :)

------
orblivion
I haven't used Rust, but generally speaking wouldn't you say that safety in
some sense includes the other nice features? For instance, if it were safe but
not fast (like, say, a GC language) it wouldn't be useful. So it has to be
safe and fast (which it sounds to me like it is). Okay, so what if it were
safe, fast, but a real hassle to use? Well that's not very useful either. So
it has to be safe, fast, and usable. Just like Moxie's approach to security:
focus on usability, so people actually use the damn thing. And it sounds like
all the other nice features make Rust more usable.

------
luckydude
"Our engineering discipline has this dirty secret, but it is not so secret
anymore: every day the world stumbles forward on creaky, malfunctioning,
vulnerable, error-prone systems software and every day the toll in human
misery increases. Billions of dollars, countless lives lost."

Billions of dollars and countless lives lost? I'm not saying that buffer
overruns aren't a thing but this seems like marketing claims without
substance. Yes, I read through the examples below, still think he's
overstating it.

------
kebolio
> [Go] failed to provide a safe concurrency model.

What did he mean by this?

~~~
nothrabannosir
Go doesn't protect you against race conditions, it merely offers some
concurrency tools. There is nothing to declare ownership of objects in memory.
So the compiler doesn't (can't) complain if you share memory and access it
simultaneously. At best, there are runtime checks. Rust does offer compiler
protection against that.

Edit: "merely", relatively to Rust :) on an absolute scale, still way better
than C for concurrency.

~~~
VexorLoophole
As a total beginner (learning programming by myself since 2 or 3 years), i am
always asking myself, how often "little" things like race conditions break
something in production. Sure thing, some applications need to be safe-super-
safe. But is it worth to switch over from go to rust as a beginner, since go
is the unsafer language? I know, that there is no ultimate language. But i
always asked myself i am missing a point, since i never really had problems
like that occur. I also wrote something little in clojure (wanted to write
something in lisp, and clojure presented itself somehow modern). But many
people told me about how bad clojure is, because it is not type-safe. So i
switched to go. And i have to say, it is really nice, to be forced to use the
right types as input. But will i have the same experience when i switch over
to rust and think to myself: "Whoa yes, i never though about that aspect, but
it really helps me as a beginner who tends to write slobby programms!"?

~~~
camus2
> i am always asking myself, how often "little" things like race conditions
> break something in production

It can basically corrupt the whole program.

I bet half go apps out there have data race. People who boast about Go's
simplicity can't even see the elephant in the room. A simplistic type system
doesn't fix unsafe concurrency. You'd think that safe concurrency would be an
important design goal for a highly concurrent language, well apparently it
isn't.

~~~
moomin
Speaking as an experienced programmer: all the time, in subtle ways, sometimes
that you don't notice for a long time. Sometime benign, sometimes your data
has been being corrupted for months before you notice.

My standard advice on concurrency is, quite simply, don't. It always looks way
simpler than it actually is. If you're doing something that _requires_ it, get
all the help you can. Type-level enforcement sounds _excellent_ to me.

~~~
macintux
If you want to avoid data corruption in concurrent software, there's always
Erlang as an option.

~~~
pimeys
I haven't checked Erlang too well, but is it so that the concurrency in Erlang
software is basically actors only? Of course in this space you can also use
Akka and even Rust and C++ have actor libraries available.

But there are definitely use cases where you don't want to use actors, where
you might want to compose several futures together without the overhead of
actor mailboxes.

~~~
masklinn
> it so that the concurrency in Erlang software is basically actors only?

Erlang's concurrency is "don't communicate by sharing, share by communicating"
enforced at the language level: an Erlang system is composed of _processes_
which each have their own heap (and stack) and an incoming "mailbox", an
Erlang process can only interact with the world by calling BIFs (built-in
"native" functions, Erlang syscalls if you will) or sending messages to other
processes, and messages can only contain immutable data structures (mutation
happens only at the process level).

Of course one of the sources for this design is that Erlang comes from a world
where 1 = 0 (if you don't have redundancy you don't have a system) thus two
processes may live on different nodes (erlang VMs) on different physical
machines and shouldn't behave any differently than if they were on the same
node.

~~~
pimeys
So basically it's like Scala/Akka, except in Erlang you can send functions
which is a nice feature. One thing that has kept me from using it in
production is its dynamic typing. Once you've been spoiled with a good type
system, it's quite hard to go back to dynamic typing.

~~~
macintux
Akka is modeled on Erlang but the JVM has very different characteristics. The
Erlang VM is optimized for immutable languages and message passing. GC is very
different (almost a non-issue) because of the process model.

And pattern matching in Erlang is a joy every developer should experience.
I've not been impressed with my limited exposure to Scala, which also bears
the burden of trying to be a kitchen sink language.

------
maxpert
I have been anxious about using Rust as webserver. But so far there is no
mature framework that I think can use. I had a look at few like mio and iron
framework etc. It has no mature Websocket implementation or an http package
mature enough to be used in production. I am looking forward to make an ultra
efficient PubSub server that supports HTTP poll and Websockets. Hope my dream
comes true :)

~~~
steveklabnik
Expect lots of movement in this space, with tokio coming out with an initial
release soon!

------
agumonkey
I think that safety is often doing small things clearly. When you read about
thread safe computing, you end up with many rules FP make impossible. So even
it's mostly safety, it encompasses a larger area in disguise.

------
mtgx
Even if Rust adds increasingly more "unsafe" features in order to appeal to
new developer groups, I agree that it should remain a "100% safe by default
language", and they should continuously try to improve the performance of the
safe code, rather than get lazy and say developers can just use the unsafe
syntax if they want 3x the performance. This would only lead more and more
developers to increase the usage of unsafe code. It would be even worse if
Rust would allow unsafe code by default for any future feature.

~~~
steveklabnik
There is no serious proposal to make anything unsafe by default, and I wasn't
proposing we do such a thing. The change I'm talking about is how we talk
about Rust, not making changes to the language at all.

------
w8rbt
How is Rust better than and different from D?

    
    
        https://dlang.org/
    

Does anyone concerned about security use D?

~~~
computerphage
There are a lot of reasons. There's a terrific in-depth discussion of D on the
Rust subreddit from a few weeks ago.
[https://www.reddit.com/r/rust/comments/5h0s2n/what_made_rust...](https://www.reddit.com/r/rust/comments/5h0s2n/what_made_rust_more_popular_than_d/)

------
keldaris
As someone looking at this influx of discussion from the point of view of a
curious bystander, I can't help but be annoyed by two persistent
misconceptions that keep being perpetuated in many statements of this kind.

1) Memory safety is or should be a top priority for all software everywhere.
The OP goes so far as to state: "When someone says they "don't have safety
problems" in C++, I am astonished: a statement that must be made in ignorance,
if not outright negligence."

This is borderline offensive nonsense. There are plenty of areas in software
design where memory safety is either a peripheral concern or wholly irrelevant
- numerical simulations (where crashes are preferable to recoverable errors
and performance is the chief concern), games and other examples abound. It's
perfectly true that memory safety issues have plagued security software, low
level system utilities and other software, it's true that Rust offers a
promising approach to tackle many of these issues at compile time and that
this is an important and likely underappreciated advantage for many usecases.
There's no need to resort to blatant hyperbole and accusations of negligence
against those who find C++ and other languages perfectly adequate for their
needs and don't see memory safety as the overriding priority everywhere.
Resorting to such tactics isn't just a bad PR move, it actively prevents
people from noticing the very real and interesting technical properties that
Rust has that have little to do with memory safety.

2) Rust is just as fast or faster than C++.

Rust is certainly much closer to C++ in performance than to most higher level
interpreted languages for most usecases and is often (perhaps even usually)
fast enough. Leave it at that. From the point of view of high performance
programming, Rust isn't anywhere close to C++ for CPU-bound numerical work.
For instance, it does not do tail call optimizations, has no support for
explicit vectorization (I understand that's forthcoming), no equivalent to
-ffast-math (thereby limiting automatic vectorization, use of FMA instructions
in all but the most trivial cases, etc.), no support for custom allocators and
so on. I'm also not sure if it's possible to do the equivalent of an OpenMP
parallel-for on an array without extra runtime overhead (compared to C/C++)
without resorting to unsafe code, perhaps someone can correct me if it's
doable.

Over the past week or so, motivated largely by a number of more insightful
comments here on HN from the Rust userbase, I've tried out Rust for the first
time, and found it to be quite an interesting language. The traits system
faciliates simple, modular design and makes it easy to do static dispatch
without resorting to CRTP-like syntactic drudgery. The algebraic/variant types
open up design patterns I hadn't seriously considered before in the context of
performance-sensitive code (variant types feature in other languages, but are
usually expensive or limited in other ways). The tooling is genuinely
excellent (albeit very opinionated) and easily comparable to the best
alternatives in other languages. I'm not yet sure if I have an immediate use
for Rust in my own projects (due to the performance issues listed above and
easier, higher level alternatives in cases where performance is irrelevant),
but I will be closely following the development of Rust and it's definitely on
my shortlist of languages to return to in the future.

However, I would have never discovered any of this had I not objected to the
usual "memory/thread safety" story in a previous HN discussion and received a
number of insightful comments in return. I think focusing on the safety
rationale alone and reiterating the two hyperbolized misconceptions I listed
above does a real disservice to the growth of a very promising language. I
think Steve Klabnik's blog post to which the OP responds is a real step in the
right direction and I hope the community takes it seriously. Personally, I
know a few programmers who've entirely ignored Rust due to the existing
perception ("it's about memory safety and nothing else") and in the future
I'll suggest Rust as worthy of a serious look as an interesting alternative to
the prevailing C++-style designs. I'm certainly glad I tried it.

~~~
dbaupp
Memory safety is important for everything because it is a prerequisite for any
other form of correctness. There's no guarantee that a violation of memory
safety will result in a crash, memory corruption is just as possible,
resulting in a bad numerical computation or a broken game. It may be that the
risk of an actual problematic memory safety violation in numerics/gaming is
small enough to not worry, but it is still something to consider.

The rayon library offers similar functionality to OpenMP, including a parallel
map/reduce (etc) over a vector, all in safe code for the user.

I believe a operations that allow -ffast-math style optimisations were
recently added to the floating-point types, allowing one to specify individual
places where reassociation (etc) is OK. This obviously isn't as automatic as
-ffast-math, but usually one has only a few small kernels where such things
are relevant anyway.

Lastly, two smaller points:

\- C++ doesn't do tail call optimisation just as much as Rust doesn't do it.
Compilers for both _can_ (and do) perform TCO, the languages just don't
guarantee it.

\- C++ doesn't do explicit vectorization either, not in the standard. If
you're willing to move into vendor extensions then nightly Rust seems somewhat
equivalent and does allow for explicit SIMD.

~~~
keldaris
> Memory safety is important for everything because it is a prerequisite for
> any other form of correctness.

That's obviously true, but not what I (or the OP) was talking about. My point
was that in many applications memory safety doesn't rank highly as a separate
concern, in addition to computing correct output from expected input. Because
of this, describing Rust as a language that solely focuses on memory safety
isn't very interesting to large groups of developers that work on such
applications.

> The rayon library offers similar functionality to OpenMP, including a
> parallel map/reduce (etc) over a vector, all in safe code for the user.

I did look at rayon when I skimmed through the available ecosystem. The
runtime cost of that approach wasn't obvious to me from the documentation, and
it doesn't quite let me keep the loop-based control flow usually employed for
numerical calculations (because of the need to refer to different indices
within the loop, etc.), but it's certainly a viable approach. Not a direct
replacement to OpenMP loops, though.

On the subject of -ffast-math, I did not encounter these recent additions you
mention in the language documentation, but I'll take another look on the issue
tracker and elsewhere. Thanks for the information.

On tail call optimisations, I don't believe your statement is entirely
correct. It's true that C++ compilers don't guarantee TCO (although,
empirically they're very good at it), but Rust doesn't seem to be able to do
it at all. It's explicitly stated in the language documentation and there's a
recent issue on the subject [1].

And on explicit vectorization - I'll take a look at the latest nightly Rust
and edit my post accordingly if explicit SIMD is already usable. Glad to hear
it.

FWIW, I think Rust has made great progress considering the age of the
language, and I'm glad to see SIMD and other improvements being implemented.
My objection was simply against the hyperbolic assertion that Rust has already
attained full parity or even superiority over C++ in performance.

By the way, is there a way to turn off runtime bounds checking for vectors?
That's another common performance sink in numeric computing.

[1] [https://github.com/rust-lang/rust/issues/217](https://github.com/rust-
lang/rust/issues/217)

~~~
dbaupp
_> My point was that in many applications memory safety doesn't rank highly as
a separate concern, in addition to computing correct output from expected
input_

Indeed, I was trying to cover that in my comment. I agree that it isn't an
explicit selling point to such people, but I think that it should be:

\- numerics/scientific computing/machine learning are slowly taking over the
world. It is bad to have random/occasional heisenbugs in systems that
influence decisions from the personal to the international.

\- games are very, very often touching the network these days, and thus are at
risk of being exploited by a malicious attacker.

Of course, people in those domains aren't necessarily thinking in those
terms/have deadlines to hit/are happy with their current tooling.

 _> The runtime cost of that approach wasn't obvious to me from the
documentation_

It is low. I've even heard rumours that the core primitive has the _lowest_
overhead of all similar data parallel constructs, including, say, Cilk. This,
combined with aggressive use of "expression templates" (with a special mention
to Rust's easily inlinable closures), means I'd be surprised if rayon was
noticably slower than OpenMP for the straight-forward map/associative-reduce
situations. More exotic transformations are more dubious, given rayon has had
far less person-hours put into it.

 _> it doesn't quite let me keep the loop-based control flow usually employed
for numerical calculations (because of the need to refer to different indices
within the loop, etc.), but it's certainly a viable approach_

I'm not sure loop-based control flow is actually necessary, since (I believe)
one can, say, parallelise over an enumerated iterator (e.g.
slice.iter().enumerate()), which contains the indices. One can then .map() and
read from the appropriate indices as required.

 _> On the subject of -ffast-math, I did not encounter these recent additions
you mention in the language documentation, but I'll take another look on the
issue tracker and elsewhere. Thanks for the information._

To shortcut your search: [https://doc.rust-
lang.org/std/?search=fast](https://doc.rust-lang.org/std/?search=fast) . (I
apologise that I didn't link it earlier, I was on a phone.)

 _> On tail call optimisations, I don't believe your statement is entirely
correct. It's true that C++ compilers don't guarantee TCO (although,
empirically they're very good at it), but Rust doesn't seem to be able to do
it at all. It's explicitly stated in the language documentation and there's a
recent issue on the subject [1]._

I guarantee that rustc _can_ do tail TCO. I've spent a lot of time digging
around in its output. The compiler uses LLVM as a back-end, exactly the same
as a clang, and things like function calls look the same in C++ and in Rust.

That issue is 5 years old, and closed, and is (implicitly) "teach rust to have
away to _guarantee_ TCO", see the mention of 'be' vs. 'ret': they're keywords,
'be' theoretically being used like `be foo(1, 2)` and meaning "this call must
be TCO'd" (i.e. my stack frame must _be_ foo's stack frame).

Lastly, if you're talking about the documentation being [0], I think you're
misreading it, in particular it says:

> Tail-call optimization may be done in limited circumstances, but is not
> guaranteed

That said, it is reasonable that you're misreading it, given "Not generally"
is being technically correct ("rustc cannot do TCO in complete generality",
i.e. there exists at least one tail-call which won't be optimised) in a way
that is confusing in normal English. I personally think it would be better if
it started with "Yes, but it is not a guarantee" rather than "No".

[0]: [https://www.rust-lang.org/en-US/faq.html#does-rust-do-
tail-c...](https://www.rust-lang.org/en-US/faq.html#does-rust-do-tail-call-
optimization)

 _> By the way, is there a way to turn off runtime bounds checking for
vectors? That's another common performance sink in numeric computing._

Yes, the get_unchecked and get_unchecked_mut methods. This takes the same
approach as the -ffast-math equivalents: disable when required, rather than
sacrifice reliability across a whole program. That said, Rust's iterators
(which also power rayon) are more idiomatic than manual indexing, when they
work, and generally avoid unnecessary bounds checks more reliably.

~~~
kibwen
Thanks for this great comment thread, Huon. :) I didn't know we had fastmath
stuff now!

------
amelius
Does Rust have template metaprogramming? And does it look more clean and
organized than boost's C++ implementation?

~~~
steveklabnik
Rust has three main forms of metaprogramming: generics, which are kind of like
templates, but more like concepts (in C++ terms), macros, and compiler
plugins.

~~~
nurettin
Wait, Rust has macros that expand to code and mess up debugging, confuse
tooling and everything else just like C++? Isn't that exactly what the
language should have avoided?

~~~
steveklabnik
They do expand to code. They shouldn't mess up debugging or confuse tooling.
They're much more similar to Lisp-style macros than the C preprocessor.

~~~
nurettin
Oh, ok, the word macro is heavily overloaded and it seems I misinterpreted the
Rust use of macros. But oh boy it costs lots of rep to ask a question.

~~~
kibwen
Trust me, every C and Lisp programmer in the world is upset that both
languages use "macro" to mean such wildly different things. :)

------
raverbashing
Rust is great, however the safety aspect gets in the way sometimes

The right granularity for error handling is important, as well as making it
easy to handle (abort? providing a default value? doing something else?)

It's not that it is not important, but code usability is important as well,
lest it goes on the way of C++ hell (though I don't think it can get that bad,
there are some warts - like "methods" and traits)

~~~
tomjakubowski
> The right granularity for error handling is important, as well as making it
> easy to handle (abort? providing a default value? doing something else?)

Option<T> and Result<T,E> achieve just about the best level of granularity I
could imagine for error handling.

Suppose you're trying to fetch a value from a map (use case for Option<T>), or
read some value over some fallible I/O stream (use case for Result<T,E>).

Want to abort if the value is missing or an error occurred? Just call unwrap()
and ready yourself for (completely safe!) crash reports. unwrap() is just a
way to dynamically assert certain invariants.

Want a default value in those cases? Just call or() or or_else() on the
Option<T> or Result<T,E> value you have.

Want to do something else? Use Rust's pattern matching features and branch
depending on whether the value was obtained, on conditionals relating to the
value (or error), and more!

~~~
curun1r
I can see Option and Result irking people who don't want to embrace a more
functional (programming) mindset. They can be kind of a pain to deal with
procedurally without the and_then, or_else, map and such. The new '?'
construction will definitely help with this.

The appeal of exceptions, to me, has always been that they allow you to
largely separate your error handling from your procedural logic since the
catch block can usually go at the end of the method/function and can usually
be written later. This means you can write and test code and then come back
and handle error conditions after you've gotten the success path working.
Option/Result force you to at least acknowledge the possibility of an error at
the point when you're writing your logic. Whether that's ?/try!, .unwrap(), a
match or writing in a more functional manner, error handling can't literally
be an afterthought the way it is with unchecked exceptions.

I'm not arguing that this is a bad thing, and it may be a push in the right
direction for many programmers. But it's still a push and many don't enjoy
being pushed.

~~~
quotemstr
At least I'm not the only one disappointed in Rust's error handling strategy.
I still firmly believe that exceptions are the best error handling strategy
we've concocted so far and that Rust (and Go) represent a big step backwards
in language design in this respect. It's still hard to get over Rust's default
abort-on-OOM behavior that arises from the awkwardness that would arise from
surfacing the possibility of allocation failure from every part of stdlib.

> the catch block

"The" catch block? For each function? Some people misunderstand exceptions and
think that every function needs a catch block that cleans up resources
allocated in that function. I hope you're not one of these people.

Idiomatic exceptional code has very few catch blocks. That's part of the
appeal.

------
krakensden
What about stack overflows? I heard that rust no longer protects against those
for benchmark reasons.

~~~
steveklabnik
That's incorrect. On some platforms, stack probes are not yet implemented
because the patch to LLVM hasn't been merged, and we need it to do this
properly. Someone is working on getting that through right now.

~~~
brson
And stack probes are one corner case of stack overflow. Rust protects against
stack overflow in most cases, on all platforms, in every case on Windows, and
is intended and designed to protect against all stack overflow, but it has a
bug due to missing features in LLVM that nobody has taken the time to fix.

------
sh_tinh_hair
Safety stopped here: "curl [https://sh.rustup.rs](https://sh.rustup.rs) -sSf |
sh" So did my interest.

~~~
PudgePacket
It's convenient for the majority of people. There are regular downloads
available ([https://www.rust-lang.org/en-US/other-
installers.html](https://www.rust-lang.org/en-US/other-installers.html)) and
you can probably also get Rust through your system package manager.

~~~
nnethercote
"I trust your binaries but I don't trust your shell script for installing
those binaries."

------
sh_tinh_hair
io::stdin().read_line(&mut guess).expect("failed to read line");

My eyes have seen the glory of RUST, it's really javascript, right?

------
Thaxll
The daily post about Rust and Go is getting tiresome... every single day we've
got one.

~~~
AsyncAwait
I read them all, you don't have to - just scroll by. I for example don't like
the 'daily' snake oil salesman type of posts that pop up here, so I just skip
them - easy.

------
StevePerkins
> " _Safety in the systems space is Rust 's raison d'être._"

I think this quote points to the REAL underlying issue here.

Rust is a language primarily built for systems programming. It has many
strengths to celebrate, and brings curated best practices as well as its own
novel features to systems programming.

However, most programmers in 2016 aren't "systems programmers" anymore. At the
very least, most programmers _who actively talk-up new technologies on web
forums_ are not systems programmers. The majority (or at least the majority of
the vocal and socially engaged) are web developers, mobile developers, CRUD
apps and microservices, etc.

As interesting as Rust may be in the systems space, it doesn't bring much
compelling new hype to the table for web stuff.

You have yet-another-concurrency-approach? That's great, but most web
developers rely on an app server or low-level library for that, and seldom
have to think about concurrency up at the level of their own code.

You have an approach for memory safety without a garbage collector? That's
great, but most web developers have never even had to think much about garbage
collection. Java, Go, etc... the garbage collection performance of all these
languages is on a level that makes this a moot point 99.999% of the time.

You have a seamless FFI for integrating with C code? That's great, but after
20 years of web development I can count on one hand the number of times I've
seen a project do this. And those examples were Perl-based CGI apps way back
in the day.

Rust people seem almost dumbfounded that everyone hasn't jumped all over their
language yet. And from a systems programmer perspective, memory safety without
garbage collection does sound amazing. But you guys really need to understand
that Hacker News and Reddit hype is driven by web developers, and that
community isn't even sure whether or not _type safety_ is a worthwhile
feature! So really, it's amazing that you've managed to draw as much hype as
you have. It's not about the mainstream popularity of your language, it's
about the mainstream popularity of your _field_.

~~~
lobster_johnson
The way the industry is moving, it seems that:

(1) Web apps are increasingly being split into a separation between
presentation-only frontends + multiple "purely API-oriented" backends;

(2) There is a trend towards static typing in webapps.

We're currently using Go (plus some legacy Ruby apps we haven't rewritten yet)
to implement microservice backends that serve APIs, and the frontend is all
client-side JavaScript using React. (We also use Node.js to do server-side
rendering of static HTML for Googlebot, but for a typical visitor, all the
magic happens in the browser.)

For us, Go works well, and the compilation and static typing is a much-
appreciated safety net compared to the everything-goes world of Ruby, not to
mention much better performance and memory usage (one app is went from being
multiple Unicorn processes consuming 2GB RAM in total, down to a single
process using ~60MB and a fraction of the CPU usage).

But this isn't "systems programming" at all, and yet for me, Rust is very much
on the table as a possible next language. I'm not sure if its complexity is
large enough of a hindrance yet. Go is already a challenge for junior
programmers who are used to dynamically typed languages, Rust much more so.
I'd love to be able hire all seniors, but all the hot startups are taking
them. (Though in that sense, Rust may even serve as a good carrot.)

As for static typing on the web side, TypeScript — which is essentially static
typing for JS — is also most definitively in our future. The last year or so,
Microsoft has made it easier to work with a mix of legacy JS and TS, so you no
longer have to convert the entire codebase to migrate, which is great.

I don't think every company is going to move away from their classical Rails
or PHP stack, of course, but there's definitely a trend, and I can imagine
Rust becoming a popular alternative to the other statically-typed languages,
including Scala and Java.

------
jinmingjian
The memory safety of Rust is over consumed.

1\. several small languages also introduce the type system to try to solve the
memory safety problem. But all of them are less famous. Because there are many
reasons that makes a language being accepted massively from other tons.

2\. in many cases, it is not hard to do manual memory management. There are
many great software done with manual memory management. Although I admit the
quest to memory management is always wonderful for system. But go to the
follow #3.

3\. linear/affine type system[1] is not the panacea. The case of "used exactly
once" is just a small case. Forcely to this pattern makes large boilerplates.
And constraints and verifications to system can not be done many levels and
aspects. Is this truly valuable to add all into type system?

4\. memory safety of Rust comes with price, which have added many complexities
and language burdens to itself. Who like to read the following function
declaration?(just borrowed as example):

fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str

5\. So, finally, the question arises: does the current form of the memory
safety of Rust deserve as the hope of next industry language? I'm afraid...

[1]
[https://en.wikipedia.org/wiki/Substructural_type_system](https://en.wikipedia.org/wiki/Substructural_type_system)

~~~
Retra
>Who like to read the following function declaration?(just borrowed as
example):

> fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str

Anybody who cares about the validity of pointers would like to read that. It
very explicitly tells you what must be true of the arguments for them to be
valid and for how long the result will be valid.

In general, you seem to be over-valuing conciseness. If you think conciseness
is more important than memory safety, feel free to not use Rust. But frankly,
it is trivial to make a language more concise. That's not a hard problem
whatsoever.

