Rust is mostly safety - <AUTHOR> http://graydon2.dreamwidth.org/247406.html <comment><USER2> 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.

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

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

<comment><USER5> 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... :)

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

</comment></comment></comment></comment></comment><comment><USER6> 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.)

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

<comment><USER8> _> 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.

<comment><USER7> > > 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).

<comment><USER8> _> 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.

<comment><USER9> The guy's a troll.

</comment></comment></comment></comment></comment></comment><comment><USER10> 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/)

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

<comment><USER10> I really, really like this. Thank you. Well put.

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

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

<comment><USER13> > 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).

<comment><USER12> Ah, that was my understanding.

</comment></comment></comment></comment><comment><USER14> 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.

<comment><USER15> Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production

<comment><USER10> 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)

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

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

<comment><USER7> 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...)

<comment><USER17> 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)

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

<comment><USER9> He didn't misrepresent anything. You're the one doing all the misrepresenting, exaggerating, and being obnoxious.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> 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.

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

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

</comment></comment></comment><comment><USER21> 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.

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

<comment><USER22> 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.)

<comment><USER23> 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 :)

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

<comment><USER23> 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!

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

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

<comment><USER22> _" 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?

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

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> 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. :)

</comment><comment><USER26> 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.

<comment><USER27> > 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_.

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

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

</comment></comment></comment></comment><comment><USER28> 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.

<comment><USER30> I'm a polyglot programmer and for me Rust is mostly about the awesome abstractions and the great community.

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

;)

</comment></comment></comment><comment><USER31> _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.)

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

<comment><USER31> _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?

</comment></comment></comment><comment><USER15> 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.

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

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

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

<comment><USER36> If only Go was useful in building closed source products. Google must not have gotten the memo about Rust yet.

<comment><USER37> 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).

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> > 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?"

<comment><USER39> TDD: "If you're not doing this, you're not a real engineer."

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

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

</comment></comment></comment><comment><USER12> > 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.

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

<comment><USER41> 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)

<comment><USER12> ParaSail development looks stalled since its main designer joined AdaCore.

Just my impression, anyone feel free to correct me.

</comment></comment></comment></comment><comment><USER42> 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)

</comment><comment><USER43> 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.

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

</comment></comment><comment> 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.).

</comment><comment><USER45> It's a shame there is no mention of ATS, which also attempts safe systems programming usings an advanced type system.

</comment><comment><USER46> 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.

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

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

</comment></comment></comment><comment><USER48> 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)

<comment><USER41> "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.

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

<comment><USER41> "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.

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

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

<comment><USER49> With rust you don't need to rewrite though. Just integrate it a little at a time.

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER50> 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.

<comment><USER51> 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. :)

</comment></comment><comment><USER52> 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.

</comment><comment><USER53> "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.

</comment><comment><USER54> > [Go] failed to provide a safe concurrency model.

What did he mean by this?

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

<comment><USER56> 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!"?

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

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

<comment><USER59> If you want to avoid data corruption in concurrent software, there's always Erlang as an option.

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER62> 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 :)

<comment><USER10> Expect lots of movement in this space, with tokio coming out with an initial release soon!

</comment></comment><comment><USER63> 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.

</comment><comment><USER64> 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.

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

</comment></comment><comment><USER65> How is Rust better than and different from D?

        https://dlang.org/

Does anyone concerned about security use D?

<comment><USER66> 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/)

</comment></comment><comment><USER67> 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.

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

<comment><USER67> > 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)

<comment><USER68> _> 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.

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

</comment></comment></comment></comment></comment><comment><USER69> Does Rust have template metaprogramming? And does it look more clean and organized than boost's C++ implementation?

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

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

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

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

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

</comment></comment></comment></comment></comment></comment><comment><USER71> 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)

<comment><USER17> > 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!

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

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

</comment></comment></comment></comment><comment><USER74> What about stack overflows? I heard that rust no longer protects against those for benchmark reasons.

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

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

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

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

<comment><USER16> "I trust your binaries but I don't trust your shell script for installing those binaries."

</comment></comment></comment><comment><USER76> io::stdin().read_line(&mut guess).expect("failed to read line");

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

</comment><comment><USER78> The daily post about Rust and Go is getting tiresome... every single day we've got one.

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

</comment></comment><comment><USER80> > " _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_.

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

</comment></comment><comment><USER82> 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)

<comment><USER83> >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.</comment></comment>


The Hustle – Productivity Tool for 9-5 Job Side Hustlers - <AUTHOR> https://thehustle.app/ <comment><AUTHOR> Hi Hackernews

my name is Viet and I made TheHustle app, a productivity tool for individuals working 9-5 jobs with entrepreneurial spirit while having short attention span and horrible memory :).

I know hackernews folks are more interested in tech than story behind, so let's share my tech stack first :)

TheHustle was made as React JS SPA with Django backend, while running on VPS.

Now the story:)

Is it possible to side hustle with a day job?

After 5 years in the corporate world working 9-5, I have always dreamed about starting a side project.

Having limited time in the evenings and weekends, I started to learn how to code from scratch. But I never managed to finish and launch any of the prototypes. I always gave up midway, due to burnout, laziness, and procrastination.

The day was just not long enough and exhaustion from 9-5 job hindered my progress.

Then I developed my own methodology on how to finish impossible goals while working 9-5. I started to treat my free time as an investment.

The only thing missing was an app, that would help me to keep my productivity methodology consistent.

For that reason, I decided to make my own productivity tool.

After a year and half, I finished the app and I am happy to share TheHustle app with you.

What makes TheHustle great for 9-5 side entrepreneurs 1⃣ big focus on the precious free time after an exhausting day at 9-5 job 2⃣ flexible goal tracking with the possibility to create tasks and subtasks 3⃣ track time spent on each task 4⃣ see how well you invested your free time 5⃣ motivate yourself by following others

Thanks to TheHustle app, I managed to finish and launch TheHustle, while working 9-5.

Also I have a special promo offer for you. Use code producthunt2020 and get free account forever if you side hustle every day for 14 days straight. Everyday you must log an activity so the offer applies.

Check it out, and leave a comment below.</comment>


Extending the Revealing Module Pattern – Why is this a bad idea? - <AUTHOR> http://invalid-arg.github.io/2013/04/13/extending-the-revealing-module-pattern.html

<comment><USER2> The revealing module pattern is an antipattern. Instead, just document which of your methods are private or protected,

      /** @private */
      MyClass.prototype.foo_ = function() {}

<comment><USER3> I have to agree with you, if nothing else because existing debugging tools just aren't very good at dealing with the privacy-through-closures pattern. In many cases, it's essentially impossible to inspect the state of a variable that is made private this way, and it's not clear how you would even design a debugger that gave a reasonable interface for doing so.

<comment><USER4> Its annoying, but certainly possible to inspect the state of a local variable inside of a closure. Set a breakpoint inside of one of the exported functions, call it, and you have access to all the local variables within the closure.

I do dislike this pattern as I find the code is less structured, harder to debug, and less performant than attaching functions on the prototype. This outweighs the benefits of encapsulation to me.

<comment><USER5> I have never, ever come across a scenario where assigning to the object instead of the prototype has made any meaningful impact on performance.

The only scenario I can even think of where it would maybe possibly matter would be a tight loop where you are doing little else except just accessing properties.

<comment><USER4> I can imagine it having an impact on a graphics app where a `Point` class might be instantiated thousands of times, or even if the Backbone.Model constructor were hundreds of lines long to attach all the public methods. It would be weird to me to have to spend a few seconds of thought on a per-object basis to think how I should structure the code based on how often I think it will be instantiated.

But yes, I also have not been bitten by this. Its just something I've read about how the v8 engine works (and makes sense intuitively). I agree you shouldn't base coding style decisions soley on hearing one way is faster, but I think its a minor point and worth noting.

Edit: a link! <https://news.ycombinator.com/item?id=2991904>

</comment></comment></comment></comment></comment><comment><USER6> I do understand the difficulty of testing private code in tools like jasmine when you use private variables based on publicly unreachable scopes. When I have to do this, I add a debug object with references to the code. Generally, this code should affect publicly accessible methods and those are more important to test. If they fail, decent in-browser tools like breakpoints and watch lists should reveal the error.

I'm not completely ready to call this an anti-pattern. There's no reason to expose local methods of an Object to the parent scope if they aren't needed. I'm sure that in some cases this could cause the memory footprint of an Object to be larger than desired by preventing garbage collection. Anyway, I would have factored your code more like this:

      var PseudoClass = function(_args){
          // guarantee that "this" is what we expect
          if( this === window ){ // use global for non-browser    implementations
             return new PseudoClass(_args);
          }
          // private variables are local
          var private = function() {;
                 this.value = 2;
              };
          // public variables are on prototype
          this.constructor.prototype.value = 1; // I'd prolly use a local var and a getter for this
          this.constructor.prototype.public = function(){
              private.call(this); // force scope for private methods
          };
          // testing access (only added when necessary)
          this.constructor.prototype.privateMembers = {
              "private":function(){ private.call(this) }
          };
        };

There's no "self" here, but there are two pieces of insurance around scope. First is the condition that forces the "new" keyword. (This could be written to test against instanceof the function name, but generally problems occur when users forget new, not when they force the scope to be wrong. Last I checked, this is how jQuery tests it too.) Second is calling the private methods with the call() method of the function, allowing us to keep the scope from defaulting to global/window. Sure, you are forced to put these in to avoid errors, but this is programming. If you would like it to throw an error when this === window within private(), just add it. I didn't because a) I'm lazy and b) once the PseudoClass private methods are all called, I would end up removing the un-thrown errors and the privateMembers property before compressing for staging/production to keep size down.

Using a variable like "self" is quite clear in this context and I've seen it done thousands of times. I just wanted to show that using "this" is still possible.

Javascript is a funny language. I often find myself wondering if this was the intended structure of the language as it takes advantage of many of the key elements (closure scopes & prototype) while abstractly appearing like simple Java (or C#). Sure in a perfect world, the wrangling of "this" wouldn't need to be done. I'd say the unpredictable value of "this" in different contexts is the biggest fail of Javascript. I programmed ActionScript (including AS1) for many years and this (pun intended) is the biggest mindf*ck I've come across when regarding them in comparison (considering they're both based on ECMA script). Hope there was something helpful to you in this.

</comment><comment><USER7> The pattern also seems like it would be an impediment to performance. The JIT would have to do a lot more work to optimize the function, as well as parse code that isn't really required. So even if the end-result machine code after JIT was performed was the same, the compiler itself would have a much harder time getting there. This can be an issue on mobile devices that are CPU constrained where you want the page to load as fast as possible.

</comment><comment><USER5> I don't really see the need for the extend at all. In fact if you don't use it, it will work the same as example 1 and you'll still have access to self.

Or you can just do this.foo = foo; this.value = value; at the end instead of returning an Object.

<comment><USER8> Yes extend is unnecessary in this case. The key was saving a reference to self.

</comment></comment><comment><USER9> The problem is the foo function not being apart of the returned object. Something like this is a very easy solution without the need to use call/apply/jquery.extend

<http://jsfiddle.net/ABD3C/>

</comment><comment><USER10> I don't see why this is "bad" other than depending on jQuery to do something not directly related the browser. That could easily be fixed by swapping jQuery out for Underscore, since it would then work in browser and in Node.</comment>


The OpenSSD Project (2011) - <AUTHOR> http://www.openssd-project.org/wiki/The_OpenSSD_Project <comment><USER2> A bit from Libreboot that is relevant: [https://libreboot.org/faq/#firmware- hddssd](https://libreboot.org/faq/#firmware-hddssd)

> HDDs and SSDs are quite complex, and these days contain quite complex > hardware which is even capable of running an entire operating system (by > this, we mean that the drive itself is capable of running its own embedded > OS), even GNU/Linux or BusyBox/Linux. Some proof of concepts have been > demonstrated.

> For HDDs: > [https://spritesmods.com/?art=hddhack&page=1](https://spritesmods.com/?art=hddhack&page=1)

> For SSDs: > [http://www.bunniestudios.com/blog/?p=3554](http://www.bunniestudios.com/blog/?p=3554)

</comment><comment><USER3> Kinda related, the complexity of a basic SD card is insane. They have full 32-bit micro-controllers for data handling:

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

Not anywhere near as complex as a full SSD, but still very interesting if you're into storage technology.

<comment><USER4> Thanks, fantastic talk. I never knew. Well actually, not far off the complexity of an SSD: apparently SD cards even use wear levelling algorithms, and so forth, and some SD cards have ARM microcontrollers.

</comment></comment><comment><USER5> I have been involved with SSD development for many years. The thing is flash memory is no longer a near ideal memory device like RAM. You start to see a lot of the physics behind how the transistors behave and interact. The companies spend lots of time and money characterizing them and developing algorithms that are trade secrets. You may figure it out yourself but by that time that part is already EOL. And if you don't do it right your SSD will be unreliable.

<comment><USER6> Can you explain what you mean by "no longer a near ideal memory device." Was it at one time?

I realize the page hans't been updated in a while but there are references to NVMe on it so it can't be _that_ old no?

<comment><USER5> Typing from phone so being brief for now. One time you could write NAND flash pages and have no read errors for months on end. No longer the case now. You need massive amounts of hardware error correction. You have to worry about adjacent cell interactions. You have to use signal processing to read degraded bits. Then there are weird eratta that will not be disclosed to you unless you have an NDA and beg to them. This is just a few things that come to mind but there are tons more.

</comment></comment></comment><comment><USER7> A more actively-developed framework is LightNVM for Open-Channel SSDs. The kernel bits have been upstreamed into mainline kernel as well: [http://lightnvm.io/](http://lightnvm.io/)

I met the project architects at a conference earlier this year, and they are on the right track IMO. If only more vendors would support the notion of open- channel SSDs which allow for custom FTLs from outside the device.

Also, per the LightNVM supported hardware list:

"Other platform such as OpenSSD Jasmine and OpenSSD Cosmos are able to support LightNVM. However, there are no compatible firmwares yet."

</comment><comment><USER8> This has been around for a couple of years and the wiki is kind of dead, as seems to be most of the project looking at the activity around it? This probably warrants a (2011) update to the title as it seems that's when this project was truly active.

</comment><comment><USER9> Is it possible to buy a reference board like the one described in [http://www.openssd- project.org/wiki/Jasmine_OpenSSD_Platform](http://www.openssd- project.org/wiki/Jasmine_OpenSSD_Platform)

<comment><USER10> Surprisingly, it looks like you might be able to:

[http://crz-mart.com/shop/shopdetail.html?branduid=1914659&xc...](http://crz- mart.com/shop/shopdetail.html?branduid=1914659&xcode=003&mcode=002&scode=&type=X&sort=order&cur_code=003002&GfDT=bmp6W1w%3D)

The price is equivalent to about $2000 USD, though, and the controller is completely obsolete nowadays. (I'd be surprised if the Barefoot controller is still in production; it's SATA2 only, and OCZ - parent company of Indilinx - went bankrupt in 2014.)

<comment><USER11> OCZ was for the most part bought by Toshiba.

I'm not sure how public this is, but there were many more Barefoot controllers made and tested and a number of the later-generation OCZ drives were based on a much newer Barefoot-based controller.

<comment><USER12> I think the later Barefoot controllers were public enough, with the two different speed grades of Barefoot 3 being used in the OCZ Arc 100 and Vector 180 (which still exists as the VT180): [http://www.anandtech.com/show/9009/ocz- vector-180-240gb-480g...](http://www.anandtech.com/show/9009/ocz- vector-180-240gb-480gb-960gb-ssd-review)

But it's a dead end and last I heard Toshiba doesn't plan on doing another revision of the silicon to update it with anything like support for SATA link power saving modes.

</comment></comment></comment></comment><comment><USER13> SR-IOV support [0] ?

[0] [https://en.wikipedia.org/wiki/Single- root_input/output_virtu...](https://en.wikipedia.org/wiki/Single- root_input/output_virtualization)

</comment><comment><USER14> Only me read it as openbsd project and thought, eee, where is (1996) about first homepage dig up from archives ?

</comment><comment><USER15> This could be a nice tool for prototyping disk cryptosystems or accelerators for databases.</comment>