Hacker News Reader

Comment by Animats | Hacker News Reader

Yes. The sell point of Go was supposed to be the queue type concurrency model. But that turned out to be marginal. In practice, programs use shared data and locks.

The real advantages of Go seem to be that it's reasonably simple and comes with solidly reliable libraries for web server side applications. The libraries are used internally by Google, so you know they've been exercised thoroughly.

With Python and Rust, there seem to be multiple packages for everything, and you get told "Oh, you shouldn't be using X, you should be using Y".

(Back in 2012, I filed a Python bug report on parsing ISO 8601 date strings. I'd found four library functions for doing that, all with bugs. Fixed in 2018, after years of bikeshedding.)

View on HN

Goroutines are still pretty darn light-weight and relatively "easy" to use. Compared to processes and threads, you can spawn thousands+++ with sane defaults and minimal overhead on crappy hardware. Having decent stdlib-support for things like mutexes and sync.pool, means using what works. But yeah, channels and "synchronization by communicating" was heavily oversold, more as a cool idea than anything to cargo-cult. There are many other mechanisms offered in standard lib that may be used to improve scalability and performance. Overall, Golang is overall "good" in many areas, do have some snags (but like in C/C++ these provides you with some lower-level control), though will not approach C-performance. So it's a trade-off to be able to use those sane defaults until bigger foot-guns are really, really required (avoiding premature optimizations).

They're really "green threads" or "fibers". Remember those? With a good way to avoid blocking on system calls, which Go has, it's a much simpler way to do sequential operations. No need for state machines, "promises", "futures", "async", or all the other hacks used to hammer an event driven model into a sequential model.

Goroutines are multiplexed by M:N scheduler and do not belong to a particular OS thread, so the builders chose a custom name for it.

What does go solve that kotlin + the jvm libraries ecosystem doesn't?

Not needing to install/update a runtime on the target machine is an enormous win for shipping client-side software. For server-side software, maybe it's a small win. (If all you need to worry about is your own proprietary server environment, that's not a big deal, but shipping open source software that depends on the JVM leads to a lot of extra installation instructions and bug reports.)

The latest versions of Kotlin support multiplatform programming (and hence native compilation) and this feature is actively under development. The JVM is not necessarily needed if you go that route.

https://kotlinlang.org/docs/reference/multiplatform.html

Probably better off using Graal native-image than kotlin native at this point.

Specially since Kotlin/Native semantics are not 100% like Kotlin on the JVM.

Kotlin barely has a standard library outside of the JVM. They only recently introduced experimental io support and the concurrency model is just plaim weird.

Yes that is what I mean with semantic differences.

I watched a couple of KotlinConf talks, it appears that JetBrains wants to be the next Borland (Kotlin == Turbo Pascal), using the JVM and helped by Android to bootstrap their own eco-system.

So even with multiple platform Kotlin there is only so much that you can use from each platform when deciding to go big like that.

I don't see it working and think if they want to survive they should focus on the KVM (aka Android).

To be fair, you can bundle JVM with your app except e.g. Android.

So a solved problem since 2000.

Not needing to know how to configure and run the JVM performantly is a big plus in my book.

Instead you allocate 1 GB to work around lack of GC tuning.

10 gb if your twitch.

https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

Doesn't Go have a lower memory overhead than any JVM language?

This is a reasonable question, so I’m unsure why it’s downvoted.

It usually makes sense to talk about the memory overhead of the JVM itself, rather than talking about one of the languages specifically, like Java or Kotlin (but maybe Scala and Clojure are a bit different).

The tradeoffs for GC systems are complicated and not easy to understand. Go supports only one GC system, as far as I know, which does not move memory and attempts to minimize GC pauses. It sacrifices throughput and CPU utilization to achieve this.

The JVM can be tuned in many ways and there are a number of different options, from choosing different GC algorithms to different memory models. Most JVM algorithms will compact memory. Some are optimized for throughput and others are optimized for shorter pauses.

In practice, my observation is that Go’s GC pauses are, out of the box, shorter than what most people will get by tuning the JVM. This is probably the most critical property for writing backend services with high fanout, which is very common at places like Google.

I don't have a dog in this be cause all I do is write embedded firmware and crummy tools that run under windows. But low latency is a better choice than throughput most of the time. My gut says when a system bogs down failures due to latency hits you first.

I’m gonna go ahead and say that this is one of the reasons why people like Go so much. Latency is a big problem and becoming bigger as fanout increases, so the old defaults for tuning GC turn out to suck horribly.

However, the throughput penalty is very real and e.g. compiling a large codebase I’d much rather have throughput tuning.

I recently had to evaluate using Go vs Rust vs Java (current) and while Go did bring notable resource usage bonuses compared to JVM, Rust seemed to give significantly more if we did switch.

The drawback of both Go and Rust for our group was that Java developers were so much more abundant in our market(not major technology hub city in the South).

I think cities with smaller amounts of talent have the same problem when trying to find Go and Rust developers of all skill levels.

I don't know about the total memory overhead, but the Go team has written a lot about how their GC pauses are shorter.

Reply on news.ycombinator.com