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

[phoronix]

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

Go 1.14 is now available as the latest version of this popular programming language backed by Google...

http://www.phoronix.com/scan.php?page=news_item&px=Golang-1.14-Release

[pkese]

Give this a Like if you DISLIKE golang

[pkese]

Give this a Like if you LIKE golang (and explain why; how many statically-typed programming languages do you actually know).

[Guest]

Give this a Like if you LIKE golang (and explain why; how many statically-typed programming languages do you actually know).

Just, because it has got very sophisticated design, which encourages simple, decoupled and organized code. Java language allows to easily write heavily intercoupled spaghetti code. In golang, it becomes much more visible, giving feel something isn't quite right, if there's high coupling.

Apart from language design. It is compiled to native code, which produces tiny docker images (only compiled binary is needed). And, it has garbage collection, which relieves developer from having to think a lot about life of dynamically allocated data, and eliminates bugs caused by dangling pointers, and memory leaks.

However, generics support is very missing, as lots of abstract and reusable code, and especially some repeated mechanisma algorithms, do require generics.

[quintesse]

It is compiled to native code, which produces tiny docker images (only compiled binary is needed). And, it has garbage collection, which relieves developer from having to think a lot about life of dynamically allocated data, and eliminates bugs caused by dangling pointers, and memory leaks. However, generics support is very missing

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

[gquintard]

And, it has garbage collection, which relieves developer from having to think a lot about life of dynamically allocated data, and eliminates bugs caused by dangling pointers, and memory leaks.

Go loves pointers, leading to memory corruption and other atrocities, memory leak still exists too, so yeah, it eliminate some of them, but it's still a mess.

[boxie]

Go loves pointers, leading to memory corruption and other atrocities, memory leak still exists too, so yeah, it eliminate some of them, but it's still a mess.

I would argue that "Go uses pointers and you can trip over them" - having seen the atrocities of pointer math, I am glad that Golang does not support it

[Ironmask]

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/

Other than that, Go is just another "Alternative C", except compared to Rust, Swift and pals, it does the least amount of innovating and gives you the least amount of options. I feel like the designers just want it to get a participation award for trying to be better than C but not actually really doing that. And C sucks, so I don't know how you screw that up. It's not even a general purpose language, it's only for writing servers, which makes it pretty hard to choose, even if you're only writing a server, because there's so little support for it. I feel the same about Erlang/Elixir and I actually really like Erlang. If you're writing a server, you're better off with something like ASP.NET Core since there's just about a C# library for anything you could ever possibly want to do, and .NET Core 3.1 has Java bindings, so you can even make use of those rare edge cases where what you want to in C# is only possible in Java, like using Lavalink. I just see absolutely no reason to choose Go unless you have really specific and esoteric tastes, but, then you may as well invent your own language like what Johnathan Blow is doing with his language Jai. Johnathan's an idol of mine, prefers error codes over exceptions, one of the few things I disagree with him about.

[xen0n]

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 .

[xen0n]

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