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.

The importance of Rust is that it's raised the baseline for low-level languages in the modern age. If any future systems languages emerge that don't feature memory safety, it will have to be a deliberate choice that must be defended rather than just an implicit assumption of how the world works.

With that said, can you recommend a good source to really understand best practices and patterns for ownership and borrowing? I feel that's the biggest hurdle to using Rust (at least in my case).

The rise of "it demos well so we should use it" is in a lot of ways troubling. The inflection point for productivity doesn't need to be "five minutes in" to be worthwhile if you're doing something that is, itself, worthwhile.

How about http://rust-lang.github.io/book/ ?

Mostly I think that the fear of the borrow checker has become more meme than truth at this point. The difficulty with Rust is that it has things found in different languages, so no matter who you are you probably have to learn something: a strong type system and unique ownership and pointers, and if you're coming from a language like Python and Javascript you may know none of this! But that's what we're here for (that's where I came from!), and we like to help. :)

As someone who has yet to do more than do minimal dabbling in the language, this is a very positive message. It expresses that there is some work to learning this so don't be put off if you experience it, it's normal, and that the work required to learn it pays off in the end.

That's probably a more appropriate message than that it's not hard. I don't think it's appropriate to express to people that learning pointers in C and C++ is "easy". It's not "hard", but it's not necessarily easy for some people. It requires a specific mental model, and depending on how they learned to program, it may be more or less easy for them to wrap their head around. Afterwards, it's easy and makes sense. I assume the borrow checker follows a similar learning hurdle. That doesn't mean we should forget what it's like before we've learned it though (and at this point, there's probably a lot of people in the midst of learning rust that haven't quite fully internalized the borrow checker).

That said, I still occasionally have problems where I feel like I'm doing something "dirty" or "hacky" just to satisfy the borrow checker. It's easy to program yourself into a corner and then find yourself calling `clone()` (the situation, I've been told, has gotten much better in recent releases with improvements to the borrow checker, but alas I haven't had a chance to play much with Rust in nearly a year).

Another thing that I still find difficult is dealing with multiple lifetimes in structs, to the point that I usually just say "to hell with it" and wrap everything in an `Rc<T>`. And sometimes there's simply no safe way (afaict) to do some mutation that I want to do without risking a panic at runtime (typically involving a mutable borrow and a recursive call), which leads to a deep re-thinking of some algorithm I'm trying to implement. That's not Rust's fault, though—it's a real, theoretical problem that arises in the face of mutation. In time, I'm sure there will be well-understood patterns for handling such cases.

If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature.

But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tasks, but it needs more than that to be on-par with the other languages. And Rust's got plenty of things going for it, so there's nothing wrong with stopping to play the safety card (since that is expected anyways) and painting Rust as a language that is actually fun to work with.

How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala).

What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this space and GC based languages are just more elegant and not to mention the tooling is way more mature. Runtime also doesn't matter that much and with the recent changes to .NET can be avoided anyway.

This Rust fanboyism is turning in to the new node hype "use node for everything node is web scale fast because it uses an event loop io instead of thread based io", "use rust for everything because the type safety is literally the best and it's the only language with a strong type system out there". I get it it's new and shiny, I like it to, and it has a strong argument to make in the systems programming - the designers are doing a good job of making trade offs that let you retain low level control while still having memory safety - but these tradeoffs are just that and they come at the expense of higher level stuff, higher level languages don't need to make these because they don't pretend to be systems programming languages.

I have to agree that the "Rust all the things!" game is getting old.

I've got Clojure/Clojurescript, Rust, Python, HTML5 JavaScript, F#/C# and Java.

Clojure/Clojurescript is used for long running processes and web development. So backend/frontend stuff. I also use it for fun experiments, the REPL is great at that.

Rust is used when performance matters, when I want the simplicity of running a native executable with no heavy dependency, and when I need to write low level components.

Python is my goto scripting language for quick scripts, hacks, messing around. It also serves my scientific computing needs, data mining, visualization, etc. Also, this is the best language I've found for doing coding interviews or practice. So easy to whiteboard python.

HTML5 JavaScript is used for most web development, for customizing my editor Atom.io, and other things. With Metro apps, and other OS moving towards an HTML5 JavaScript stack, its also quite good at some user apps.

F# is good for simply knowing an ML language and when I want more functional flair in the .Net world.

C# and Java are used to pay the bills, as they are easiest to find jobs for.

There would be valid alternatives for most of those categories, but I highly recommend everyone invest in knowing one language for each one.

I haven't switched to Rust yet (I still deal with C/C++ at work on "legacy" code, and I'm having too much fun with Lua for my own stuff) but I don't expect to pick it up "quickly" and I'm sure I'll be trying to write C in Rust for some time. It comes with the territory.

If what you are suggesting is true, isn't the biggest problem by far the fanboyism posing as knowledge? Wouldn't complaining about Rust be like living in the age of alchemy, and complaining about someone's particular potion? Isn't the epistemological squishyness of the entire field the biggest problem by far?

I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years to come if ever there.

-----

Let's say I want to build a piece of software that depends on some software library written in C at version 1.0.1. It's distributed through my system package manager, so I sudo apt-get install libfoo.

~~ some time later ~~

Now let's say I want to build a different piece of software that also depends on foo, but at version 1.2.4. I notice that libfoo is already installed on my system, but the build fails. After a quick sudo apt-get install --only-upgrade libfoo. This piece of software now builds.

~~ Even later ~~

When I revisit the first project to rebuild it, the build fails, because this project hasn't been updated to use the newer version yet.

I'm fairly inexperienced with system package managers, but this is the wall I always hit. How should I proceed?

Anyway, Debian/Ubuntu has multiple fallbacks for this situation:

a. ppa's

b. parallel versions for libraries that break API compatibility (libfoo-1.0...deb, libfoo-1.2...deb that can coexist).

c. install non-current libfoo to ~/lib, and point one package at it (not really debian-specific)

d. debootstrap (install a chroot as a last resort -- this is better than "versioning packages per-project" from an upgrade / security update point of view, but worse from a usability perspective -- you need to manage chroots / dockers / etc).

I suspect the per-project versioning system is doing b or d under the hood. b is clearly preferable, but hard to get right, so you get stuff like python virtual environments, which do d, and are a reliability nightmare (I have 10 machines. The network is down. All but one of my scripts run on all but one of the machines...)

A long time ago, I decided that I don't have time for either of the following two things:

- libraries that frequently break API compatibility

- application developers that choose to use libraries with unstable APIs that also choose not to keep their stuff up to date.

This has saved me immeasurable time, as long as I stick to languages with strong system package manager support.

Usually, when I hit issues like the one you describe, it is in my own software, so I just break the dependency on libfoo the third time it happens.

When I absolutely have to deal with one package that conflicts with current (== shipped by os vendor), I usually do the ~/lib thing. autotools support something like ./configure --with-foo=~/lib. So does cmake, and every hand-written makefile I've seen.

[edit: whitespace]

No, what that thread is talking about is that somebody wrote a library to exercise unstable features in the nightly branch of the Rust compiler, and that inspired somebody else to write a sky-is-falling blogpost claiming that nightly Rust was out of control and presented a dozen incorrect facts in support of that claim, so now we have to bother refuting the idea that nightly Rust is somehow a threat to the language.

As for the package manager criticism, the overlooked point is that OS package managers serve a different audience than language package managers. The former are optimized for end-users, and the latter are optimized for developers. The idea that they can be unified successfully is yet unproven, and making a programming language is already a hard enough task that attempting to solve that problem is just a distraction.

That's the problem with FUD, it gets everywhere and takes forever to clean up. :)

> I got the impression that it is not trivial to backport packages from the nightly tree to the stable tree

Let's be clear: stable is a strict subset of nightly. And I mean strict. All stable code runs on nightly, and if it didn't, that would mean that we broke backwards compatibility somehow. And even if you're on the nightly compiler, you have to be very explicit if you want to use unstable features (they're all opt-in). Furthermore, there's no ironclad reason that any given library must be on nightly, in that boring old every-language-is-Turing-complete way; people use unstable features because they either make their code faster or because they make their APIs nicer to use. You can "backport" them by removing those optimizations or changing your API, and though that seems harsh, note that people tend to clamor for stable solutions to their problems, so if you don't want to do it then somebody else will fork your library and do it and steal your users. There are strong incentives to being on stable: since stable code works on both nightly and stable releases, stable libraries have strictly larger markets and therefore mindshare/userbase; and since stable code doesn't break, library maintainers have much less work to do. At the same time, the Rust developers actively monitor the community to find the places where relatively large numbers of people are biting the bullet and accepting a nightly lib for speed or ergonomics, and the Rust developers then actively prioritize those unstable features (hence why deriving will be stable in the February release, which will get Serde and Diesel exclusively on stable, which together represent the clear plurality of reasons-to-be-on-nightly in the wild).

> What's missing?

I've already typed enough, but yes, cross-platform support is a colossal reason for developers favoring language-specific package managers. Another is rapid iteration: it's way, way easier to push a new version of a lib to Rubygems.org than it is to upstream it into Debian. Another is recency: if you want to use the most recent version of a given package rather than whatever Debian's got in stock, then you have to throw away a lot of the niceties of the system package manager anyway. But these are all things users don't want; they don't want to be bleeding-edge, they don't want code that hasn't seen any vetting, and they really don't care if the code they're running isn't portable to other operating systems.

I think a more accurate assessment would be that both Red Hat and Debian extended their package support through repositories to enough packages that developers often opt for the easy solution and use distribution packages instead of package manager provided ones because it's easy to, and there are some additional benefits if you are mainly targeting the same platform (and to some degree, distribution, if that applies) that you are developing on.

Unfortunately, you then have to deal with the fact that some modules or libraries invariably get used by code parts of the distribution itself, making their upgrade problematic (APIs change, behavior changes, etc). This becomes problematic when using or targeting a platform or distribution that provides long term support, when you could conceivably have to deal with 5+ year old libraries and modules that are in use. This necessitates multiple versions of packages for a module or library to support different versions sometimes, but that's a pain for package managers, so they tend to only do that for very popular items.

For a real, concrete example of how bad this can get, consider Perl. Perl 5.10 was included in RHEL/CentOS 5, released in early 2007. CentOs 5 doesn't go end of life until March 2017 (10 years, and that's prior to extended support). Perl is used by some distribution tools, so upgrading it for the system in general is problematic, and needs to be handled specially if all provided packages are expected to work (a lot of things include small Perl scripts, since just about every distro includes Perl). This creates a situation where new Perl language features can't be used on these systems, because the older Perl doesn't support them. That means module authors don't use the new features if they hope to have their module usable on these production systems. Authoring modules is a pain because you have to program as if your language hasn't changed in the last decade if you want to actually reach all your users. Some subsert of module authors decide they don't care, they'll just modernize and ignore those older systems. The package manager notice that newer versions of these modules don't work on they older systems, so core package refreshes (and third party repositories that package the modules) don't include the updates. Possibly not the security fixes as well, if it's a third party repository and they don't have the resources to backport a fix. If the module you need isn't super popular, you might be SOL with a prepackages solution.

You know the solution enterprise clients take for this? Either create their own local package manager repo and package their own modules, and add that to their system package manager, or deploy every application with all included dependencies so it's guaranteed to be self sufficient. The former makes rolling out changes and system management easier, but the latter provides a more stable application and developer experience. Neither is perfect.

Being bundled with the system is good for exposure, but can be fairly detrimental for trying to keep your user base up to date. It's much less of a problem for a compiled language, but still exhibits to a lesser degree in library API change.

Which is all just a really long-winded way of saying the problem was never really solved, and definitely not in the 90's. What you have is that the problem was largely reduced by the increasing irrelevancy of Perl (which, I believe was greatly increased by this). Besides Python none of the other dynamic languages (which of course are more susceptible to this) have ever reached the ubiquity Perl did in core distributions. Python learned somewhat from Perl with regard to this (while suffering it at the same time), but also has it's own situation (2->3) which largely overshadows this so it's mostly unnoticed.

I'm of the opinion that the problem can't really be solved without very close interaction between the project and the distribution, such as .Net and Microsoft. But that comes to the detriment of other distributions, and still isn't the easiest to pull off. In the end, we'll always have a pull between what's easiest for the sysadmins/user and what's easiest for the "I want to deploy this thing elsewhere" developers.

I think the language-specific ones will win for developer-oriented library management for platform-agnostic language environments.

My theory is that each language community thinks it will save them time to have one package manager to rule them all instead of just packaging everything up for 4-5 different targets.

The bad thing about this is that it transfers the burden of dealing with yet another package manager to the (hopefully) 10's or 100's of thousands of developers that consume the libraries, so now we've wasted developer centuries reading docs and learning the new package manager.

Next, the whole platform agnostic thing falls apart the second someone tries to write a GUI or interface with low-level OS APIs (like async I/O), and the package manager ends up growing a bunch of OS-specific warts/bugs so you end up losing on both ends.

Finally, most package manager developers don't seem to realize they need to handle dependencies and anti-dependencies (which leads you to NP-Complete land fast), or that they're building mission-critical infrastructure that needs to have bullet proof security. This gets back to that "reinvent dpkg poorly" comment I made above.

In my own work I do my best to minimize dependencies. When that doesn't work out, I just pick a target LTS release of an OS, and either use that on bare metal or in a VM.

Also, I wait for languages to be baked enough to have reasonable OS-level package manager support. (I'm typing this on a devuan box, so maybe I'm an outlier.)

Is there anyone out there saying "builds only when connected to the internet so it can blindly download unauthenticated software ... SIGN ME UP!"

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.

Rocket is a recent one. I talked with the owner of Rocket and one of their goals was to help push the boundaries of Rust by playing with the nightly features. With that sort of meta-goal using nightly is sort of a prerequisite. Meh.

You can use almost all of the code generation libs on stable via a build script. Tiny bit more annoying, but if it's a dependency nobody cares. A common pattern is to use nightly for local development (so you get clippy and nicer autocompletion) and make the library still work on stable via syntex so when used as a dependency it just works.

The most used part of the code generation stuff will stabilize in 1.15 so it's mostly not even a problem.

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) got pretty much no traction whatsoever in the Rust community.

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

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

http://xion.io/post/programming/rust-nightly-vs-stable.html#...

In 2017 we'll get Tokio and lots of Tokio-ready libraries. Some of them already work and compile with stable Rust. And maybe in the end of the year we can take a proper look what we can do with Rocket, or Diesel...

Diesel does work on stable today, but its nightly features will be on stable in five weeks with 1.15.

Are you talking about impl Trait or some other language changes?

That said, if you want to play with nightly Rust, it's pretty trivial. Rustup https://www.rustup.rs/ makes it easy to install multiple Rust toolchains and switch between them, in a fashion similar to rvm and rbenv.

rustup run nightly cargo build --release

You were saying? In any case, there's no such thing as a stable vs nightly split. There's pretty much zero libraries that require nightly, and the few that have a nightly option for optional features will no longer require nightly after the macros update lands.

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

For example, if I have a big string, I may create a hashmap where both keys and values are references to some portions to that original string.

Then, I may pass this hashmap to another function that will transform this hashmap into structs that contain reused portions of those string references.

Rust compiler will make sure that the original string is not destroyed or moved in any way in memory while this is happening.

While it is certainly possible to do this in C and C++, the development cost there is way higher. In C++, one would be sensible to stick to a slower version that copies and allocates data, unless he/she is really sure that the need for performance justifies the code complication.

Meanwhile, juggling the references this way in Rust is common and almost sloppy: the hashmap contains references to strings because it was probably created from iterator that iterated over references. The developer might not even need to notice it unless the string reference in result might be kept around longer than original. The compiler will tell about the type mismatch, and the developer will then create a new string from the reference, and then he/she will move on.

There is a similar story when such code needs to be refactored. The word "sloppy" still works here, but in a good way: offloading "being very, very careful" stuff to compiler is deliciously fun.

I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.

The fact that the code was complicated was sort of the point; the generic deriving code in the Rust compiler is in general a very tricky and confusing area and pretty complicated to deal with. In C++ I would have been very careful around code like this and not introduced new pointers. In Rust, I could do this without being afraid of memory issues.

You're not supposed to understand the actual code in the blog post; there's heaps of context and explanations of compiler internals I didn't want to do. I tried to make it clear what task I wanted to do, and how the compiler helped me carry it out; the code is just there to give a better idea of what was going on. If you read closely I do mention that a lot of things should be ignored, there.

The post also walks through the explanations of why the lifetimes work out that way, but that's more for the readers' edification -- I didn't need to actually figure anything out whilst working on it; the explanations are something I thought about later.

This isn't an instance of the XY problem.

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.

Maybe, but it also appeals a lot to many of us experienced programmers who know how hard things can bite us. It's not so much that we can't get things right. It's that it's really expensive to revisit old assumptions when circumstances change, and it's phenomenal to be able to document more of these in a machine-checked way.

> It's that it's really expensive to revisit old assumptions when circumstances change, [...]

That's very dependent on the type of work you do. Over the last 23 years, my job has been to write many small programs to solve new problems. It's not expensive for me because I've aggressively avoided making monolithic baselines. I have medium sized libraries that I drag from project to project, but I can fix or rewrite parts of those as needed without breaking the old projects.

True, if your code never gets big or old, you can keep all of it in mind and write correct code without too much worry. Though in my experience, it really doesn't need to be very old or very big before tooling starts paying big dividends.

> I have medium sized libraries that I drag from project to project

I'd wonder in particular about those libraries. Certainly you know more about your context. But I expect that there are both contexts where it wouldn't be helpful, and also contexts where it would be substantially helpful but authors don't know what they're missing. I don't have a way of distinguishing the two here.

I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, and many other things.

If I tried to advocate Rust in my office, many of my coworkers would simply say, "I didn't have to do that in Fortran, and Fortran runs just as fast. Why are you wasting my time?!"

> To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

They don't really care about memory deallocations - the program will finish soon anyways, and the operating system will cleanup the mess. Sorry, they've already excused you from the office and have gotten back to getting their work done.

Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.

[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... (yes, most people disregard benchmarks, but you need someway to discuss performance)

Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental, or in fact how some of them are worse than the exact same features in Swift, which you mentioned.

> ... I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists....

Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks. Also, you have to look at the quality of the compilers themselves. Rust is universally acknowledged to be a high-quality compiler, while Swift (especially together with Xcode) are often bemoaned as buggy and crashy.

> They don't really care about memory deallocations ... the operating system will cleanup the mess.

Well, I have to say they are an extremely lucky bunch. Most systems programmers don't have the luxuxy of writing script-sized programs which use the OS as their garbage collector.

> Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.

I was specifically replying to your Fortran example, but for the sake of argument, to C++ programmers I'd ask, 'Would you like to do high-performance concurrency with statically guaranteed no data races?'

There are two string types in Rust, `String` (growable and heap-allocated) and `&str` (a reference to string data). Anything else is just a shim for FFI.

I guess I don't have to worry about the non-Scotsman strings then... You've heard the criticisms about Rust's strings before, and I'm unlikely to tell you anything you don't know.

You never addressed my other "too clever" items in Rust. Does that mean, other than strings, we agree?

Not necessarily. :P Features exist, and I'm not about to dictate where others draw the cleverness line.

I still think the point is valid, though, even if the analogy isn't.

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

Unless you rush to publish a public facing version of your code, I can't see why you'd be afraid to take risks in any language. What's so scary about a buffer overflow on your home workstation running data from a source that's never even seen your program? It will just segfault, which is no worse than a Rust panic. If I could exploit your new code, it means I've already gotten so far into your workstation or server that I could just run my own code. Where does the fear come from?

The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern. (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.)

I guess the analogy would be that you can have more fun cavorting across the sky if you knew with 100% confidence that your parachute automatically would deploy itself at the appropriate time (and not a moment sooner).

I've spent a lot of time figuring out how to do completely mundane things in Rust. At this point, buffer overflows and use-after-frees are not my biggest concerns in C++.

> The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern.

If your testing didn't catch the problem (which I can fully understand), a panic at runtime is not much different than a segfault.

> (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.)

I firmly believe the OpenSLL team would've used unsafe blocks in Rust to disable the performance overhead of bounds checking. That whole exploit was caused by sloppy optimizations, and Rust is not immune from that.

I could visit a country with a completely different set of laws regarding driving and a different road marking system. After a few days of driving, I might also feel like I've spent a lot of time trying to figure out how to navigate the rules of the road rather than actually getting to my destination when compared to driving in my native lang. I would also be unable to accurately ascertain whether one system was better than the other, because of inadequate experience with the new system. It would be a mistake to assume that I could become proficient enough in such a complex system in such a short period of time as to ascertain whether one was better than the other.

To put it another way, I don't feel like avoiding bicyclists is my biggest problem when driving, but having a dedicated bike lane at all times would probably be a good idea anyways. Sure, maybe you've never hit a cyclist, and never will. That doesn't mean it doesn't happen enough that we shouldn't do something about it, because it does.

> If your testing didn't catch the problem (which I can fully understand), a panic at runtime is not much different than a segfault.

No, a segfault at runtime is something that is possibly exploitable. A Panic is not.

> I firmly believe the OpenSLL team would've used unsafe blocks in Rust to disable the performance overhead of bounds checking.

Even if they did, that would still reduce the portion of the code that needs to be audited to those blocks. Effort could be made to reduce the size and scope of those blocks. There is something to be said for having the ability to categorize and enforce different safety levels in your codebase, when the alternative is no categorization or enforcement.

Arguments by metaphor aren't my thing. It's very likely I would become more proficient at Rust if I programmed in it more. It's also very likely the poster above would worry less about memory errors if s/he programmed in C or C++ more. Yes, Rust is safer in some ways, but I still can't understand where all the fear of other languages comes from.

> having a dedicated bike lane at all times would probably be a good idea anyways.

I used to live in a city with a lot of dedicated bike lanes. I commuted to work on a particularly long stretch that was very popular for cycling. The majority of the cyclists refused to ride in the lane. It turns out that cars naturally blow the dust and small pebbles out of the main road way, but bikes don't do that in the bike lane. Cars also smooth out the pavement in their tire tracks. The result was a road that's 5 foot narrower for cars (speed limit 45 mph) with bicyclists in it (not moving 45 mph), a generally unused bike lane, lots of uncomfortable passing, and a lot of indignation from cyclists who claimed an equal right of way despite having a separate lane designated for them.

> Sure, maybe you've never hit a cyclist, and never will. That doesn't mean it doesn't happen enough that we shouldn't do something about it, because it does.

The city I live in now has many bike paths, completely separate from major roads. It's also a different climate, so there are less pebbles and they have street sweepers clean the road after snow season to remove the sand. There really doesn't seem to be much interaction between the cyclists and the cars. So should I choose a programming language with bike lanes on major roads or separate paths though the parkways? :-)

> No, a segfault at runtime is something that is possibly exploitable. A Panic is not.

Anything is possible, but it's very unlikely. I will write a program and intentionally put a buffer overflow in it. Can you send me some data that will exploit it?

Here's a metaphor that also isn't one: I'm not afraid of terrorists despite some high profile events in the last 20 years. I certainly wouldn't optimize my life around avoiding terrorist attacks because the empirical evidence shows me the probability is very low.

> The city I live in now has many bike paths, completely separate from major roads.

Which wasn't the point of that at all. It was to point out that you assessment of how much time is wasted working around problems in each case is irrelevant given your vastly different experience levels. There are plenty of people here with quite a bit of C and C++ experience that have weighed in about this, not just the person above who you assess as not having much experience in C or C++.

A bike path is a dedicated bike lane,just not necessarily parallel to the road. You're taking the metaphor too literally to be useful. A metaphor is as useful as you allow it to be. They can be extremely useful in pointing out somewhat parallel situations where people may find their beliefs are different. When that is so, it allows the people involved to examine what is different about the situations that leads to a different opinion, if anything. Sometimes we fall prey to our cognitive biases, and a metaphor can be a shortcut out of that bias if it exists, and you allow it be that shortcut. Driving it into irrelevancy through focusing on minutiae is a useful rhetorical trick, but doesn't actually advance the conversation, and at the extreme end if done purposefully is not acting in good faith.

> Anything is possible, but it's very unlikely. I will write a program and intentionally put a buffer overflow in it. Can you send me some data that will exploit it?

Depending on the segfault? I could. It would take me a lot of work, because it's been nearly 15 years since I paid much attention to that, but I have done it before.

> Here's a metaphor that also isn't one: I'm not afraid of terrorists despite some high profile events in the last 20 years. I certainly wouldn't optimize my life around avoiding terrorist attacks because the empirical evidence shows me the probability is very low.

No, you don't optimize your life around them, but you might also support checking of identities on international flights to prevent access to your nation from known terrorists.

Here's the thing. It's not about you. At any point in time, some percentage of C and C++ programmers are neophytes that may not be as proficient as you at avoiding the pitfalls possible in those languages. Given the average amount of time it takes someone to be proficient in C or C++, divided by the average career length of a programmer of those languages, and you'll have a rough estimate of what percentage of programmers of those languages we might conceivably have to deal with problems from them being inadequate for the job they are assigned. I think that reducing this has such a large impact, that this is of vast benefit to society at large (given the botnets we are currently seeing), and would total billions of dollars.

An accurate diagnosis, I think. You'll never get anywhere with people like that ... or where you get is not anywhere you want to be. In this case, you have someone arguing against Rust because a) his coworkers don't bother to free memory because their programs will finish soon and b) because he doesn't care whether toy programs that he writes for his home computer are subject to buffer overflow exploits.

And on top of that was missing the point of your analogies that, if not willful, was certainly convenient. To use another one: some people are like quicksand.

> Which wasn't the point of that at all. It was to point out that you[r] assessment of how much time is wasted working around problems in each case is irrelevant given your vastly different experience levels.

That was almost my exact point, and it's odd you're repeating it back to me. I guess I could've laid it out more plainly.

> [Metaphors] Driving it into irrelevancy through focusing on minutiae is a useful rhetorical trick. [...] at the extreme end if done purposefully is not acting in good faith

Using a metaphor is a rhetorical trick. If you want to explain something to a non-technical audience, maybe analogies "get the hay down to the horses" so they can have at least a limited understanding. However, we both seem to understand programming languages so talking about roads obfuscates the discussion, leaving me to wonder whether there really is a parallel between the two topics. I know more about programming languages than I do about bike paths.

> Depending on the segfault? I could. It would take me a lot of work, because it's been nearly 15 years since I paid much attention to that, but I have done it before.

Even if I offer to run malicious data, it sounds to me like a low probability event - probably lower than my being in an airplane crash or shot by a cop. It's not something I should fear today. Over the last 25 years, I've had lots of segfaults, but I think I've done the most damage by accidentally overwriting files. I'm a little afraid of that.

> No, you don't optimize your life around them, but you might also support checking of identities on international flights to prevent access to your nation from known terrorists.

No, I definitely would not. It's very easy to get into this country, and an organized (dangerous) group would have no more difficulty than the drug dealers do smuggling cocaine. There is no benefit to harassing millions of citizens if you can't actually stop the problem.

> Here's the thing. It's not about you.

Are you suggesting the only people allowed to share their experiences in a thread like this are new programmers and the people pushing their language? I was new once, and I survived lots and lots of segfaults. Don't you think neophytes should hear that? They're definitely getting a large dose of doom and gloom about the bad old days.

> Some percentage of C and C++ programmers are neophytes. [...] I think that reducing this has such a large impact, that this is of vast benefit to society at large (given the botnets we are currently seeing), and would total billions of dollars.

In one of your other comments, you indicated you haven't tried Rust yet. You should - you sound interested. It definitely has its nice parts. However, I don't think you will find the safety features to be a big productivity gain, and you will have to use unsafe code to accomplish tasks from a freshman level computer science book. Think about that - you can't cleanly use the safe subset of Rust to teach computer science to beginners... (you could do it with a lot of compromises)

Rhetorical tricks can be used to deepen the conversation, or to dismiss points out of hand. The first is useful to the discussion, the second is useful for winning, but at the detriment to the discussion.

> However, we both seem to understand programming languages so talking about roads obfuscates the discussion

I provided a example where it may provide value even if two people are experts in the area being discussed. Metaphors can help explain someone underlying reasoning and motivation in a way that is hard to express technically. People talk past each other enough in discussions by slightly misinterpreting what is trying to be expressed, that I find metaphors a valuable tool. I find many disagreements in text are rooted in people assuming a comment is countering a point of their or someone the agree with, and interpreting it in that light when often they are saying very close to the same thing. Thus I believe expressing a point in multiple ways, even if it's through metaphor, to have merit.

> Even if I offer to run malicious data, it sounds to me like a low probability event - probably lower than my being in an airplane crash or shot by a cop.

First, airplane crashes are extremely rare. Second, being shot by a cop is rare too, depending on your vocation and behavior. Third, remote code execution exploits are not rare, given the relatively small amount of public facing software compared to airplane flights an all police interactions.[1] Were you to author or contribute to any non-trivial size C or C++ project that was publicly available, I would put better than even money on there being an exploit findable in it. There's a vast difference in how much software is written to how much is public facing, but that doesn't mean things that were originally private don't sometimes make their way public years later, for example internal libraries that a company open sources or even just includes in another project that ends up being public facing.

> No, I definitely would not. It's very easy to get into this country, and an organized (dangerous) group would have no more difficulty than the drug dealers do smuggling cocaine. There is no benefit to harassing millions of citizens if you can't actually stop the problem.

So, again, because you can render a metaphor in more detail to make it irrelevant in context doesn't mean that's appropriate. So, in more generic terms, "do you support keeping known detrimental people out of a defined area to facilitate the usefulness of that area"? If can can do so, and it's not to cumbersome on those that are not detrimental, depending on the problems caused by the people in question, at some point it becomes worth it. There are parallels that can be drawn here, if you're willing to entertain the thought. It appears you aren't.

> Are you suggesting the only people allowed to share their experiences in a thread like this are new programmers and the people pushing their language?

No, I'm expressing that a single person't ability to avoid negative behavior has little bearing in an argument regarding community norms and herd behavior, which is what I'm getting at. Whether you are a perfect programmer and never make a single mistake in any language you use doesn't matter when discussing the merits of enforced safety in general as in this discussion regarding C and C++. What does matter is whether other programmers in general do, and what percentage of them, which you've also made a point of expressing. I think that is worth discussing, because I think we either disagree on the proportion of those programmers that can code with adequate safety, or some other facet of them that results in them yielding far more problematic code every year than you think they are producing.

> In one of your other comments, you indicated you haven't tried Rust yet.

I've tried it. I haven't done more than dabble though, while playing it futures-rs. I understand the borrow checker is cumbersome at my level of uncerstanding, and I fought with it. I don't think I have sufficient experience to make an assessment of the language personally based on my level of experience with it, and especially not with how it feels to write in comparison to C or C++, because I strive to avoid using those languages.

> However, I don't think you will find the safety features to be a big productivity gain, and you will have to use unsafe code to accomplish tasks from a freshman level computer science book.

I believe have the ability to define safe and unsafe portions of code is in itself laudable and useful. Allowing me to categorize possibly problematic portions of code is a benefit. In any case, I could essentially write the entire program in an unsafe block and have a C/C++ alike with a different syntax. I'm not sure how "unsafe" can be presented as a downside, when it's strictly a way to enforce separation of a feature that C and C++ don't have.

> Think about that - you can't cleanly use the safe subset of Rust to teach computer science to beginners... (you could do it a lot of compromises)

What, you can't use that explicit separation of what is known safe and known unsafe to point out computational problems and ways they can be solved? I find that hard to believe. Unless you think unsafe is Rust but "lesser, not really". It isn't. It's part of the language. It exists as a concession that sometimes things are needed that can't be proven safe by the compiler, but you may be able to prove to yourself it is.

1: https://www.exploit-db.com/remote/

My point about remote exploits, airplane crashes, and cops is not about me. Yes, public facing software needs to be careful, but (fun metaphor) that's like saying prostitutes should use condoms. Web servers, browsers, firewalls, and the like are built specifically to communicate with untrusted entities. That's some of the most promiscuous software out there, and yes it gets exploited. But most people don't need to use condoms with their wives, and nobody is going to exploit software a newbie wrote and runs on his home computer. Safety should not be the fundamental criteria for a newbie programmer to choose a language and learn how to write fibonacci or hello world. When they're ready to write nginx, then they should be careful.

My point about the questionable productivity gain and safety was a reply to your estimate of the billions of dollars lost. If you're not more productive, and you aren't really safe, then you aren't going to save those billions.

> What, you can't use that explicit separation of what is known safe and known unsafe to point out computational problems and ways they can be solved? I find that hard to believe.

I didn't say anything like that. We're talking past each other.

> Unless you think unsafe is Rust but "lesser, not really". It isn't. It's part of the language.

(Metaphor time again) I've got a really safe bicycle. When the safety is on, children can't get hurt while riding it. If you care about the safety of the world's children, they should use my new safer bicycle. Oh, but you can't pedal it on paths I don't provide unless you disable the safety. Is my bike really that safe?

> 1: https://www.exploit-db.com/remote/

I have no idea how many people compiled and ran a program today. It's probably millions. Bayes's theorem might be a useful way to normalize that long list you linked. I don't see a single program from a home programmer on that list.

No one said that you said anything like that. Of course you didn't. But what you said necessarily implied that.

"We're talking past each other."

No, you willfully ignored and misrepresented all his points.

"Oh, but you can't pedal it on paths I don't provide unless you disable the safety."

That's a grossly dishonest misrepresentation the situation with Rust.

This. Unsafe is to the borrow checker as 'Any' is to the typechecker.

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.

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

You like to make stuff up.

"If you can't see them, it might be because you're aligned with that point of view."

Or it might not. It might be that you're just being abusive and dishonest.

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.

Just out of curiosity, what is it about Rust that means it's an inadequate replacement for C++?

I'm not completely serious, it's more complex that this.

Regardless, it's a complete mispresentation of Rust, which is all that zero has to offer.

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/

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.

> The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

"Facilitate the growth" does not imply that dominance of a certain practice (whether that is use of Python, or adoption of its core principals) is a goal. So you have an incentive for the PSF to say "our international community is growing at a sufficient rate" and focus instead on "advancing the language," which may or may not be aligned with adoption. In such a framework, it becomes easy to justify backwards-incompatible major releases that, regardless of whether their opinion is justified, many users consider to be user-hostile. Framing Rust towards a larger mission that implies user adoption of core principals as a fundamental goal seems much cleaner in that regard, and could conceivably avoid similar pitfalls.

I'm all up for a marketing shift though. I agree Rust is much more than safety and I think graydon2 missed your point there. The fireflower simile is excellent. Plus I've seen lots of people confused about Rust, including here on HN. Those are the people to whom marketing failed and should be targeted better.

I would go a step further, "fearless programming". Though I would hesitate on 'easy'.

Rust gives you fearlessness in all the things, but it does mean learning new style and discovering new solutions to old problems. To fully understand 'Send' vs. 'Sync', for example, means really groking the Rust type system. Once you get the type system, then fully utilizing it with the expressive generics becomes unlocked, and then at that point you've transcended from Rust dabbler to fully fearless Rust user.

Once this world of development is unlocked to you it is mind-blowing, but it is a journey to get there, and not everyone will have the heart to make it. It comes in stages, is wonderfully rewarding, will make you a better programmer in you other favorite languages, but I think we should be careful with statements like 'Rust makes it easy'.

It does make hard things easy, but only after you've fully embraced Rust. This feels more accurate: "Hey, you know that thing that's really hard for you? Rust makes it fun."

Rust is cool enough that it doesn't need to be promoted with excess hype.

If it was just safe and not C/C++, it would be another Ada, Modula-2, D, etc. It's important to market all the key benefits of it in a way that lets potential users know it will help them solve problems faster and with less trouble down the road.

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.

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

Ada side is producing a new model for parallel and concurrent programming called ParaSail:

http://www.embedded.com/design/programming-languages-and-too...

http://www.math.umn.edu/~arnold/disasters/ariane.html

Although that was not a failure of language safety, but an overflow issue. The software was designed successfully for another rocket, and was reused for a rocket that didn't match the original specification.

Programmers blindly following specs put together by people who have no claim to expertise in these matters without questioning the assumptions behind the spec is the cause of all manner of disasters. And "but that's what the spec said to do" is all to common an excuse when the problem is with subtle runtime behavior issues that fall squarely in the programmer's domain of responsibility.

The decision to re-use the component as-is in the Ariane 5 without sufficiently investigating the consequences of the higher horizontal velocities that it is subject to compared to the Ariane 4 cannot so obviously be blamed on the programmer that implemented it years before in a different context.

I kind of took the story as an allegory when writing my comment. The article is quite vague about the details of the situation. And for all I know, it IS programmers that write specs for this European Space Agency unmanned rocket project. But the way the story is told aligns with a more universal experience of programmers blaming specs for the failings of programs, even when they should have recognized that the program was misspecified before implementing it. I ran with that interpretation because it was illustrative of something important, but it is not particularly surprising to me that the details are being questioned. The article was never a rock solid account.

1) No manual memory management, everything is static and you have memory safety

2) Garbage collection, you have memory safety

3) Manual memory management, you lose memory safety

Rust provides memory safety in the case of manual memory management.

Ada provides more ways to automate memory management, though.

Controlled types are Ada's version of RAII, used for arenas and smart pointers.

Also in Ada you can dynamically allocate everywhere, so a common pattern is to use a subroutine parameter to do stack allocation. If it fails, by throwing an exception, recall the subroutine with a smaller size.

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

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

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?

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.

As a big rust fan, I wouldn't go that far. You can offload a lot more work to the type system in a language like F# or Haskell. Rust is very safe from e.g. a memory perspective (excepting unsafe operations), but there are additional levels of assurance you can get by aggressively forcing the type system to catch logic errors for you that you can't really do in Rust.

As for performance, I agree, although a more accurate description would be that it's much easier to get C-level performance with Rust code while you have to put in some more effort to get it in any high-level functional language.

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.

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

And some of them are watching you with great interest.

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

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

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

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.

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

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!

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

"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

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

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

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.

I'm somewhat okay with the parsing ones using unsafe if we can be very sure that the unsafe code actually has a performance impact, and be very careful about it. Some of them already do this, but not all.

For me, safety is the killer feature in Rust. It's also exciting because it brings systems level programming to a new generation of programmers without all the risk.

So basically just about all programs, all of the time?

https://www.owasp.org/index.php/Don't_trust_user_input

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

Not just that, but my theory is that untrusted input should only be stored in data types specifically designed for untrusted input [2], and should undergo safety/sanity checks during conversion to more high-performance types. For example, a general rule might be that untrusted integer inputs may only be converted to (high-performance) native integers if their value is less than the square root of the max integer value.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus#quarantined...

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

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.

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.

It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language.

Especially since the systems we use are often dynamic with changing requirements.

Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors.

> The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language.

Sure, I don't disagree with that statement. But it's important to recognize that eliminating whole classes of errors is extremely valuable and allows us to focus on the important things.

There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anything to say that a language like Rust or Haskell eliminates all type errors. There are certainly type systems which could catch more errors.

But I read OP's point as "Well, you can never catch all programming errors with PL_feature_X, so why even bother." And my point is simply that a lot of PL features make formerly hard things easy and thus allow you to go faster and focus on more interesting things.

Yes, no programming language perfectly eliminates all classes of unsafety. But that's no reason to let the perfect be the enemy of the good! "The issue with safety is..." no issue at all. Being safe in a bunch of problem domains (Rust) is still strictly better than being safe in very few if any of them (C).

In e.g. Python, the following code:

    foo = Bar()
    foo.baz()

This distinction is significant, as Python and other dynamically-typed languages require comprehensive test suites for any non-trivial software written in them, shifting the burden of ensuring type safety to the programmer. Testing systems for statically typed languages don't need to concern themselves with type safety. Dynamic typing also carries performance penalties at run-time (checking type safety for e.g. every member access).

* Some statically-typed languages (e.g. C++) allow for very specific subversions of type safety at run-time, but its usually clear to the programmer when they are doing something dangerous.

Um, no. Every pointer is fundamentally unsafe, and a lot of C++ code is written with pointers through and through.

Nonsense. C/C++ will happily produce a warning, if you specified -Wall, that you violated a type constraint and then go ahead and compile your program. To suggest that such violations are part of C's type system is to pedantically and willfully miss the point.

Do you consider silently trimming value during mandatory explicit type conversion a type error?

    fn main() {
        let x = 5i32;
        let y: i64 = x.into();
        println!("{}", y);
    }

    fn main() {
        let x = 5i32;
        let y: i16 = x.into();
        println!("{}", y);
    }

    fn main() {
        let x = 5i32;
        let y = x as i16;
        println!("{}", y);
    }

The casting function could specify the valid input values, and force the programmer to handle the rest of the cases when the input type is wider.

[1] https://news.ycombinator.com/item?id=13125328

This is a contradiction, something cannot be both silent and explicit.

This is a common misunderstanding of being Turing complete. A program running in an interpreter isn't unsafe just because the programming language and the interpreter are Turing complete. Being Turing complete doesn't mean being able to gain root access, overwrite the boot block, scribble on the hard drive, etc.

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

Like this "safe concurrency" claim sounds really fearless to me, even though I know they mean some guarantees towards thread safety and all that, not actual safe concurrency.

I think the word you're looking for is "safety". Safety is inherently relative and mostly about risk management. There's no such thing as 100% safe by definition.

As you consider higher (application) level notions of safety, it generally becomes less practical to achieve that safety statically (at compile-time), so you'd want your language or your framework or whatever to facilitate the implementation and performance optimization of dynamic (run-time) safety. At the moment I'm thinking about automatic injection of run-time asserts (of application level invariants) at appropriate places in the code. (At the start and maybe at the end of public member functions for example.)

If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. (Of course the optimizer could report what run-time checks it was not able to optimize out, if you wanted to self-impose static verification.)

(Statically optimized) dynamic safety is more scalable than statically verified safety. As a "systems language", Rust may be less concerned with higher/application level safety. But I think this might be a little short-sighted. The definition of "system" is expanding, and the proportion of "higher level" safety concerns along with it.

That kind of lack of transparency about what in the hell your code is doing at runtime is really inappropriate in a system's language.

It's an interesting idea, and it would be neat to play with in a language that wanted to restrict itself to more business-logic level safety concerns, but it would absolutely come at the cost of not being appropriate for systems-level tasks.

But yeah, I can understand the sentiment of wanting to minimize that kind of thing in a lot of cases. Perhaps, like C and C++, Rust might consider bifurcating into a "high transparency" language, and a "high productivity" superset of the language. In that case, would all of the existing Rust language make it into the "high transparency" subset?

Like I said, the problem is that no one's defining what a "system" is. Haven't they written a browser rendering engine in Rust? Is that a "system"? Is there any part of the browser that does not qualify as a system?

Question mark is roughly six lines of code, it's a match statement on Result, which has two cases.

edit: Or is that just looking too far ahead?

It's simple (only the two tiers), but it is another tool for abstraction and managing complexity.

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.

;)

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

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?

Rust was released in 2015, it's merely one and a half years old, while Go was released in March 2012.

If you count the inception period of Rust (pre-1.0) you should also count Ken Thompson's and Rob Pike's work at plan9, which doesn't make more sense …

Fun fact: Go's first commit is 44 years old [1] ;)

[1] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...

I agree that they had very different priorities in beginning and it changes with time. My goal was to merely point out core rust people in Mozilla and elsewhere now recognize that industry usage is an area of high importance in coming months/years in contrast to purely technical concerns of past.

Rust took a different path, the developers until the 1.0 release basically said; use at your own risk, we reserve the right to change anything and everything and break it all. This freed them of trying to keep the language backward compatible.

After the 1.0 release, there have been nearly no breaking changes introduced to the language, and they have signaled that they want to keep this stability going into the future. This is a big difference from Go which decided to go for an earlier public release, and now is much more constrained on how it can change (if they don't want to break all the stuff built on it out there).

So it's not fair to include the 6-7 year development cycle, as that could be more thought of as a research period, one that laid the groundwork for the safety in everything which is the basis for Rust now.

"Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money."

Major differences are that Limbo uses a VM based runtime with dynamic loading and Abstract Data Types.

But your approach is also good, still Oberon had some issues that were eventually improved in Oberon-2 that Go lacks.

On the other hand Oberon-07 is even more bare bones than Go.

Has Rust actually settled down on some stability?

1. serde, the best serialization/deserialization library. This works on stable now using the `serge_codegen` crate and a custom `build.rs` script. This will Just Work on stable with no extra setup once Macros 1.1 lands, theoretically in about 5 weeks. But I'm using it on stable now in a half-dozen projects, thanks to a `build.rs` script.

2. Diesel, the high-level ORM library for Rust. This works on stable using a `build.rs` script, and 90% of it will work on stable without the `build.rs` script once Macros 1.1 ships.

There are a few other experimental libraries like Rocket (which looks very slick) that only work on nightly Rust. But I don't think any of them are particularly popular yet.

Personally, I maintain something like two dozen Rust crates and applications, and only two use nightly Rust. Both need Macros 1.1, which should be on stable in about 5 weeks.

To recap, in Rust, to make additions to the language:

1. Small additions mean make a PR.

2. Big additions mean make an RFC, then a PR if accepted.

3. These PRs go behind a feature flag that lets us track the feature, and only allows it on nightly.

4. People who desire the new feature try it out. (This is what you refer to.)

5. If any issues are found, they're fixed, or, in the worst case, the feature is removed.

6. The feature is made available to stable users, the feature flag is removed, and backwards incompatible changes can no longer happen.

What would be un-healthy is if everyone had to rely on nightly for everything. At the moment, most people use stable Rust. And of the people that use nightly, the largest single feature will be stable as of the next stable release for Rust. But some people are always going to be using nightly features, and that's a good thing: it means that by the time it hits stable, it's already undergone some degree of vetting.