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

31–40 of 102 posts

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

#31

Post by namelost »

nine_k wrote: post #5
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…

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.

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

#32

Post by k__ »

systems wrote: post #27

They are both being used, where C and C++ were the only alternative Some of the points to be made here is that C and C++ are being used for a very wide range of applications So if you do compare Go and Rust, you will find distinct technical advantages and disadvantage Rust/Go are currently the C/C++ alternative

But it seems to me that Go is used especially by non C/C++ devs.

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

#33

Post by geodel »

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?

To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.

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

#34

Post by k__ »

3pt14159 wrote: post #24

I actually think that in the long run Rust and Go will have a similar relationship between Ember and React. They'll have fundamentally different approaches, but they'll steal the best ideas from each other (for example, Glimmer is heavily influenced from React) and they'll both end up serving their domains better and maybe overlapping a bit more here and there.

lol, good comparison.

But what did React steal from Ember and what did Rust steal from Go?

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

#36

Post by eric-hu »

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.

Sounds like you're advocating a Rocker project.

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

#37

Post by oconnor663 »

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 :)

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

#39

Post by oconnor663 »

> Go is focused on concurrency as a first class concept. That is not to say you cannot find aspects of Go’s actor oriented concurrency in Rust, but it is left as an exercise to the programmer.

To be fair, concurrency is baked the Rust type system itself. It's certainly a first class concept. I think the better way to describe it is that Rust wants to make concurrency safe regardless of what mechanism it's based on (system threads, futures/asyncio, maybe other things eventually?), while Go wants to provide a particular (very convenient) mechanism as part of the language.

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

#40

Post by hinkley »

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?

Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8.

They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.

Post reply on HN