Rust 0.11.0 Released
mail.mozilla.org
mail.mozilla.org
Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.
Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.
Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".
My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.
You are correct. The third production deployment of Rust is a Ruby gem written in Rust.
It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
We'll never see Go on 16-bit architectures or smaller, though.
I do bash Go a lot, but it would be possible if the designers took the same approach as Cedar, Oberon and Modula-3. A few GC enabled system programming languages.
- Expand the capabilities offered by the unsafe package
- Offer more control over the GC behavior
- Add a kind of untraced pointer or a GC API for allocating them
Great job, Rust developers! As ever, the challenge is to keep it up. :)
This appears to be "dynamically-sized types", for people who aren't in the know: http://blog.babelmonkeys.de/2014/03/18/dst.html
I look forward to a Rust release that doesn't have these. :) I've been tracking the language since the 0.5 (ish) timeframe and the language is a lot more ergonomic than it used to be but the frequent major shifts in how day to day Rust code is written make it tough to follow for a casual observer like myself (I follow /r/rust and write toy code every point release). Salute to the Rust devs and for those of you that work at relating the language to the rest of us. The language looks better every release.
The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies).
As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.
And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally.
At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.
(I've also come to understand that Go is an extremely sharp tool for Google's problems - the style of coding, the concurrency, the expectations of the developers (look at the Google style guides to see the culture of development there, there's a harmony with Go). Your harmony with Go reflects your harmony with Google's problems).
Rust has a good concurrency model but I doubt it will compare favorably with Erlang's distributed computing primitives and fault-tolerance features (read, fault-tolerance is not equivalent to type safety!!)
Storm does it more at the machine level, while the philosophy is the same there it's not really done in the language but by Nimbus (correct me, someone, if I'm wrong).
The things in Erlang that are novel are really features in its BEAM VM, and not as much in the language. Distributed RPC, a DNS system built in for discovery, hot-reloading, heartbeat, etc...
I'm sad that Storm ended up being built on Java - Erlang would have been a perfect and probably better way to implement it.
I think a potential reason people are comparing the two is because Rust is also great (it's still early, though, so it'll be interesting where people leverage Rust) at the use cases that Go was designed for, while Go cannot touch what Rust was built for. However, the two being defined as system languages with two widely different views on what "system" means doesn't help.
I'm not so positive that Rust will be so great in cases where you have many developers with different levels of skill and experience working on infrastructure projects. Rust makes the low level stuff easy, but a lot of high level stuff is still going to be easier in Go.
I actually feel that Rust is really good at abstractions that make it seem a lot higher-level.
I agree that Rust more complex than other languages, but I don't think it's that much more complex. I think better documentation and tooling will make it more approachable.
Go has been fairly expressly billed as a C/C++ replacement. Now, I think that's somewhat misleading in comparison to Rust also being a C/C++ replacement, in that Go seems intended to replaces C/C++ in uses that are near the boundary where C/C++ (and, yes, Java) competes with Python/Ruby/etc. (where the former set has more of the performance characteristics sought but may be less convenient/concise/expressive, whereas the latter has the reverse features), whereas Rust is aimed at C/C++ deep in those languages prime use cases where they have little current competition -- certainly not from languages like Python/Ruby/etc. -- not at the boundary where they compete with Python/Ruby.
I think the community at large has billed it as such, but I haven't seen such a direct statement come from anyone on the Go development team. This is really the core of my original question, why does the community think of Go as a C replacement when it explicitly does not support the feature set required to be such a language?
Put in other words, there is a class of problems C/C++ are used for which Go isn't even remotely suitable for, on the other hand, there is a large class of problems that C++ was used for, that could have been written in Java and Go is a good replacement for. I feel that the subset of problems that were/are solved in C/C++ that could not have been solved in something like Java is fairly small. Off the top of my head things like high end video games, high frequency trading, perhaps database type systems where direct memory access may not really be needed yet the performance constraints are tight enough that something like Java was too slow for it. This may be where the 'systems programming language' moniker came from. I would guess that Google has a disproportionately large set of problems that fit into the space that I think is relatively rare for the programming community at large.
Here's an article from Rob Pike both pointing to Go's motivation as a C/C++ replacement and explaining why he thinks it didn't draw that audience:
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
Go doesn't appear to be particularly suited for writing a kernel or drivers, Rust looks better for that. Beyond that, if we're talking about writing user space type applications, can someone point to some that need something particularly C like? There is a whole ton of C code that could easily be done in C, Rust, or go with relatively little downside. Not too many weeks ago someone posted linux coreutils in Rust and someone else posted coreutils in go. I'd be hard pressed to make the case for C over either of those, perhaps raw cycles performance is incrementally better.
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...
(approx 6 minutes 45 seconds into the talk)
I think it will take about a decade for everybody to readjust their frame on this one, alas.
P.S. Rust's own Niko Matsakis is one of the 4 people in this panel discussion, by the way, and it is well worth watching – even though they burn maybe a little too much time struggling with the question of what does/doesn't constitute a systems programming language.
It is a bad meme, it even doesn't fit for C++ given it's main application as an application language (cue Torvalds rants about C++)
I think Go fits decently for the latter, and reaches up to higher-level (or lazier) code that others might write in Python or Ruby or Haskell. Rust seems to reach as far down as C, which would be nice, though I worry that LLVM lacks any target smaller than ARM to keep them honest.
A language capable of building the OS whole stack from the ground up, taken out the obvious parts in Assembly.
Yes, there are OS out there written in C++.
That's unfortunate. We should be arguing about Ocaml vs. Rust or Ada vs. Go!
I mainly receive bemused looks. "We use Java."
Worse, Java really means Java and not any alternative language for the JVM.
That depends. Not all are bought on the Java hype from the past but it surely is still widespread.
> Not all are bought on the Java hype
Yeah, that happens. You probably should just skip those places to begin with :) I second those who mentioned C++ in the comments. Those places have more chances of appreciating Rust.
https://github.com/rust-lang/rust/wiki/Note-getting-started-...
I myself run Ubuntu at the moment, so I can certainly help.
1: #rust on irc.mozilla.org, or http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23ru...
It turns out default mem settings in VirtualBox weren't large enough. On IRC they recommended 2.0 GB of ram and that worked for me! ready to rock...
When people become attached to an exciting new language, in their elation they tend to envision using it in every context imaginable. But most languages are designed for a particular (and possibly narrow) domain. As you venture further from that domain, things begin to unravel.
Example: after giving a presentation at a recent Rust meetup, someone asked me if they could use Rust as a scripting language. My response was something along the lines of, "sure, it's as Turing-complete as any other language, but why would you want to?" Mostly I would like people to acknowledge that different languages exist to serve different needs, and that there does not and will never exist One Language To Rule Them All.
Rust is a low-level systems language, and it's optimized very, very well for that niche. I'm very happy if you want to use it all time, for everything! But please continue to evaluate it as a systems programming language. There are very good reasons for every feature in the language, but many of those reasons may seem entirely superfluous if you don't appreciate the context in which they were made.
/Scala fan, would and have used it for scripting.
Consider as well that as long as there exist languages that are so heavily-laden with features, there will continue to crop up "minimalist" languages like Go which will appeal to people by virtue of sheer simplicity and eat the lunch of the maximalist languages.
[1] An example: you know one thing that's great about using bash instead of Python for quick scripts? I don't need to put quotes around strings! Imagine how much time you'd waste in your terminal if you had to type `git grep foo -- bar.txt` as `git "grep" "foo" "--" "bar.txt"` all the time (which is valid bash, btw), or worse, `git("grep", "foo", "--", "bar.txt")`. TCL adopted this barewords-as-strings behavior as well, and though I hear mixed things about the rest of TCL this feature has always intrigued me. But this feature would be awful for any language where text input or string manipulation were not the predominant activity, so how would you go about turning it on and off? And even if you provide tools to automatically convert source files between barewords-as-strings and barewords-as-keywords, is that even the same language anymore?
Sure, scripting Scala looks rather different from high-performance Scala. But there's a continuity between them, which allows you to customize the appropriate "dialect" for a particular project, and avoids the overheads of using multiple languages in a project that straddles one of the lines.
> how would you go about turning it on and off
There's already a certain level of syntax customizability in most languages, e.g. I can use an import that will make symbols ('grep) treatable as strings. Whether this is a single language or a suite of languages designed to work closely together is an academic question, but I certainly think it would be possible to write something that allowed you to write (say) C-like code and Python-like code with a much smoother interface between them than there currently is when calling C from Python.
These days I'm dabbling with Go and while the toolchain is fantastic and the standard library is fairly comprehensive, I find the language itself to be "meh".
Rust-the-language looks much more promising but I'm holding my breath waiting until it stabilises before I consider it for my next project. I read elsewhere that they are striving for a near-final release at the end of the year so I won't have to wait long, after all :)
Keep it up!
Most important reason is that I want to keep believing that a (bunch of) genius(es) inventing their perfect language that can be practically and widely used without a big company backing is still a thing
Secondly because these languages have so many great ideas with high quality implementations.
I know there are pockets of D throughout the industry. I know it's catching on at Facebook (and, because I know Facebook folks, I know what an uphill battle those folks are having too). I just don't hear about D nearly as much as I'd expect to over a decade in.
Nothing against D, mind.
IIRC, at the beginning the whole thing was not being developed in the open and the compiler was proprietary (although the front-end became open source at one point).
Those two things (especially the former) pretty much killed it for me.
D finally matured at a time where I was already more interested and invested in the Lisp/ML family of languages, thus I ended up never considering it for a project.
Thanks for sharing such nice little gem.
I do however find the imperative style of programming more efficient, when working with Haskell I always felt like I was fighting it. So perhaps Nimrod may not be for you, but it's still definitely worth checking out!
I did and continue to really like the way they handle encapsulation at the module rather than object level.
The main reason to load up on features is that you are anxious your audience won't like you unless you do, but it is a wrong idea about design.
Wondering if there's a roadmap/ETA for v1.0?
Also https://github.com/rust-lang/rust/issues?direction=desc&mile...
and https://github.com/rust-lang/rust/issues?direction=desc&labe... , which are the most interesting open questions regarding backwards compatibility.
Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.
The reason for the proposal was that (.) for function composition made the grammar more complex or problematic because of the accessing 'operator' (.), and/or something that had to do with more fancy accessing and such (lenses?).
Theoretically it's solvable by requiring whitespace to surround all arithmetic operators, which is actually a bit of an intriguing proposition because it would then also allow you to use dashes in variable names and have it be unambiguous, i.e. `foo-bar/qux - baz / spam` would unambiguously mean "divide baz by spam, then subtract it from qux in the foo-bar namespace". But nearly all languages try to avoid this sort of whitespace dependence (look at the ancient furor over the `> >` requirement in C++), and it would be quite a reach for Rust to start championing it now.
The reason for using :: instead of . for paths is because the Rust developers did not want to conflate path lookup and field lookup, which would obscure the runtime costs of indirection. (This is also the same reason why you can't omit the parens when calling a method with no arguments: a field lookup and a method call have wildly different runtime costs.)
Good to know the reasoning behind ::.
Waiting for Rust 1.0, after it gets released it's Scala for JVM and Rust for everything else (except Qt) :P
(a big issue with []-generics is that they're easy to confuse with indexing/slicing to a human. <> may look noisy, but it's harder to confuse it with comparisons)
Though apparently this couldn't be used in Rust, since they want both traits for indexing ( [] ) and calling like a function ( () ) on types that implement those respective traits.
- Qt core (QList, QMap) can be replaced with Rust std lib
- I don't use QML and Javascript (because Javascript errors don't show up at compile time)
- The only thing missing from Rust is QWidgets, but I'm sure there will be something to replace it
I wouldn't like to use a Rust port of Qt just to get QWidgets for Rust, because it would also mean shipping huge Qt core libraries with my Windows application. I don't need them so I don't want to do that.
QML is the way forward for making GUI apps, you are not supposed to use javascript much (although you can make complete apps with it). You are supposed to have your complex logic in a C++ backend which interacts with the QML frontend.
Maybe QML will have Rust bindings.
Don't worry, once Rust has established a foothold here, then we can start designing the pretty language that will usurp it. :)
Well, like any turing-complete language, technically anything, though Rust tends to be lower-level than most.
What kinds of programming do you like to do?
But I wonder; if these newer 'systems' (which we can define to be very performant, though not necessarily C-level performant) languages are so interesting, why don't any of the older systems languages come up? Like Free Pascal or Ada (I think this language is a 'systems' language in this sense?). Are these languages viable today, if you already can afford to use relatively new languages with all that that entails of lacking libraries etc.? Or are they dead ends? It seems weird to me that when talking about these languages, there seems to just be C/++ and these newer languages, while the older performant languages seem to not come up. Is this because they aren't suitable for most people, or because people don't know about them/forgot about them? I don't know myself, since they seldom seem to come up in discussions on forums like this.
Personally I'm a big fan of Pascal, and I look to Ada sometimes for inspiration (it brought a lot to the table!), but it's quite clear historically that these languages petered off and simply won't get enough momentum to become popular again.
I was talking about them in aggregate, and not all of them seem to have that goal.
That said, in the long run I think the APIs and tooling experience matters. Free Pascal basically hangs on because Delphi did so well as a third-party environment, even though it was always marginalized on Windows for not being a Microsoft-anointed language. But the Delphi experience was related to the era of the Windows desktop application, and when the market's interest moved away from that the magic was kind of lost. Ada likewise has hung on because it has that gov/mil influence behind it - and its ecosystem is still mostly centered around commercial development environments.
Sadly, despite having useful-looking properties, I suspect it'll serve as little more than inspiration for others.