Go 1.14 Released - Performance Improvements, Go's Module Support Production-Ready

[archsway]

Maybe I would like go more if it wasn't so big:

$ sudo pacman -S go
resolving dependencies...
looking for conflicting packages...

Packages (1) go-2:1.13.8-1

Total Download Size:   103.40 MiB
Total Installed Size:  384.66 MiB

:: Proceed with installation? [Y/n]

[Guest]

Some of the major pain-points and headaches while using Go:

• Lack of generics, leading to boilerplate code (not all can be expressed with its duck-typing interfaces);
• Overuse of interface{}, because of the above, leading to plenty of runtime errors that should have been discovered at compile-time;
• Lack of light-weight code generation (like Rust's macros), making for example SDKs for legacy in-house services unnecessarily complicated;
• Lack of closed enums, together with widespread zero value semantics (esp. when used delibrately), making compatibility, and business logic in general, a pain to reason about;
• Outright incompatibilities, e.g. go1.9 baking monotonic clock reading into time.Time breaking naive equality comparison, caused us a LOT of headache migrating some ancient code, meanwhile the Go team is perfectly OK with the change as if it doesn't count as violation of the "Go 1 promise of compatibility".

Go as a language certainly has its merits, though. Its delibrate simple design and easy learning curve enables beginners to write relatively high-performance server code despite not knowing much of the intricacies inherent in server-side programming. Lowers cost for companies too. But it risks eventually being replaced by other languages if well-known shortcomings don't get addressed, which I personally don't see much hope in; maybe wake me up when go2 releases .

Yep,.. especially, lack of generics could be the main reason, why go would start getting replaced soon. Missing generics heavily impacts on ability to reuse code, as nowadays it's not only about data structure and functions composition, but also about other abstractions. For example, same behaviour and algorithms applied on different data structures, and with different "functional modifiers":

• collection types: lists, maps, sets, and thread-safe counterparts/implementations,...
• collection manipulation: sorting (and comparator), collection filtering (and predicates), collection mapping (and transform function), collection reduce,...
• graph algorithms like BFS/DFS/A-star/... fed by different data types (nodes and edges),...
• custom abstractions in frameworks and libraries,...

Though I love go, if another similar language (compiled to binary, with garbage collection, and designed to have simple syntax) emerges (as stable and a bit mature version), and go still wouldn't have generics, then I wouldn't mind to leave go fully behind.

[Luke_Wolf]

For me my biggest gripe overall with Go is that it's basically an attempt to rewrite C as a "modern" language. Where modern means garbage collection, allowing interface based polymorphism, and playing around with parallel processing. The later two not being bad things, and the first a matter of taste, but at the same time the language designers clearly haven't learned much from the past 30 years of language development and so most of the things that are wrong with C are also wrong with go.

Personally I can't stand the return codes over exceptions. There are pros and cons to return codes and exceptions, but the majority of people like exceptions and hate return codes, and I am one of them. It's messy and disrupts the flow of the algorithm. Darn, I actually read a really great blogpost about their pros and cons and can't find it now. Actually, this looks like it, although this isn't the site I read it from: https://ra3s.com/wordpress/dysfuncti...tion-handling/

Tbh I very much think both exceptions and return codes are incredibly stupid. IMO the way Rust handles it is the only good way to do exception handling, which means shoving the success or failure into the type information of the object being returned, and allowing it to blow up the program, be forwarded, or explicitly handled as appropriate (with some nice syntactic sugar), which gives you the benefits you would normally have with exceptions, but unlike exceptions the ErrorKinds needing to be handled are a closed set that I don't have to inspect the whole program to figure out or have to memorize an arcane set of set of prebuilt exceptions and try to figure out when I need to make my own, and well for return codes...I'll leave it to your link there

[bug77]

BTW Java has all this. Just look at https://quarkus.io/ if you want tiny binaries for use in containers.

Java's AOT is, unfortunately, still experimental. Even if you're lucky, it only works for x86_64 for the time being.
There's also Micronaut. And even Helidon, but that looks (to me) like the weakest of the bunch.

Though, having seen my share of languages, I can safely say that no language guarantees clean, working code. Hell, having worked with Java since 1.1, I can write better code in Java than I can in Go. But I still like Go better.

[quintesse]

Java's AOT is, unfortunately, still experimental. Even if you're lucky, it only works for x86_64 for the time being.
There's also Micronaut. And even Helidon, but that looks (to me) like the weakest of the bunch.

Well experimental, it's more early access, it still supported by Oracle:

The Native Image plugin is available as an Early Adopter technology. It can be used in production and is supported by Oracle as part of your GraalVM Enterprise subscription. However, it is not covered by Oracle’s standard warranty as Oracle reserves the right to force you to migrate to newer versions in order to get support.

Though, having seen my share of languages, I can safely say that no language guarantees clean, working code. Hell, having worked with Java since 1.1, I can write better code in Java than I can in Go. But I still like Go better.

It's definitely not a bad language, but I just miss too many things from it when compared to Java so it seems I have to do more work just to do thing that are supposed to be easy. But that can very well be just a lack of experience. But with Java gaining more and more interesting features at an increased pace with the new release schedule and with things like GraalVM and native image becoming available it seems that Java still has some aces up it sleeve.

[cybertraveler]

Nice thread. I enjoyed reading all the comments in here.

[squash]

Oh, and language-level concurrency but NOT eliminating data races. Concurrent accesses to maps are FATAL, not even catchable with standard recover()-in-defer trick that works for panics. Mutexes protect control flow i.e. critical sections, not data flow, because doing so requires generics. I don't have much to say...

Maybe you missed the memo about https://golang.org/pkg/sync/#Map which is part of the standard library, added around 3 years ago to provide a baked-in solution for concurrent access for folks who didn't want to manage their own locking.

You were always able to use sync.Mutex on maps, and the documentation was very clear about the need to protect it from concurrent use. Your stated definition of a mutex is an opinion, not the actual definition of a mutex.

[squash]

Maybe I would like go more if it wasn't so big:

That's a weird thing to not like about a language, particularly one that includes a vast standard library, a bunch of included tooling, and cross compilation to a several platforms. "Go has too much included in the box" just doesn't seem like a negative.

With that said, it's strange that it needs 40 megabytes more than the official distribution.

/usr/local/go$ du -sh .
342M

[bug77]

Maybe I would like go more if it wasn't so big:

$ sudo pacman -S go
resolving dependencies...
looking for conflicting packages...

Packages (1) go-2:1.13.8-1

Total Download Size: 103.40 MiB
Total Installed Size: 384.66 MiB

:: Proceed with installation? [Y/n]

That's the entire SDK. And it can't even be considered big at under 400MB. I mean, it's less than a NodeJS project

Well experimental, it's more early access, it still supported by Oracle:

Last I tried it, it couldn't generate native code because of a combination of the framework and Hazelcast. "Support" from Oracle does exactly squat when that happens. And it happens a lot since many libraries like to (ab)use reflection. Hell, most libraries aren't properly modularized these days, making native-tool's job that much harder.
But let's get back on topic, which is Go. Did I mention I love it?

[Guest]

That's a weird thing to not like about a language, particularly one that includes a vast standard library, a bunch of included tooling, and cross compilation to a several platforms. "Go has too much included in the box" just doesn't seem like a negative.

With that said, it's strange that it needs 40 megabytes more than the official distribution.

/usr/local/go$ du -sh .
342M

Doesn't go depend only on libc, therefore these 342M represent whole build system/tools, and also standard library? Which is much less, compared to gcc/clang and other languages, including build tools, standard library, headers if necessary for compilation, and other dependencies except libc?