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.
It is not my intention to show Rust in bad light. I roughly mean to say both languages have put about 6-7 years of engineering effort by now but usage differs by an order of magnitude or so.
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.
I think your not looking at this correctly. Swift also had a very fast pasted release cycle like Go.
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.
I said 6-7 years of engineering effort not development cycle which are often linear. I am not blaming for taking long to get things right. If authors think they need more time then of course they need more time. Right now they really want to have broader industry usage and this can't be any clearer when they say:
"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."
I thought it was supposed to be Oberon-2 with some Limbo, C, etc touches. That's part of how it becomes my slam dunk against C in anther discussion. ;)
I only glanced at Limbo. I'll have to take a more detailed look at it. Inferno was definitely interesting. It was even ported to Android to replace Java runtime by people at Sandia.
It might be Go’s age overall from initial inception, but a typical point at which people start paying attention is the 1.0 release. In Go this was March 2012, for Rust it May 2015, over three years later.
To be honest, Rust took so long to stop making breaking changes and stabilize, I sort of tuned out on it -- it was never at a point it made sense to start using.
There are really only two popular Rust libraries that use unstable features:
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.
serde works on stable without serde_codegen or custom build scripts, too. It works like a regular library in fact, just with less features (no code generation feature). A custom data structure might not be able to use the default code generation for its impls anyway.
Right. Go and Rust have completely different development models, so that wouldn't make any sense.
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.
However, many popular or important libraries like Serde or Rocket require the use of nightly. I recall the article a very short while ago on the front page that noted how Rust has effectively diverged into two languages, stable and nightly.
This article has been unanimously qualified as FUD by the Rust user community.
Nightly is for innovations and experimentations, not for real use :
- Rocket is an amazing example of innovation, but it's currently just an experimentation.
- Serde works on stable for a long time but they experimented a more ergonomic version on nightly. They iterated upon it with Rust developers to create a new and well thought stable API which will land in the next version of Rust (macro 1.1 in february).
Rocket is likely to follow Serde's path during 2017 and will eventually work on stable in 2018. Building a great langage takes time ;)
Serde does not require nightly, though it is nicer to use on nightly. That's the "will be stable as of the next stable release for Rust" I alluded to above.
Rocket just came out; I think it's an extremely interesting library, but https://crates.io/crates/rocket shows that it's been downloaded 618 times. It hasn't exactly taken the world by storm yet. I think it shows great potential though! But it's not a good case of showing that the Rust ecosystem largely depends on nightly.
The article you refer to contained a number of factual errors.
Over the last year of intermittently dossing around with Rust I encountered the need to use nightly regularly, with various crates refusing to compile (and usually I stopped my experimentation there as my barrier to entry was anything harder than pacman -S rust cargo). Yet I did not know until just now that Serde is moving off a dependency on nightly and it is encouraging that this is a trend with similar libraries; I stand corrected.
Serve creator here. The core library 'serde' never actually required nightly. It was just the helper library 'serde_derive' which can automatically implement the serde traits that needed nightly. dtolnay has been doing a wonderful job getting us off nightly. We can't wait to finally get rid of using it.
If you happen to remember which libraries those were, I'd be interested in hearing about them!
> my barrier to entry was anything harder than pacman -S rust cargo
Today, that also wouldn't be the case: "rustup update nightly" and "rustup run nightly cargo build" or whatever, with extra stuff to automatically switch per directory.
We've been using Rust on production since the summer and we only use the stable compiler.
These "popular or important libraries" are nice use cases what you might be able to do with Rust in future. But relying on them right now and using them in production is not really a good idea.
That article posted half a week ago [1] claiming Rust developers and libraries rely on nightly was FUD. It's terrible that this is being repeated, because it is simply not true.
>> Currently Rust is about Go's age but nowhere close in usage.
However, Go has been suitable for production projects for several years longer than Rust.
Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go.
Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use cases that Go serves vastly better than other available alternatives.
Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the Go team has been so conservative re: generics: If they aren't implemented carefully, they could unacceptably complicate the language.
Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.
In my experience working with new and experienced Go developers that simplicity is pretty superficial.
Take a look at SliceTricks[0]. These are all pretty simple operations in other languages that the Go authors think users should be forced to write manually so they understand the costs. Reading these in code reviews is definitely not a breath of fresh air.
I also see Go users develop bad habits that will burn them in other languages, like returning a reference to a "stack" allocated variable. In the same vein, if you care about performance you have to internalize the escape analysis rules, which most new users won't know about.
There are tons of footguns[1] in Golang as well. I constantly see people get burned by issues at runtime. I truly believe that the Golang benefits are short-sighted. You get some upfront development gains that you end up pain for with less reliable software. I personally would rather pain that cost upfront where possible with the compiler telling me when something is wrong.
> 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.
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.
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).
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.
For all the benefits of higher-level languages. Remember that the designers of C had to agree on every feature that went into Go: a language they co-designed for better programming experience & results. Wirth-style languages also compile ultra-fast for quick iterations.
My question is really why not choose something really higher level ? Go is like stuck in the middle. If I need very low level, I'd choose rust. If I need high level, I'd choose Python. Go is kinda filling a weird niche between the two and I rarely find a case where I feel like it's the best choice.
Anything that is robust, dynamic, with a big ecosystem. Python, Ruby, whatever have you. You don't need raw speed since the OS API does most of the work, and the ease of programming would make it more productive. In the end, they added Python anyway for stuff like "compose", so I'm missing the point of using Go for this. The Go code is not even network bound, the ability to get multicore easily is not a bit advantage here since you spawn a new process anyway, so really, why ?
Go has much lower memory usage, high throughput, std ssl/tls/http libraries, high performance GC and produce fully static binaries. I do not think Python/Ruby can provide required performance for containers, cluster scheduling, orchestration etc. Even Java with much higher perf compared to Python/Ruby is not suitable because of high memory usage.
> lower memory usage, high throughput [...] high performance GC
Irrelevant, as most ressources will be consummed from underlying OS API.
> std ssl/tls/http libraries
So does Python and Ruby. But even if it didn't, you provide a package anyway.
> produce fully static binaries
You can do that with Python and nuikta. But there is need for it, since docker is provided as an msi/deb/whatever that take care of distribution.
> high memory usage.
On your xGb RAM server, the memory usage of your container is the least of your problem. Your DB will dwarf it, your app will dwarf it. Anything you put in your containers will take 100 times more memory.
Ocaml is a good choice, and Anil Madhavapeddy used it for his unikernel ideas. But Ocaml doesn't have strong backing any more. JaneStreet alone isn't enough.
Part of the issue stopping me from jumping in is that it feels like the language is still changing in ways large enough to make it difficult to learn. That may not be true anymore, but it seems like it would take a lot of work to keep up with the current 'best practices'.
> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.
I don't. It's a measure of the overall success. Design is but a small part of that. Community, outreach, corporate back up… play a huge part in the success of a language.
Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Feels like Google backup matters more than the core language here. Either that, or someone please explain why omitting generics today is not a big mistake. Feels like dynamic scope all over again.
Think about who is picking up which language and how many programmers with what background there are. Go offers solutions for certain problems that many of programmers have. I.e. performance and ease of deployment are the biggest ones for people coming from scripting languages, and there are a lot of them. Having easy to pick up syntax doesn't hurt easier. But generics are not as valuable for them at the beginning. And Go's syntax has like a dozen of critical problems either way, might as well add generics in 2.0 together with all the fixes.
Google backup is really more towards Dart when compared to Go. Dart has much more Google contributors vs Non-Google. Dart Dev summit seems to be totally sponsored by Google and it even had free entry whereas Gophercon is independent of Google.
Though Dart has generics but not much usage in industry.
> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.
C (and later C++) became popular because Unix was successful. Safe systems programming and safe browsers are nice to have but not completely safe if the underlying OS is unsafe (Windows in particular). Rust's "killer app" would be a safe OS. The first attempt (Redox) is already there.
