Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go and Rust Are Not Competitors (2015)

dave.cheney.net

Post reply on HN
Print view View original

51–60 of 102 posts

Re: Why Go and Rust Are Not Competitors (2015)

#51

Post by perfmode »

moomin wrote: post #12
vvanders wrote: post #8

Earlier quoted context omitted.

Yup, like the post about Discord processing images from yesterday underscored. If you need top tier performance you're going to have to reach for a language like Rust, C or C++ because without discrete control over your allocations and memory placement you will have something slower. C# is about the closest thing these days thanks to value types but even then Unity had to drop down to C++ to really get the performanc…

Yeah, but it seems to be fine for something like Docker.

Docker is more I/O bound than CPU bound, so Go is just fine.

Re: Why Go and Rust Are Not Competitors (2015)

#52

Post by matt_wulfeck »

namelost wrote: post #31
nine_k wrote: post #5

Earlier quoted context omitted.

They forgot the mindshare of PHP users. The tradeoffs Go makes are rather similar (simplicity, ease of deployment vs expressivenes and consistency).

This actually makes a lot of sense. From the outside, it's hard to see why anyone uses Go. Using Go feels like going back in time 20+ years. However if someone is coming from PHP, Go must look positively modern. Considering the millions of PHP programmers out there, Go can keep on growing for a long time.

Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome standard lib.

Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.

Re: Why Go and Rust Are Not Competitors (2015)

#53

Post by jeremiep »

themihai wrote: post #4
jackmott wrote: post #3

There will be some crossover since Go's AOT compilation and low latency pause times will make some things that needed to be done in C++ or Rust viable in Go.

>> make some things that needed to be done in C++ or Rust viable in Go. like "micro controllers, AAA game engines, and web rendering engines"? I highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).

I don't see Rust as ready for AAA game engines, not by a long shot.

Last I checked it had absolutely terrible reflection capabilities and meta-programming; both of which are used as the foundations of modern engines.

A game engine is also radically different than your usual use of Rust; its almost impossible to model with borrows without going dynamic and those come with runtime overhead; something not acceptable when you're used to zero-cost abstractions.

A web rendering engine has ridiculously less state and moving parts than a game engine. D would be a much better fit for game engines than Rust.

Re: Why Go and Rust Are Not Competitors (2015)

#54

Post by unscaled »

Scarbutt wrote: post #10
kgthegreat wrote: post #2

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering engines. Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and N…

Curious, what are the "high deployment costs of JVM based languages"? Don't must standard workloads simply deploy a jar?

Without using containers or fragile (and not very portable) executable wrappers you need to manage the JRE, JAR files and the right classpath.

With go you can just run 'go build' and get static executables for all common platforms with zero dependencies.

The key difference between that and just throwing jar files on random systems is that static executables truly work anywhere and will never crash because you don't have the right version of JDK and usually won't need messing up with arcane command line parameters or .properties files.

Deployment is one area where Go truly shines and I guess that helped its popularity. PHP also got immensely popular due to ease of deployment, although of a different kind, in a different era and with different expectations.

Re: Why Go and Rust Are Not Competitors (2015)

#55

Post by zzzeek »

jeremiep wrote: post #43
Scarbutt wrote: post #10

Earlier quoted context omitted.

Curious, what are the "high deployment costs of JVM based languages"? Don't must standard workloads simply deploy a jar?

Most likely some old myth regarding the JVM. Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer. I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.

The unbelievable irony I'm observing with the Java-based things I need to deploy these days (Jenkins and Gerrit related) are that quite often they're making me build something, which then fails due to weird maven issues I don't understand (since I haven't been a Java dev since the ant days).

The entire point of java was that bytecode is portable, it's "write once, run anywhere". Don't make me build your stupid .jar and figure out all your dependency / build-time issues, just give it to me!

Re: Why Go and Rust Are Not Competitors (2015)

#56

Post by jeremiep »

vvanders wrote: post #8
themihai wrote: post #4

Earlier quoted context omitted.

>> make some things that needed to be done in C++ or Rust viable in Go. like "micro controllers, AAA game engines, and web rendering engines"? I highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).

Yup, like the post about Discord processing images from yesterday underscored. If you need top tier performance you're going to have to reach for a language like Rust, C or C++ because without discrete control over your allocations and memory placement you will have something slower. C# is about the closest thing these days thanks to value types but even then Unity had to drop down to C++ to really get the performanc…

I wrote the most non-idiomatic C# in Unity to create a lighting fast 2D skeletal animation system (100-1000x the performance of the closest competitor) and I'm certain I could've gained yet another order of magnitude had I access to C++ instead of C#.

C# is fine for scripting, but absolutely terrible for performance critical batching where branch predictions and cache misses are your main optimization points.

Also the lack of array slices make it really hard to avoid memory allocations.

Re: Why Go and Rust Are Not Competitors (2015)

#57

Post by jeremiep »

zzzeek wrote: post #55
jeremiep wrote: post #43

Earlier quoted context omitted.

Most likely some old myth regarding the JVM. Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer. I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.

The unbelievable irony I'm observing with the Java-based things I need to deploy these days (Jenkins and Gerrit related) are that quite often they're making me build something , which then fails due to weird maven issues I don't understand (since I haven't been a Java dev since the ant days). The entire point of java was that bytecode is portable, it's "write once, run anywhere". Don't make me build your stupid .jar…

I don't think Jenkins is a good indication of modern Java :) If anything Jenkins is a hairy ball of mud you should try to avoid :p

I write exclusively Clojure on the JVM now; its like having all the advantages of the JVM and none of the inconvenients of Java!

Re: Why Go and Rust Are Not Competitors (2015)

#58

Post by vram22 »

oconnor663 wrote: post #37
kgthegreat wrote: post #2

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering engines. Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and N…

I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python. If that's right, it might be fair to say Rust and Go were "originally" competitors, even if they aren't as much anymore :)

Ha ha, my edit and your reply (which you later deleted) crossed in time, due to my messing up my original post a bit w/copy+paste :) Sorry for the confusion. Anyway, point made clear. I found Rob's statement surprising too. But also, I heard from Josh Fraser, founder of Torbit (acquired in a relatively short while after being founded), that they decided to use Go because it has a good balance between the performance of C and the productivity of dynamic languages like Python and Ruby.

Re: Why Go and Rust Are Not Competitors (2015)

#59

Post by vvanders »

jeremiep wrote: post #56
vvanders wrote: post #8

Earlier quoted context omitted.

Yup, like the post about Discord processing images from yesterday underscored. If you need top tier performance you're going to have to reach for a language like Rust, C or C++ because without discrete control over your allocations and memory placement you will have something slower. C# is about the closest thing these days thanks to value types but even then Unity had to drop down to C++ to really get the performanc…

I wrote the most non-idiomatic C# in Unity to create a lighting fast 2D skeletal animation system (100-1000x the performance of the closest competitor) and I'm certain I could've gained yet another order of magnitude had I access to C++ instead of C#. C# is fine for scripting, but absolutely terrible for performance critical batching where branch predictions and cache misses are your main optimization points. Also th…

Yeah, that's my biggest gripe with the "GC'd language are as fast as native" crowd. You end up doing all sorts of contortions in order to get the allocation/cache coherency that you need that you're better off using a language that has proper support for it.

I love scripting languages for orchestrating logic(luaJIT!) but when you need to massively vectorize your data so that you get full utilization of the prefetcher there really is no substitute.

Post reply on HN