Why Go is my favorite programming language

Not to disparage less experienced developers but I think teams of developers of any experience level need to have code governance and oversight regardless of the technologies and that a good team with good practices can create good code bases even with more complex and expressive languages. I know another colleague who did this with Scala and was able to properly mentor more junior developers by leading by example. I have not used Go. I have done and lot of Java and a bit of Scala and have many times leveraged generics to create a very high degree of reuse. Without them clearly you get a lot of boilerplate code which makes a codebase larger which leads to another type of complexity in my opinion. So the question is which scenario increases your codebase complexity and that probably boils down to what domain you are developing in. I explore some ideas relating to that tradeoff here [0]. Go has a specific use case that it targets which I believe is services and certain aspects of concurrency.

Clearly the Go language and environment have value in the industry, however, as a language it offers little for people who want to have an opportunity grow and learn about more advanced concepts wrt to PLT and CS in general. I have a friend who is a Go fanatic and I try to encourage her to push her limits, but she feels and she can bang out service level code very quickly and she can as she is quite talented. Of course you can do that with Spring Boot as well. Regardless of your language you should always be trying to grow as a developer otherwise you risk becoming obsolete.

To put it bluntly and I may get downvoted for this I feel Go is the “Rise of the Expert Beginner Language”. [1]

[0] http://www.elegantcoding.com/2012/02/software-reuse-complexi...

[1] https://www.daedtech.com/how-developers-stop-learning-rise-o...

No idea how they are using it.

I said "it's unsafe", not "it's not safer than void*".

> (i.e. exit cleanly without corrupting memory).

This makes no sense. If it exits, who cares if the memory of the process is corrupted?

Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it.

That's the point of static type safety (which Go doesn't provide in this case): it lets you ship code that is provably incorrect and that will not work once deployed (it will exit, like you say).

This is why I said "it's unsafe".

Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC.

Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs.

And so it's so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. "The repetition is simple," they reply, "and of course abstractions have cost."

So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it's so tempting to start pattern matching the whole block of code and miss these subtleties.

This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes.

Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible. As such, it is quick to learn the syntax. It's not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library.

I just don't understand why anyone appreciated go's design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don't think very much of and have no desire to train.