________________________________________________________________________________
Very generic Golang puff piece; this reads like a Business Insider “contributor” blog post.
I couldn’t agree more. I love Go, but this piece is superficial at best.
One thing I’ll say about Go, and why I love it. I’ve been coding for decades, and it’s one of the few languages where I find it very easy to read and understand other peoples code.
That’s more a side effect of the tooling than the language itself tho.
“ Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.”
https://go-proverbs.github.io/
The language goes out of its way to minimize concepts, the number of ways state can be mutated (eg no thread locals), over-abstraction, and dynamic meta-programming. It emphasizes explicit control flow, preferring code duplication that is easy to read, over minimizing duplication by creating complex abstractions or implicit runtime behavior.
There are a lot of cases where these tradeoffs suck and add a bunch of unnecessary friction. And there are many cases where it boosts overall productivity significantly.
not sure I agree. the ability to comprehend code goes way beyond surface-level formatting, especially since gofmt doesn't actually do that much
I concur. It's not just gofmt (although it is great). With go and an IDE, I can drill straight down and basically hit "bottom of the stack" within <5-7 jumps of "jump to definition" (C-b for me). Python it's like layer on layer on layer of indirection, "clever" code everywhere, and frequently the track runs cold. I don't have to sit there and study some inscrutable nugget for minutes/hours cause it's all obvious.
Not sure if it's the language, culture, or both, but I love it.
In my opinion, Go & Python are similar languages in the way they balance language constraints with just enough expressiveness to not feel stifling. I think this is part of the reason so many Python shops have adopted Go as either a second language or their new primary language.
Agreed, and I'm a fan of Go. Evaluating its performance from a toy CRUD app and a microbenchmark? It's disappointing to see this on SO.
Pretty much all of the content on that blog is fluff garbage.
"Making the most of your one-on-one with your manager or other leadership", "Communities and Connections will power our growth in 2021", "Static site generation with single page app functionality? That’s what’s coming Next(.js)".
Personally I like Go for the same reason I like Clojure. It aims to be a simple (in the most positive sense of the term) and reliable language that avoids fanciness or complexity and has a good concurrency model.
Easy to learn and without much arcane hierarchies and easy to read and maintain. The longer I write code the more I'm drawn to simplicity as the most important thing about a language.
They mention two things in the article - speed and number of lines of code. Are either of them the most important thing in the average business code? Sure devs always like to get things faster just because they can, but in most business settings whether its java, .net, php, etc it really doesn't matter it will be just fine for the speed (considering its probably database calls, etc that are the bottleneck).
I would argue its more about code readability and maintainability than speed. Can I take a java developer and have him/her look at some Go code and know what's going on? For the most part I would say yes.
What's not so great about Golang:
-error handling is kinda ugly and verbose
-no generics
-interfaces are done through duck typing
-null pointers
-int size is platform dependent
-no built-in immutability
A point I don't see mentioned often enough is a couple of points about the compiler's poor DX for iterative development.
Go will fail to build if you have unused dependencies or variables. (And it's easy to use the convenient `:=` in a way which faces problems exacerbated by this).
If I'm debugging through something, I might be adding packages or intermediate calculations to try and figure out what's going wrong. But because the Go compiler enforces this proper style of "nothing unused", there's that much more friction when tinkering.
All of this is true, and yet Go is going from strength to strength because sometimes "worse is better".
https://en.wikipedia.org/wiki/Worse_is_better
What's great about "not so great about Golang" posts:
- it's the exact same 4-6 criticisms every single time
- "no generics" is on the chopping block
It's the exact same criticisms every single time about other languages too. Unsafe C, slow Python, verbose Java, messy JavaScript ecosystem, etc.
When criticism is valid, it doesn't matter if it's novel or not.
> - it's the exact same 4-6 criticisms every single time
This isn't necessarily an argument that those criticisms are wrong, though.
To me it's the fact that it's an alright language to build stuff in, but the tooling is hard to beat.
The fact that you can "go <command>" so many things so easily (build, run, test, etc.) beats almost every language out there. It makes starting new projects _really_ easy. Personally, that's one of the main barriers I feel when I'm trying to start anything in other languages.
Consider Java (or Kotlin, for that matter). You need either a Maven POM or a Gradle build file. Gradle makes things a little easier with 'gradle init', but you're still stuck with arcane build files either way. If you have to use Maven and need any plugins... Good luck with that.
I think the general pattern here is that pretty much every language doesn't stand on its own when it comes to starting and working on a project. You need external build and dependency management tools. Go has it all built-in and it's super easy to use. It's beautiful.
Language-wise, I want a language that's as versatile as Kotlin, with the ease of use of Go. Imagine having a bunch of .kt files and just being able to 'kotlin build', 'kotlin run', etc. That'd be gold.
> I want a language that's as versatile as Kotlin, with the ease of use of Go
You can do that today with C# and .NET Core - initialize and build your project straight from the command line with standard tooling bundled with the language (of course .NET Core's tooling is a lot younger than Go's, and in a typical .NET environment you'd be expected to be using Visual Studio or some other IDE, and probably have to deal with legacy projects that depend on old tooling).
https://ttu.github.io/kotlin-is-like-csharp/
https://docs.microsoft.com/en-us/dotnet/core/tools/
In some ways Kotlin’s heritage from JetBrains is a disincentive to make this simple, batteries-included build/run/test/deps tool - most language users and the language producers have the IDE itself playing this role.
I hope that as Kotlin multi-platform matures, we’ll see more stand-alone, Unix-y tooling for the language. As is, it seems very challenging to do a Kotlin project without a (JetBrains) IDE handling initial project set-up, Repl, build, run, test, and all the Gradle malarkey.
Technically you can use Gradle from the command line. Gradle isn't pretty though. `gradle init` for a simple Kotlin hello-world application generates 20+ files and folders, which to me is an incredible amount of bloat. Not exactly Unix-y. Agreed about Kotlin being made by JetBrains being a negative. It's a great language, but only working with one IDE, JetBrains', is a trap I'd rather not be in. They seem to be on the wrong side of history with the Language Server Protocol becoming more popular every day.
The nicest thing about Go is that the trade-offs are quite clear from the beginning, i.e. you know what you are sacrificing to seize the pros. The cons are usually excessive verbosity.
I'll add my favorite pros as well:
- the language is very simple and explicit, which makes it easy to understand third party code bases
- the spec moves very slowly (or not at all), which ends up protecting the investment that you make into your software in the long term
Get Generics implemented first. Fortunately draft already prepared but any modern PL without similar generalization tech is far from `great`.
I really struggle with this too. I know a language can be great at what it does without generics, but it doesn't seem like Go is geared towards being that kind of language.
I appreciate how easy it is to write and how incredible the performance is, but I get tired of the style of code it forces you to write. I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization.
The problem with generics is that every programmer generalizes differently and thus there is a massive barrier/“learning curve” for anyone new picking up an arcane codebase that some clever developer cooked up.
Not saying someone can’t screw up codebases in go, but it’s just much harder to do and you usually see it right away by noticing abuse of interface{}.
I agree completely. I use very dumb generalizations in hopes of keeping them easy to follow. I’ve burned myself and team members with cleverness many times with good intentions. These days I’ve calmed down a little but still find generalizations handy on a regular basis. You’re absolutely right though and I see why they were left out. For a lot of people (including myself at a times) it’s probably best to prevent cleverness.
Go is simple and fast to use, but not so elegant under the hood, which is part of the cost.
Go is great for readability and changing of code, depending on the dev and time though.
TLDR;
- Simplified, familiar syntax for those who already know a C variant
- Concurrency model (CSP) which works nicely with the request/response paradigm of server communication
- Performance comparable to other statically compiled languages.