Hacker Newsnew | comments | show | ask | jobs | submit login

The two languages aren't really in the same space in the first place. Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all.

Go is a great language -- I greatly admire its simplicity -- and for its domain it's fantastic. Rust is in a different domain: low-level systems programming in which abstractions must be zero-cost and control over the machine is crucial.




Go actually provides what I believe to be zero cost abstractions that map straight to the c memory model, making it very easy to use for systems programming.

If you want a fixed size array of bytes, for for it. Zero overhead. If you want a slightly smarter list you can use a go slice, which is also pretty low overhead. I've personally verified that if I create a struct in go it takes up the exact same amount of memory as the same c structure.

As a concrete example, I recently built an interface to kernel crypto apis using pure go (no cgo). There's no magic to go data structures, you can define structs in go and pass pointers directly to syscalls (through the syscall package) and everything just works. Dealing with large arrays of binary data is similarly straightforward. So go does give you complete control over memory layout if you choose to use it.

The elephant in the room is that go does have garbage collection, and that ain't free. Practically you can minimize it's impact by managing your own memory. In fact that's what Brad Fitzpatrick is doing with his go based memcached implementation.

It all boils down to how you define systems programming. I guess if you mean is go suitable to write a kernel in, the answer is probably no, (but it would sure be fun to try). If systems programming requires having the complete ability to interact with the operating system and all syscalls + tight control over memory layout, then maybe go is the way to go.

https://github.com/shanemhansen/gocryptodev/

[edit]

with respect to python and garbage collection, did you know you can actually turn it off? If you have no cycles in your program you can turn off gc and let the ref counter clean up all your data, similar to Objective-C's ARC.

http://docs.python.org/library/gc.html

-----


There is a lot more to zero-cost abstraction than memory layout. If you do manual memory management in Go, then you get no safety. It is also difficult to use the standard library with manual memory management. Furthermore, interfaces in Go are not zero-cost; you incur virtual dispatch whenever you use them.

The article is about doing safe manual memory management. That's something that's unique to Rust.

-----


FWIW, Rust's arrays and structs are also laid out in memory exactly as C's are.

-----


> The elephant in the room is that go does have garbage collection, and that ain't free.

Since HN is Lisp country, it has to be said that having GC isn't an "elephant in the room" - though a slow GC implementation may be.

-----


> If you want a fixed size array of bytes, for for it. Zero overhead.

There's the overhead to check the bounds on operations in that array, which you don't have in C.

-----


Simplicity is absolutely the most crucial aspect of a language used for successful commercial application in my space (15-30 mil annual). That's what I like about Go. Don't know much about Rust, but if it's being designed by a small group of engineers who think oop is still awesome, then successful commercial software developed in Rust will be just as costly to maintain as the 500k to 5 mil line codebases I run across today, written in currently available languages.

Speaking in general:

You get all this wonderful language functionality, and I promise you that you will write some shitty code at some point just to keep up with the daily pressures presented by a successful software package (clients screaming, salespeople breathing down your neck, etc), I don't care how good of an engineer you think you are. What's really funny is that, because everything has gotten so much more complicated (dev tools, business, cost of bugs going up, how to make money with software, whatever), the successful software I work on today is not making any more money than the successful software I worked on back in the late 80's running under DOS. Back then, the oop free tools and the target os were simple enough that we really could become SME's on our domains as well as on the dev tools we used to write code for those domains.

C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years. If Rust is just trying to be smarter at what these languages already do, I'm not interested. Something has got to come along which simplifies development, especially concurrency, and allows programmers of varying skill levels to write productive code in. Then after 5 mil loc, programmers coming and going on a project, an app doesn't end up looking like a fragile mess.

-----


Rust is not particularly object-oriented; idiomatic Rust code leans more toward the functional style as opposed to the OO style.

The language is designed to make it harder to write buggy code at the cost of some amount of language complexity. Whether this is an acceptable tradeoff will depend on your particular situation.

-----


>C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years.

That doesn't even make sense. Both C# and Java (and JVM, CLR languages) will be used in new billion generating applications in the next 10 years and more.

-----


I should have said "generate competitive revenue." Sorry about that.

If you're still using C# or java in 10 years time for a commercial app, the only reason you will not be at a competitive disadvantage is because all the other competitors in your space are using the same languages.

-----


> programming in which abstractions must be zero-cost and control over the machine is crucial

How well does Rust do in this zero (or low) cost department? In C++ STL there's the same goal, but it compiles to code very far from what you would write in assembly without abstractions.

Eg. how are code compactness and data layout optimizations?

-----


Not sure what you mean here. Rust tends to be pretty dependent on inlining optimizations, just as C++ is. As for code compactness, the way we do task failure leads to significant code bloat at the moment (though that's on track to be fixed, and the code is off to the side and not executed unless you actually fail). As for memory layout, the rules follow C; struct fields are laid out in the order you specify them in the code, and so on.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: