21–30 of 310 posts
1. Built in support for tooling, testing, formatting etc
2. Trying to make concurrency mainstream
3. Large and developer friendly standard library, there is hardly any programming language where web backed can be written without using a framework or a library. Go is one of those.
I do like it for small things - compiling to one (albeit huge) binary and its relative speediness is nice. I wouldn't use it for large systems though. The amount of code really balloons over time, relative to, say, python and that SLOC correlates to bugs and maintenance cost.
The development process is fluid enough that I wish the language was suited to more usecases. When I need to handle complicated data (e.g. abstract syntax trees), I use Rust or Haskell because of their rich data types. But it tends to be much harder to get things running in those languages (borrow-checker and monads, respectively). I want to reach for Go to make those problems go away, but then realize that it would be really painful to try to express the program in Go. I understand that other people are unhappy with Go's development process, particularly if you deal with package versioning.
The language design itself may have been backed into a corner where adding generics will create an ugly mess (what will the standard library look like if it tries to maintain backwards compatibility?). Time will tell.
The tooling is mostly pretty good, but many things feel half-baked (compared to more mature ecosystems). On the spectrum of 'written in a weekend' to 'dozens of developer-years of work', the package "net/http/pprof" feels closer to the weekend side. There are bright sides, like having the production parser available as a library.
It's a language that is frustrating in different ways from other languages. Instead of fighting with Cabal/Stack, you have to write a million `if err != nil {}` statements. Part of what makes it frustrating is seeing how good it could have been.
Non-exported struct fields are a way of preventing your library from being composable. Checking if a value implements an interface is a way of writing surprising bugs. The standard library uses both of these features extensively, to give users bugs and prevent itself from being composable. Checking that the user uses all values bound to variables but letting them discard errors by not binding them to a variable is a…
They tried to make a better C++ and accidentally made a better Java and a better Python.
Agree over the java part. But Python is still orders of magnitude more productive, being it because of the ecosystem, available libraries, frameworks, or almost any other metric. The only advantage over python is performance, and maybe static typing depending on your taste.
It's a real good Java
https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
My biggest gripe with the language is that it doesn't scale that well for teams. It requires a certain culture & approach to produce maintainable programs that goes against the grain for many developers, and while I enjoy the simplicity it offers, that simplicity leads to cost of ownership problems in many team scenarios. This con is mostly about the language.
As a specific tactical item, the runtime multiplexer could do with a refactor. The merging of the pollers essentially could continue until it is much cleaner, there are more layers there than necessary to solve the problem. You can follow the FD close path to understand the strains of the current factoring. Such a cleanup could probably remove some overhead for io heavy workloads too, maybe even drop some lock contention. Oh, and the spins should all be removed from the runtime before we really start using it on very high core count systems. This opportunity is mostly a side effect of a long history of incremental improvement.
If I had to choose between Go and C++, I'd probably pick Go because of C++'s complexity, so they really nailed it.
In the grand scheme of things, it's a really forgettable language. Frankly, I haven't programmed in it. I don't need to. I know ALGOL+(N+1) when I see it.
Decent for writing web backends, APIs, RPC services. The high number of libraries also help. The language is very simple, which is good or bad, depending on who you ask. Tooling could use a lot of work though. After switching between vim-go, gopls, and a handful of other language server implementations, I've given up on auto-completion, definitions etc altogether. Maybe it's my setup... Overall, I'm pretty happy with…
Have you tried GoLand?
Thanks for mentioning it, I think I'll take another look at it now. Having a real IDE probably has more benefits once the code grows beyond tens of thousands of LOC.