The State of Go – Where we are in May 2017

They killed the only innovative desktop they had, NeWS. And although Swing is quite powerful, the default configuration certainly isn't.

They also removed resources from JOGL, Java3D and JDI.

Also given the existance of so many Wirth influenced languages with AOT compilation to native code, at the time Java was released, I never understood why they were so religiously against AOT toolchains.

There is even a paper from Sun Research about writing Solaris drivers in Java, but instead of compiling AOT to native code, they ported the JVM into kernel space.

I wonder what would have they done if the partnership with NeXT regarding OpenSTEP had actually gone forward, instead of being the inspiration to Java.

> How about less complex than Rust, less associated with Apple than Swift, and better designed than Go? And with serious compatibility with Kotlin for the JVM -- which boosted by Android adoption will get quite big soon.

How about a language that has every feature I want and slowly every feature that everyone else wants. If it has been tried and done successfully before, I have not seen results in commercial software realm.

Going by the hype of Kotlin on Android I am wondering it may end up becoming part of Daydream but without any VR.

Not for my money. A few things Go does better than Kotlin:

1. No classes, inheritance, etc (let's dispense with the "you don't have to use it!" arguments; they don't prevent us from interacting with an ecosystem and std lib full of classes and inheritance) 2. Concurrency; Go has one model, goroutines. Goroutines != coroutines, and no worrying about whether some function blocks the thread with a sync call. 3. Real, first class value types. Easy reasoning about allocations and escape analysis, etc. 4. Tooling: most everything is simple and does the right thing by default. There is one build system to understand, and there are no build scripts to write or cargo cult. Oh, and it's fast.

Kotlin has generics which are nice, but in practice I spend zero time on runtime type errors; on the other hand, reasoning about performance and tooling consume quite a lot of my time. I'm happy that it's getting generics, but it has a long way to go before it's competitive with Go for my time.

* you get a note that a map must not be copied, but you won't actually be prevented from doing so?

* iteration can't use the native construct (no generic interface -> no generic iteration)

Coupled with a fairly inefficient GC it means I would need to think twice before using this.

Better if you wrap it somehow. Then it's similar to an unsafe section; you need to be careful but it's self-contained.

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

TLDR: Go's GC will only be realtime as long as you use it only minimally. With tiny programs, that's fine of course. With larger programs, it will block for a looooong time. That's masked by the language making it very hard to write larger programs in the first place. For instance, by not having decent data structures (not even a tree, seriously ?)

I guarantee if you actually use the GC, there comes a point where java runs circles around Go. Hell, there comes a point where the lua GC runs circles around the Go one. That point is a lot closer than you might think, and as a bad rule of thumb you should probably think of it like this: if any of cpu, mem, i/o goes >80% of the machine's capacity, Go will disappoint very badly compared to Java (GC using more memory, using more cpu, longer pauses, ...). But if all those values are at 2% of capacity, Go's runtime will perform better.

Tradeoffs. Everything is tradeoffs. Go is not better than Java/JVM, it's worse. But a different set of tradeoffs means that there are circumstances where it'll beat the other set of tradeoffs. But "close to 0", Go will beat the JVM.