▲ 51 points
back
38 comments
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.”
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.
It's not just the formatting though, I think it's the lack of magic and options; when you compare it with Java, every library will have its own style and approach to doing things. in Go, things are a lot more consistent - either because of the language, or because of conventions.
I've always considered Scala to be the linear opposite of Go, where over time they have bolted more and more (advanced) features and syntax until you end up with libraries and code as extreme as scalaz [1], and of course every developer will have their own Opinion on how things should be written, formatted, etc. Scala adds choice, Go reduces it.
Oftentimes the argument is "but you don't have to use all these features! you can write Scala just like Java", but in practice that's not how it works. I mean just a for loop is already a headscratcher in Scala.
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)".
Yeah, SO is very much aimed at the masses + management, I mean their main platform is aimed at that as well.
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.
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.
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
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.
I highly recommend using goimports to format your code on save: https://godoc.org/golang.org/x/tools/cmd/goimports
This will hopefully reduce some of the friction you are having.
All of this is true, and yet Go is going from strength to strength because sometimes "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.
> verbose Java
Ironically, golang codebases tend to be more verbose than Java.
They've traded horizontal verbosity for vertical; you probably won't find a `SimpleBeanFactoryAwareAspectInstanceFactory` in Go; instead you'll probably find a long list of functions implementing some interface (`Stringer`, `Valuer`, etc).
I want to make a pasta comparison but can't think of a good one for Go, since it's often quite straightforward / not-spaghetti. Java is often lasagna code though.
> - it's the exact same 4-6 criticisms every single time
This isn't necessarily an argument that those criticisms are wrong, though.
Well, there's a lot more than that:
https://github.com/ksimka/go-is-not-good
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.
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.
> 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.
This is where one of those sayings come in; "Duplication is better than the wrong abstraction"
Generics is still a difficult one for me; I don't really miss it myself, but I can see some use cases for it. On the other hand, it makes the language + tooling a LOT more complicated.
But on the other other hand, it opens up possibilities to tackle other criticisms of the language - error handling and nil, which can be solved with Either and Option types found in other languages.
I am fairly new to Go, been a Gopher for about a year now, and I really like it a lot.
My background is Visual Basic, PHP, C and C++ and then C# and F# for the longest part. Coming from .NET Go feels like a huge breath of fresh air and brought the fun back into programming. What I enjoy the most is the simplicity (not to be mistaken with the language being “simple”) and the vibrant OSS ecosystem. With Go I feel like I’m actually programming again and solving problems. My focus is to deliver value. With C# I feel like 50% of the time is spent understanding everything around it and mastering .NET with the anticipation that the next project will benefit from my expertise, but before the next project has arrived the .NET landscape has changed significantly enough so that I’m yet again spending 50% of my time mastering the language rather than building something cool.
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.
> not so elegant under the hood
Could you explain this? IIRC they kept the language simple so that they can keep things elegant in tooling / compilers / etc as well. Or is this about the runtime?
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.