Hacker News Reader

Comment by oldmanjay | Hacker News Reader

of course, if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way, go isn't ready at all.

it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.

View on HN

> go isn't ready at all

It's ready when people use it in production.And that's the case so it's ready.

> it does have some marquee names behind it,

So does Rust,or are you saying Mozilla isn't a strong brand?

I don't think its fair to compare both anyway.

Rust looks like it wants to compete with C++, while Go is used by scripters coming from Ruby,Python,Js and PHP. Go devs aren't interested in memory unsafe programming.

you skipped the "if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way" part.

> you skipped the "if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way" part.

You skipped the fact that user oldmanjay heavily edited his message, and the current one has little to do with the one I answered too. Not going to edited mine, I quoted his previous message and answered to these specific points.

"go isn't ready at all" is still a substring of the parent comment, so one perfectly valid interpretation is that the quote was taken out of context, especially since HN provides no edit histories or even indication of edits.

> you skipped the "if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way" part.

Was not part of the original comment I answered to.

Go performance is going to converge on C performance with new optimization's being written after go 1.5.

Any gains from rusts expressive type system are lost by all the memory lifetime annotations imo.

I still think rust is probably going to be the best language for embedded software like router firmware, as they need to be fast, low overhead and secure.

As an upper performance bound for a GC language, I don't think Go will be able to surpass C# (which has stack allocation in the form of structs, ahead of time compilation, and many other goodies). Rust, on the other hand, has more potential as a non GC language, though at the end of the day it might be hard to tell given equivalent applications.

The upper performance for garbage collected languages (and rust) is potentially higher than C. The reasons are non aliased pointers allow more aggressive optimization, and batched garbage collection plus memory compaction can perform better than regular mallocs.

Rust still has these advantages though, time will tell. Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.

Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators. The Servo team tells me that bounds checking has never shown up in any performance profiles.

"Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators."

Can you explain this or point me to the relevant documentation or code please?

The documentation on iterators describes the advantages of using iteration rather than direct indexing in a loop: http://doc.rust-lang.org/nightly/book/iterators.html

The gist is that an iterator has enough information about the thing that it's iterating over that we, as library authors, can avoid unnecessary bounds checking and just perform unchecked indexing while retaining all the safety. LLVM is also surprisingly good at automatically vectorizing our iterators.

Thanks!

I wonder if after Mozilla writes Servo in Rust 1.x and Google sees how fast Servo is, even compared to its own JS engine, it will also consider writing a new JS engine in Rust 2.x (I assume, by then), as I doubt they'd use Go for that. Same for the whole browsers. Due to the safety features of Rust over C++ we might see both Firefox and Chrome be rewritten in Rust over the next 5 years.

Servo isn't a JS engine, it does make use of Firefox' SpiderMonkey, written in C++.

you might want to check this out

http://c2.com/cgi/wiki?SufficientlySmartCompiler

Thanks, A good page.

> The reasons are non aliased pointers allow more aggressive optimization

Rust's type system is all about controlling aliasing. But virtually all garbage collected languages, including Go, have much weaker aliasing guarantees than C does. At least C has "restrict".

Granted, if you compile with "-fno-strict-aliasing", a C compiler will have a tougher time of alias analysis, but that isn't strictly C anymore.

In any case, alias analysis here has nothing to do with garbage collection and everything to do with type safety.

> Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.

In most cases using iterators will avoid them.

>As an upper performance bound for a GC language, I don't think Go will be able to surpass C#

I don't know how well Mono C# compares to Microsoft's version, but looking at:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Shows that Go certainly beats Mono #C in these benchmarks (often by a very wide margin).

From a technical standpoint I don't see any reason why Go would not be faster than C#, how would 'ahead of time compilation' bring C# a performance benefit over Go ?

Mono is considered slow in the .net world. Lets hope the new stance on open source makes things better.

Go and C# are dealing with similar constraints, there is no language design advantage in go with respect to performance, and the resources applied to implementation are similar.

> Go performance is going to converge on C performance with new optimization's being written after go 1.5.

Do you have more details. It would seem like it would be rather difficult to do that. Sure it can rival Java in some workloads, but C performance is a tall claim.

Go is currently pretty fast, maybe half as fast as C. There is a new backend for the Go compiler being planned which uses more modern techniques.

This plan[1] estimates at 10 percent speed improvements initially, I just think they will continue to progress further over time once the SSA framework is built. They will be able to port essentially every optimization llvm uses eventually, and add a few new ones that can rely on memory safety and pointer aliasing guarantees Go provides.

Go can also do whole program analysis with the ssa form because all source is present at build time.

An addition of a moving garbage collector may also improve cache locality. We will see, google cares about making servers efficient, as it saves money in power.

[1] https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...

That makes sense Andrew, thanks for explaining.

What guarantees does Go provide about pointer aliasing? I have no production code in Go, but from what I have played with, Go has no way of indicating that a pointer is not aliased, so how can it optimize that, other than through static analysis, which will not catch the majority of cases.

I ctrl-f'd "alias" on your paper that you linked, and no mention is shown.

edit: in fact, I forgot to look for "escape analysis." So it does get mentioned, but only to point out that it is a non-goal of the project.

Go just guarantees different typed pointers don't alias, I think C has a flag to allow this assumption though.

Reply on news.ycombinator.com