@hrefna I haven’t read the entire thread, so I apologise if anything is redo. What I like about Go is it doesn’t change that much. I can go back to code written 3 years ago and just update the Go version and keep writing code. I very much miss functional methods to manipulate data and the verbose code you write is kind of a pain, but it is really to solve small problems.
@hrefna@kittylyst my main take, which I think matches yours, from my Go experience, is that Go is optimized for reading while Java has become optimized for writing
They also made some assumptions in the kind of workflow they were trying to work with/encourage
They didn't like IDEs. They largely come from a group of devs and an era of devs who didn't (though I wouldn't say this was necessarily a common take at google at the time)
They did like writing data structures. You feel very productive when writing data structures.
They were assuming something like a controlled monorepo for development
Basically at the core of it they wanted to optimize the development loop:
Make a change.
Compile.
Test.
GOTO 1.
I'm personally of the view that they wanted to optimize the development loop for someone working predominately from the command line in essentially vim, without a language server. I know a bunch of devs like that and this reminds me of them in a lot of ways.
Early versions of Go outside of Google had no package manager to speak of and it still has a relatively weird stdlib. It made assumptions about your development environment that largely were true at Google, but nowhere else.
The early gen garbage collector also wasn't really all that and had weird pauses that were difficult to debug. There was a nice enough concurrency model, but it wasn't earth shattering and it didn't solve any of the actual hard problems to speak of.
I see what you mean, but all these things seem minor issues to me. Yes, "Rat" is a funny name for a rational number type. Yes, log is overly simple. Yes, json.Marshal isn't perfect.
But you can find such things in each and every language.
For long years of my life, I have been searching for the perfect programming language, until I realized that no such thing exists.
A language only needs to be good enough. Easy enough, performant enough, maintainable enough. Go is all of this.
@hrefna The concurrency model did solve one very specific problem compared to Ruby on Rails at least — an idiomatic Go server wouldn’t use a whole thread per request, which was a major bottleneck for scaling. That was the reason many startups rewrote their Rails servers in Go in the early 2010s.
Incidentally, Node also solved that problem well, and gained popularity at the same time.
@zombierustpunk Yep, it had some marked improvements on rails's model, but as you point out it wasn't the only solution to that.
Stackless python existed, Erlang had been around forever, clojure came out with core.async and .NET 4 had tasks. A bunch of other languages simply solved the problem differently and didn't have RoR's struggles here (Java and C++ would use connection pooling).
So while it often appealed to Python (and Ruby) devs, it wasn't a Killer Feature™ for many.
Many of these issues have improved with time, but what happened next was a bunch of exec types LOVED golang. They could read it easily. They saw it as The Future™.
I was told repeatedly by multiple exec-types that this would displace Java and C++. That this would integrate better with the world. That it would come with a free pony.
This built a lot of resentment in engineers who had to deal with the execs telling them "THIS IS WHAT WE ARE DOING NOW" on the one hand and reality on the other 5/
@hrefna absolutely shot themselves in the foot by capping max open files at 1 million at the runtime level, I had to walk away from a perfectly good piece of software over it
But beyond that, if you were working on a large software project in Java or C++ you likely had a lot of very powerful tools in your IDE. You had a strong SDK and tools that worked with it.
You had a robust development environment. You had powerful frameworks that had been battle tested for years and dependency managers that, while everyone complained about them, they mostly worked and their quirks, while not solved, were also not blockers for most work.
We had incremental compilation, so the only time you had to do a full compile was on the CI/CD infrastructure. It was often still painful, but we were finding more and more ways around it with good build tools.
We had autocomplete. We had extensive refactoring tooling.
We had subtypes and a lot of strong language features that made it easier, not harder, to read on our large software projects.
What's more, there was a lot of looking to the future.
Developers were graduating with better and better knowledge of the systems we worked with. There was one of the big pushes in category theory that seems to happen every few years going on. The developers who had graduated years ago weren't leaving industry but they were getting older. People were looking at concepts like pattern matching and fp.
Go was explicitly made for new graduates, but developers are only new graduates (if they are graduates at all) for a very short period of time 8/
Along comes go and it seems to be going backwards, but not in the way that the industry rediscovers actors every ten years. It wasn't rediscovering the past, it was flat-out tacking that direction.
But. A language existed that was used for servers but was used for a lot of utility scripts and applications and that a lot of people struggled with for large projects. Where there were already libraries for CSP but they were used but inconsistently
Python developers often really liked Go and SREs who had to maintain major python projects REALLY liked go
There were IDEs for python, but they weren't at the level of maturity that Java or C++ had. They were dynamically typed and so a little type safety often felt like an improvement rather than a step backwards. The fast compile times were appealing, and the style guide appealed to a group who believed "there's one obvious right way to do it"
Basically: the execs notwithstanding, most engineers didn't see go as a silver bullet but as a nice enough tool in the toolbox, especially for writing, say, command line utilities or simple web servers.
C++ and java devs weren't willing to sacrifice the performance or more sophisticated typing, packaging, etc. They had tools to reduce the complexity they had to deal with and go seemed to shove all of that complexity at them and say "BUT THIS IS A SIMPLER WAY OF DOING IT."
The execs insistence here was especially painful for data engineers because our lives revolved around taking data from one place, applying a series of transforms to it, and putting it somewhere else. The steps were often very similar to each other but with differently shaped data, so we could reuse a lot of code in a lot of cases.
Do you know what languages make that easy?
If you answered anything with parametric polymorphism/generics you are most likely correct.
I want to emphasize: None of this is really a flaw in Go per se (well, some aspects may be, but I'm not talking about that right now). Go has a pretty strong core and it works well in that area. There are a lot of go programmers, and a lot of the issues I'm describing have been smoothed over with time, and execs have become less… enthusiastic.
It does mean I think that—for what Go was initially being advertised for—a lot of people who were already in that space found it difficult.
It works "well enough" in that space but it is just "well enough." Its advantages were muddled when compared to languages like Java, C++, and C# and it wasn't clearly better, which made adoption difficult against those languages.
It's still managed at points, but it's because a team evaluates the tradeoffs and finds that it fits, not because it is head and shoulders better (like, you know, everyone in industry for more than six months would expect).
It goes back to: there are no silver bullets. You can't just rub a programming language on top of bad practices and get a good result.
You are going to get a bad result regardless of what language you are writing in, and safeguards can backfire in a large enough project because they make things difficult to reason about or adequately test.
Anyways, I may have more to rant about on this eventually, but I'll leave off for right now.
@hrefna interesting read. I am a "hobby programmer" - as in I write really small projects once in a while for my own enjoyment/use, and personally I really love Go. It feels like I have more control than python but much less of a hassle than C. so I think the statement made here is very correct, at least anecdotally.
@hrefna the ‘one right way to do it’ is a direct contrast to scala -which I wanted to love- where there are 5 right ways to do it and every shop has its own style guide, making learning the language as an itinerant contractor impossible. I ended up going back to modern java (for preference) and learning golang for new customers.
@steely_glint I programmed in scala seriously for several years. I have been on scala projects that were great, easy to read, cleanly coded…
…and also ones that aren't
IME you need really tight discipline to make it work and it helps if you have a small team that's all relatively senior and dedicated to quality. When I've had that, I've really seen the elegance
Whenever I see a large project that doesn't check those boxes and managed to not be an eldritch nightmare I can't help but applaud.
@hrefna I found that modern java had stolen enough of the elegance (streams, actors etc) that I was no longer even tempted by Scala - it did a great job as a stalking horse IMHO.
@hrefna eh, some did, some didn't. Widespread SRE adoption of Go at Google required SRE leadership to mandate "No new cross org effort will be considered unless it's written in Go" (similar to the top-down exec-driven adoption you describe).
@hrefna In terms of "looking backwards", Go looks to me like the best programming language of the 1970s - taking the last major set of programming languages that Pike et al worked on and fixing the things that annoyed.
It's a curious coincidence that the things a grad programmer can learn quickly match '70s Unix tools.
@sgf Strongly agree. I remember reading about someone asking why go didn't seem to incorporate any lessons on type theory learned after like 1976 or somesuch.
It always felt to me like it was built for the sort of programmer who came out of that era: People who didn't like IDEs, learned mostly in C, etc.
Pike expressed surprise that C++ programmers weren't drawn to it but that Python and Ruby devs were, and I always viewed that as extremely obvious and a natural outcome.
@hrefna Execs raving on Go over Java? Not in Germany, or perhaps, it was before I jumped into the Go bandwagon (late 2018). My impression so far, having had the chance to sell it to companies is this: they think it’s a nice niche language for tooling and infrastructure, but that’s that. Nothing that they wanted near their precious core business processes.
Luckily, I also found some small teams that thought otherwise and we did prove that Go is capable of being the main character of the show.
@hrefna
At the time, I think that cscope was state of the art for "language server" type tasks. A small step up from ctags, since it could do reverse references and go-to-impl/decl.
At least, that's what I remember using in 2009. And I guess internal dev must have started in 2007 or so.
Add comment