Computer Language Benchmarks Game – Rust vs. Go
benchmarksgame.alioth.debian.org
benchmarksgame.alioth.debian.org
Go is a modern scripting language, stripped of the features that make scripting languages impossible to multithread and intrinsically slow, statically typed, and with things built on top of the multithreading. (The Perl/Python/PHP/etc series of languages is very heavy weight, huge VMs, dynamic everything, and while if you started from day one to write one of them to be threaded you could probably do it, bodging it on after the fact was virtually impossible. IMHO "dynamic everything" turned out to be a great deal more dynamic than was really necessary. But it was a worthy experiment!) Rust is a C++ replacement. Go is very fast relative to its real competition, but it is certainly not a C++ replacement. It also seems to me that Go is likely to converge on being easier to develop; I don't think Rust is going to get all of this quite for free. Both will sit on an interesting part of the bang-for-the-buck curve that is currently not well-occupied. That is, it is occupied, but it is not well occupied.
Perhaps even more interesting is how gcc C consistently outperforms g++ C++ (and Rust, for that matter).
In fact if one was to group Go with other languages, those two would make sensible comparisons
Well, as I sort of implied but will now spell out, the 1990s produced a certain stereotypical definition of a "scripting language" that I think is ultimately overspecified. A 1990s scripting language is extremely dynamic, including the type system, everything's boxed, everything's a hash table of one form or another, and in general everything converges to produce a language that is very fluid, but ultimately very slow. These were overreactions to the languages of the day, which were, I think, easy to forget how hard they were to use in practice. Even when you use C or C++ today, you're still using it with radically better community best practices, libraries, and better tool support. 1990s C++ was some hard stuff to work with even before you let threading in. Into that world, Perl and Python were a breath of fresh air!
It is easy to get deceived by the constant stream of benchmarks that are 50% faster than last month and the constant stream of incredibly-micro micro-benchmarks where JS or something is as fast as C at adding together small integers in an array or something. The reality is that after years and years and years of work, they're fundamentally slow. Yes, even Javascript; remember, for asm.js to produce such fantastic speedups, Javascript must be leaving that much performance on the table.
Go ends up in practice working very like a scripting language; line counts are virtually identical in my experience, logic is very similar, and the fluidity is there, partially by virtue of ignoring the very things that Rust brings out and makes explicit (the ownership and such). I can't say with a straight face that the logic comes out the same, the way a Perl program can be virtually transliterated into Python, because the ability to use concurrency seriously means that you don't have to bend into the contortions you sometimes do to simulate it in those older languages, but otherwise it works similarly, except that you use structs and interfaces instead.
Scripting 1.0, being made when this world was younger and 150MHz was a fast machine, made some mistakes in thinking that compilers would eventually be able to overcome their fundamental weaknesses. It was a neat experiment to make everything wildly dynamic, but in the end, you end up paying and paying and paying and paying and paying for that dynamism, but you only use it rarely. You may be inclined to object, saying "I use it all the time! I use Ruby gems to assemble all sorts of complicated and interesting objects!", but that's because we humans are really bad at order of magnitudes inside of programs... you set up your objects essentially once at the "beginning" of some computation, then you pay for that dynamism billions of times. You pay for the awesome exception handling all the time, yet only use it rarely. You pay... etc.
Scripting 1.0 also accidentally interpreted the failures of the languages of the day, which were all statically typed, as being significantly caused by static typing. I'd suggest we've since learned that the static typing of the time was simply bad; the languages are not all that great, and the ways they were used even worse (inheritance favored over composition, etc.). So they whiplashed wildly to the opposite, which turns out to have been an overreaction similar to the previous paragraphs. You pay for all that typing dynamism all the time, yet in practice, legal inputs to a given function are characterized by a limited number of types, legal outputs also, and all this dynamism is really going to waste. (Go's interfaces capture %95 of the use cases here while still being perfectly statically typed. There are other possibilities as well for other languages to explore.)
Scripting 2.0 is fixing that problem by creating languages that judiciously use dynamism instead of indiscriminately slathering it everywhere, that are merely somewhat slower than C rather than the night-and-day of 1.0, are still fairly easy to program in even if they are not as wildly dynamic, and execute an order of magnitude faster than Python or Perl or JS while also obtaining the advantages of more static typing for software quality. Go is merely the most prominent of this line of language, there's a whole bunch of them bubbling up right now. Julia is trying to fit into this for numeric computing, LuaJIT is sitting there sipping the punch wondering why all the other languages are so many years late to the party, there's another language that's popped up on HN every so often in the past few months that fits in here but escapes my mind, and I think we're going to see more of this. With computer processors speeds having stalled it becomes a difficult proposition to go up to a programmer and promise them the moon, and all they have to do is be willing to be 20-100x slower than the competition, and, uh, well, no, you won't just catch up in 5 years of processor advancement because raw clock speeds are stalled.
So I find in practice Go is a Scripting 2.0 language. You write it at roughly Python speeds, it runs much faster and works much better in the cloud where that actually matters, and part of the way it accomplishes this is to do things like gloss over memory management details and exactly how interfaces are satisfied (dynamic lookup at runtime, compare with wycat's comments in the thread on how Rust does it), and generally focuses on being relatively easy and fast to write. Looking at it from another direction, compare Go to Rust and Go looks more like a scripting language than a competitor to Rust.
I could write a similar post on how Rust is also a harbinger of a new wave of languages that are trying to replace C++, but make it easier to write correct code than to write incorrect code. (C++, alas, makes both quite easy, and makes it hard to tell which is which. It is true that correct code is possible, but it takes more skill to get there than it should.) Nim, for instance, fits into this mold, though a great deal less popular. I expect more. The dependent type community is also struggling mightily in the direction of putting this sort of thing out, and I wouldn't be surprised to see something moderately practical pop out in about 5 years or so.
I know the narrative right now is that Rust and Go are in some sort of fierce competition, but personally I see a world where they live in harmony, with a great deal less overlap than most people currently see, just as Python would still not displace C even if it were in fact 25 times faster.
It's really quite an exciting time and I can't wait to get my hands on these languages. I am ready to leave C and C++ behind. Of course I've already got Go in hand, but I look forward to Rust. (As I am personally a "cutting edge" but not a "bleeding edge" sort of guy in language choice, Rust and I are not yet a match. I consider this just a matter of time.)
All just my opinion, of course. I am not the keeper of the term "scripting language." YMMV.
You can't call a language that is compiled, GC'ed, statically-typed, good concurrency model a 'scripting language'.
Some people argue python isn't a scripting language, because it 'compiles' to byte code.
What is the defining characteristic of a scripting language for you?
That it runs in an interpreter? That you distribute source code files that are executed by a monolithic binary? That you can't compile it into a static binary?
java, lua, javascript, perl, python, make, awk, powershell?
Which of these doesn't tick at least one of those?
The point the parent post is making is that 'scripting language' is an arbitrary term that isn't well defined. It tends to traditionally mean "relatively easy to code in language that runs slowly and has a horrible syntax". ie. bash scripts, perl scripts, make files and the like.
...but technically speaking, what makes these 'scripting languages' as distinct from other languages, like say, java? Or, indeed, go?
The parent isn't arguing that go is a scripting language (I wouldn't say that either), but that it shares some common features, both good and bad (ease of writing, gc) with some other 'scripting languages'.
And that the useful criteria are changing, as in my reply to Retra. Who in 2014 is sitting here selecting a language based on whether or not it is "compiled" or "interpreted" as opposed to picking it based on libraries, or simple real speed (as opposed to worrying about where the speed comes from)? Who saw the wave of Javascript JIT interpreters and yelled "Crap, there goes Javascript, because now it's 'compiled' and that change now makes it suck"? The way we're going to be characterizing language families in 2020 will make such 1990 concerns look quaint and there's little reason not to start thinking about it now, since 2014 looks more like 2020 than 1990.
I don't see how inventing terms like "scripting 2.0" makes anything clearer. It just reeks of unjustifiable rationalization and square-peg-round-hole thinking.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
If you want to play Perl golf, Perl will blow it away. Then again, my well-written Perl and Go come out pretty similarly.
That's not to say that I think Go and Rust are the same classification of languages though. I think "scripting vs compiled" is an overly simplistic view. Go compares better against the byte-code AOT compiled languages such as C# and Java. These kind of languages are also seen in some traditionally scripting-dominated markets (eg web development) while still being used as systems languages as well.
"Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, was Perl. Tcl is the scripting language of Tk. Java and Javascript are intended to be the scripting languages of web browsers." (from Being popular, http://www.paulgraham.com/popular.html)
Love the post. Were you thinking of Nim [1]? It recently benchmarked close to C++ in speed [2] and it will assuredly continue gaining ground.
import rdstdin, strutils
let
time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt)
hours24 = time24[0]
minutes24 = time24[1]
flights: array[8, tuple[since: int,
depart: string,
arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."),
(583, "9:43 a.m.", "11:52 a.m."),
(679, "11:19 a.m.", "1:31 p.m."),
(767, "12:47 p.m.", "3:00 p.m."),
(840, "2:00 p.m.", "4:08 p.m."),
(945, "3:45 p.m.", "5:55 p.m."),
(1140, "7:00 p.m.", "9:20 p.m."),
(1305, "9:45 p.m.", "11:58 p.m.")]
proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int =
hours * 60 + minutes
proc cmpFlights(m = minutesSinceMidnight()): seq[int] =
result = newSeq[int](flights.len)
for i in 0 .. <flights.len:
result[i] = abs(m - flights[i].since)
proc getClosest(): int =
for k,v in cmpFlights():
if v == cmpFlights().min: return k
echo "Closest departure time is ", flights[getClosest()].depart,
", arriving at ", flights[getClosest()].arrive
[2]: https://www.reddit.com/r/programming/comments/2pvf68/armv7_v...
Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on.
While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
For a given piece of code as written today, its compilation speed will naturally improve over time as processors get faster. Optimizing it to a certain degree becomes faster for the same reason. Therefore, assuming a fixed threshold for what constitutes "fast [enough] compilation", potential for more optimizations becomes available over time.
> However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
That's true for many languages, including PHP or Perl. The problem is: once you use these languages more, you discover that most people don't do it (for various reasons, one of them often being that they're trying to be clever).
Go has a better syntax that rust, objectively, because it refuses to create new operators that are not orthogonal to existing ones. That makes it easier to parse because there are fewer 'code synonyms' (eg. the rust Fn<(Arg1, Arg2), (Rtn)> is identical to Fn<Args, Arg2> -> Rtn; to be fair go has its share of these irritations as well; eg. x := 1, vs var x = 1; but fewer of them)
It's got nothing to do with how pretty or ugly the code is.
Also what is stopping a LLVM backend for Go being developed?
He later regret it but it's too late everybody just bench Go with any system language there is out there.
Go is better off as a middleware language that rival that of Node.JS (javascript) imo. Everybody see Node.JS (javascript) as somesort of web dev language in the same vein as Ruby, Python and PHP. But the web frameworks out there that I've seen are mostly incomplete or just very bare bones compare to RoR, Django, and Laravel. Express is very very barebone and you wouldn't prototype with that or do anything quick with that. You can argue that would use Node.JS for long term stuff and my counter point would be if your code have to survive for more than 6 months then use a type language. I don't believe a dynamically loose type language such as Javascript is suitable. Go would be better in this regard.
I'd like to see Rust vs Ada vs C++
The point of the Node ecosystem is to be library-based. It's quite rare to have full-fledge frameworks dictate an environment like Rails does (and a method I personally hate). Go has the same principle afaik with it's web libraries.
I'd personally rather use a dynamic language rather than a statically-typed one with a weak type system. While the former can produce more errors at times, the later is often times just too inflexible and painful to use properly.
But, this turns that on its head. Microbenchmarks are, of course, to be taken with a grain of salt, but it's still a useful data point. More useful would be a discussion of why it is so.
But, if it is the primary source, it would tell me that Go will close the gap as the compiler becomes more advanced and takes advantage of more CPU optimization features. Also, it's an interesting difference that Rust is an LLVM language while Go is compiled to native code directly; probably not from a performance perspective (at least not in the long run), but from a development perspective...is it easier or harder to develop new language features on LLVM or a native compiler?
https://groups.google.com/forum/#!topic/golang-nuts/NSPcEqhe...
That is to say: there's not much difference for difficulty of developing new language features, but avoiding LLVM makes it harder to develop new fast language features.
That isn't always going to mean that Rust code is faster, but for benchmark games like this, when Rust is slower it almost always means that the benchmark is wrong.
As for dynamic dispatch...does Rust not support it, or is there some language construct that allows solving the problems dynamic dispatch solves without imposing annoying limitations or needless verbosity? And, aren't there fast implementations of dynamic dispatch?
Rust supports dynamic dispatch if you truly need it, but the normal approach is to use trait bounds, which the compiler expands when used. Here's an example:
fn main() {
let r = MemReader::new("hello world\n".as_bytes());
get_line(&r);
}
fn get_line<R: Buffer>(r: &R) -> IoResult<String> {
r.read_line()
}
In very rare cases, you may want dynamic dispatch. For example, imagine you have an array of Buffers, and want to read a line from each of them. In this case, you use a "trait object" (a `Box<Buffer>`), which moves the object to the heap and allows dynamic dispatch.
In practice, I have written many thousands of lines of production Rust code and have only encountered a need for trait objects a handful of times. This means that idiomatic, normal Rust code is stack-allocated and statically dispatched.
The verbosity of trait bounds has decreased more and more over time, and my favorite proposal (by aturon) for making it pretty close to maximally ergonomic is:
fn main() {
let r = MemReader::new("hello world\n".as_bytes());
get_line(&r);
}
fn get_line(r: &impl Reader) -> IoResult<String> {
r.read_line()
}
Permalink to the relevant section of the Go source, with descriptive comments: https://github.com/golang/go/blob/04cf881fbea55d5bca584c78b1...
Go is explicitly meant to have _really_ fast compilation times, which precludes the Go compilers from any expensive optimisations. Rust, on the other hand, has an explicit goal of being as fast as idiomatic/safe C/C++ while removing the burden of writing the safety yourself, so it really _has_ to be fast.
If automatic memory management is built in, that adds some overhead to most allocation situations(and encourages an architecture that exploits easy allocation - e.g. Java libraries where everything you do involves a new()). There are differences between garbage collection(mark-and-sweep) and reference counting as well; an RC system is "pay for what you allocate" with predictable scaling, making it more appropriate to employ for hitting real-time deadlines, however, the state-of-the-art in generational mark-and-sweep GC does better for average case throughput. Or to put it another way, if you have a single batch process that everything goes through, you can usually count on a GC system doing it faster than a RC equivalent. But if you want to run several things concurrently and tally results, or you are running an interactive app and care about getting your latency numbers down, the pauses involved in GC may be more problematic to you. (The semantic downside of RC, which has also made a lot of languages avoid it, is its inability to deal with circular data references.)
Of course, manually managed memory lets you design any allocation strategy you want, and so it can let you blow away automatically managed systems on microbenchmarks like these - stuff that starts mattering in the real world only after you've scaled up near to the constraints of the target hardware and any overhead is a Really Big Problem. There's definitely some more experimental automatic technology out there that "breaks the rules," but in terms of what you see in today's production environments, you can start estimating performance characteristics just by knowing what type of allocation is being done.
The other big issue, of course, is the type system. The design of the type system determines the constraints and difficulty of automated optimizations; classically, Fortran was one of the best languages for low-level optimization because it made things very easy for the compiler, and offloaded many considerations on the programmer. Today C has grown into a roughly equivalent space(pointer aliasing, the last big issue, was tackled in C99). Rust can do everything C does, but it also has a much smarter type system backing it up and enforcing memory safety. Dynamically typed languages like Python, Ruby, Lua etc. are essentially always slower and more memory-hungry because of their intentional flexibility - to do as much as they do at runtime, they end up retaining more stuff per piece of data and paying a bigger cost to manipulate it. Luajit is an example of best-in-class technology for dynamic languages, and it's still not as fast as Go on most of the benchmark game. [0]
Where Go stands in these two concerns is roughly comparable to Java or C#: it uses GC, and it has an intentionally simplistic static type system which points you towards built-in data structures, which makes it easy to work with for average-case situations, but hard or impossible to "tune up" as needs grow more complex. And if you check the benchmark game, all three are in the same window of performance, with some variance that could mostly come down to implementation detail.
[0] http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...
This is why I have hopes that Rust will make it easier to match the performance of micro-optimised C code in the future whilst still maintaining clarity and safety (the compiler knows more invariants about the code, so can be more aggressive in its optimisations).
Your hunch/gut feeling seems to be very off.
Also, which benchmark did you have in mind when you said unsafe code is mandatory?
[1] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
[2] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
[3] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
Same is the case with spectral norm. It is unsafe rust beating safe go there too.
Small, widely-verified blocks of unsafe code should be the norm if unsafe code is necessary. This does not mean "if you're using unsafe you've failed!"