7 ms·
I’m glad that Go went the other way around: compilation speed over optimization. For the kind of work I do — writing servers, networking, and glue code — fast
by rednafi 1y ago
I’m glad that Go went the other way around: compilation speed over optimization.
For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.
I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.
But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.
- galangalalgol 1y agoThat is exactly what go was meant for and there is nothing better than picking the right tool for the job. The only foot gun I have seen people run into is parallelism with mutable shared state through channels can be subtly and exploitably wrong. I don't feel like most people use channels like that though? I use rust because that isn't the job I have. I usually have to cramb slow algorithms into slower hardware, and the problems are usually almost but not quite embarrassingly parallel.
- bjackman 1y agoI think a lot of the materials that the Go folks put out in the early days encourage a very channel-heavy style of programming that leads to extremely bad places. Nowadays the culture seems to have evolved a bit. I now go into high alert mode if I see a channel cross a function boundary or a goroutine that wasn't created via errgroup or similar. People also seem to have chilled out about the "share by communicating" thing. It's usually better to just use a mutex and I think people recognise that now.
- rednafi 1y agoThis is true. I have been writing Go for years and still think channel is a bit too low level. It probably would've benefited from a different layer of abstraction.
- ode 1y agoIs Go still in heavy use at Google these days?
- hu3 1y agoWhat would they use for networking if not Go?
- surajrmal 1y agoC++ and Java. Go is still used, but it's never caught up to the big two.
- frollogaston 1y agoAnd probably more Java than C++
- homebrewer 1y agoLast time I paid any attention to Google's high level conference presenters (like Titus Winters), they almost didn't use Go at all. Judging by the sibling comment, this hasn't changed much. For some reason people are thinking that half of Google is written in Go at this point, when in reality if you listen to what they themselves are saying, it's 99% C++ and Java, with a tiny bit of Python and other languages where it makes sense. It's just a project from a few very talented people who happen to draw their salary from Google's coffers.
- fireflash38 1y agoK8s isn't entirely in go?
- frollogaston 1y agoThey don't really use K8S internally
- fsmv 1y ago
- mark38848 1y agoWhat are obnoxious types? Types either represent the data correctly or not. I think you can force types to shut up the compiler in any language including Haskell, Idris, PureScript...
- Mawr 1y agoI'd say you already get like 70% of the benefit of a type system with just the basic "you can't pass an int where string is expected". Being able to define your own types based on the basic ones, like "type Email string", so it's no longer possible to pass a "string" where "Email" is expected gets you to 80%. Add Result and Optional types (or arguably just sum types if you prefer) and you're at 95%. Anything more and you're pushing into diminishing returns.
- hgomersall 1y agoWell it depends what you're doing. 95% is like, just your opinion man. The rust type system allows, in many cases, APIs that you cannot use wrongly, or are highly resistant to incorrect usage, but to do that requires careful thinking about. To be clear, such APIs are just as relevant internally to a project as externally if you want to design a system that is long term maintainable and robust and I would argue is the point when the type system starts to get really useful (rather than diminishing returns).
- rednafi 1y ago> The rust type system allows, in many cases, APIs that you cannot use wrongly, or are highly resistant to incorrect usage, but to do that requires careful thinking about I need none of that guarantee and all of the compilation speed along with a language where juniors in my team can contribute quickly. Different problem space.
- bogeholm 1y agoWhile I agree with your analysis and points, my upvote was based entirely on the Lebowski reference
- 1y ago
- mike_hearn 1y ago> fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps Well, that point in the design space was already occupied by Java which also has extremely fast builds. Go exists primarily because the designers wanted to make a new programming language, as far as I can tell. It has some nice implementation aspects but it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java, which was the original target market they had in mind (i.e. Google servers). Scripting language users were in the market for a language that had a type system but not one that was too advanced, and which kept the scripting "feel" of very fast turnaround times. But not Java because that was old and unhip, and all the interesting intellectual space like writing libs/conf talks was camped on already.
- rsanheim 1y agoJava still had slow startup and warmup time circa 2005-2007, on the order of 1-3 seconds for hello world and quite a bit more for real apps. That is horrendous for anything CLI based. And you left out classloader/classpath/JAR dependency hell, which was horrid circa late 90s/early 2000s...and I'm guessing was still a struggle when Go really started development. Especially at Google's scale. Don't get me wrong, Java has come a long way and is a fine language and the JVM is fantastic. But the java of 2025 is not the same as mid-to-late 2000s.
- mike_hearn 1y agoMaybe so, although I don't recall it being that bad. But Go wasn't designed for CLI apps. It was designed for writing highly multi-threaded servers at Google, according to the designers, hence the focus on features like goroutines. And in that context startup time just doesn't matter. Startup time of servers at Google was (in that era) dominated by cluster scheduling, connecting to backends, loading reference data and so on. Nothing that a change in programming language would have fixed. Google didn't use classloader based frameworks so that also wasn't relevant.
- frollogaston 1y ago
- silverwind 1y agoYou can have the best of both worlds: A fast, but sloppy compiler and slow, but thorough checkers/linters. I think it's ideal that way, but rust seems to have chosen to needlessly combine both actions into one.
- danielscrubs 1y agoOne day I would like to just change pascals syntax a bit to be Pythonic and just blow the socks of junior and Go developers.
- the_sleaze_ 1y agoThat's what they did to Erlang with Elixir and now there are a lot of people saying it's the Greatest Of All Time. I'd be interested in this project if you do decide to pursue it.
- rednafi 1y agoSounds like the guy who wanted to write curl in a weekend. /s
- danielscrubs 1y agoYou’d be surprised. Here is the Pascal successor Oberons very short Ebnf. https://oberon07.com/o7EBNF.xhtml https://oberon07.com/o7EBNF.xhtml Something to look into in retirement.
- paldepind2 1y ago> I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. I'm a fan of Go, but I don't think it's the product of some awesome collective Google wisdom and experience. Had it been, I think they'd have come to the conclusion that statically eliminating null pointer exceptions was a worthwhile endeavor, just to mention one thing. Instead, I think it's just the product of some people at Google making a language they way they wanted to.
- melodyogonna 1y agoBut those people at Google were veteran researchers who wanted to make a language that could scale for Google's use cases; these things are well documented. For example, Ken Thompson has said his job at Google was just to find things he could make better.
- nine_k 1y agoThey also built a language that can be learned in a weekend (well, now two) and is small enough for a fresh grad hire to learn at the job. Go has a very low barrier to entry, but also a relatively low ceiling. The proliferation of codegen tools for Go is a testament of its limited expressive power. It doesn't mean that Go didn't hit a sweet spot. For certain tasks, it very much did.
- IshKebab 1y agoAnd indeed they did come to that conclusion - for Dart 2. Go is the product of like 3 Googlers' tastes. It isn't some perfect answer born out of the experience of thousands of geniuses. I think they got a lot right - fantastic tooling, avoiding glibc, auto-formatting, tabs, even the "no functional programming so you have to write simple code" thing is definitely a valid position. But I don't think anyone can seriously argue that Go's handling of null is anything but a huge mistake.
- frollogaston 1y agoSame but with Python and NodeJS cause I'm doing less performance-critical stuff. Dealing with type safety and slow builds would cost way more than it's worth.
- rednafi 1y agoPython and NodeJS bring a whole lot of other problems. But yeah at a smaller scale these languages are faster to work with. At the same time, I have worked at places where people had to rewrite major parts of their backend in other languages because Python/Node was no longer sufficient.
- frollogaston 1y agoI'd have to see it, cause rewrites happen all the time. We had a system written in C++, then rewritten in Golang because C++ was supposedly not good enough, then rewritten back into C++.
- liampulles 1y agoAs the story goes, a couple of Google developers designed Go while waiting for one of their C++ projects to compile.
- zenlot 1y agoIf we wanted speed compile times only, we'd be using Pascal. No need for Go. In fact, if there would be ever a case for me to use Go, I'd rather go for Pascal or Delphi. But there isn't, it just doesn't fit anywhere.
- rednafi 1y agoI understand the sentiment as I feel the same about Rust. I’d rather raw dog C++ than touch Rust. Doesn’t make sense and I could come up with some BS like you did and make my case anyway.
- pjmlp 1y agoYes, because the way Google uses C++, and the developers have well known positions against C++ anyway, coming from Plan 9/Inferno and Oberon backgrounds.