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

21–30 of 102 posts

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

#21

Post by vvanders »

nine_k wrote: post #14
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).

Many controllers are not hard-realtime. Think e.g. of microwave ovens or smart locks. Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.

Many controllers have almost zero memory headroom meaning your GC pauses get an order of magnitude slower if not more as you have less than 2x your working set.

Also, most of the applications never allocate because they can't even afford the overhead of pooling/freelists that come with a stock malloc implementation.

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

#22

Post by mtgx »

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

A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?

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

#23

Post by dyladan »

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?

I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.

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

#24

Post by 3pt14159 »

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.

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

#25

Post by jackmott »

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

Like AA games/game engines, and some micro controllers sure. Desktop applications like text editors where waiting for JITs and high pause times are annoying unlike things running on server as well.

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

#26

Post by nine_k »

mtgx wrote: post #22
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).

A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?

How would you handle plugins? Some kind of cheap local RPC would probably be fine from both the complexity and the performance POVs.

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

#27

Post by systems »

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

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

#28

Post by woah »

nine_k wrote: post #14
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).

Many controllers are not hard-realtime. Think e.g. of microwave ovens or smart locks. Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.

I’m developing software for WiFi routers. I would have liked to use Go but the binaries are simply too large and compilation is sketchy for ARM.

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

#29

Post by k__ »

zaarn wrote: post #19
k__ wrote: post #13

Earlier quoted context omitted.

I saw a tweetstorm by a longtime Go user who listed all the flaws and inconsistencies of the language. In the end it didn't look much better than PHP to me. Which is surprising, since PHP is a "grown" language and go has been "designed" by some longtime languages pros.

A lot of complaints usually affect niche or rare use cases in the language (or you learn them fast). Though I guess the same applies to PHP. It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP) Also the stricter type system…

Yes, I'm not a big fan of PHP either.

Guess the global state access and easier parallelization are the main selling points.

I wrote a few APIs with long running queues in PHP and Node.js and found it both a bit too clunky for that job.

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

#30

Post by geodel »

mtgx wrote: post #22
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).

A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?

Perhaps this: https://gohugo.io/

There are bunch of comparisons Hugo vs Wordpress on internet.

Post reply on HN