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...
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.
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."
Has Rust actually settled down on some stability?
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.
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.
> 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.
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.
- 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 ;)
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.
How many breaking changes happened in the past 18 months?
>> Currently Rust is about Go's age but nowhere close in usage.
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.
Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.
Can you explain why?
For example, simple generics which could be implemented as regex doesn't seem to complicated? Am I missing something?
For example (in Java), an ArrayList <String> could be turned into a StringArrayList by a basic internal pre-processor.
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.
[0] https://github.com/golang/go/wiki/SliceTricks [1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
> I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing.
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.
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.
http://www.tiobe.com/tiobe-index/
A Github search turned up 2,658 Go repositories with more than 100 stars:
https://github.com/search?l=go&q=stars%3A%3E100&type=Reposit...
compared to 348 Rust repositories:
https://github.com/search?l=rust&q=stars%3A%3E100&type=Repos...
Notably, Docker has more stars than Go itself.
Edit: you may also be interested in IEEE Spectrum's interactive list of the top programming languages:
http://spectrum.ieee.org/static/interactive-the-top-programm...
With the default parameters, Go and Rust are 10 and 26, respectively.
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).
Rust: https://www.rust-lang.org/en-US/friends.html
Without counting Go usage roughly looks 10 times more than Rust.
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.
Though Dart has generics but not much usage in industry.
Only because one can opt-out of the type system and use a catch all "interface {}" .Actually even the std lib does that ... a lot.
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.
I was looking through the pointer safety portion of the safety brochure: https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me... and wondering how to approach unwrapping an ethernet packet on the wire in the easy unsigned pointer-specific way it can be done in C and came across a pcap implementation in Rust (sample source): https://github.com/ebfull/pcap/blob/master/src/raw.rs Are you serious? Rust is not for me, thanks.