8 ms·
I still don't think Go is a good language. I had notable experience at Google and the following things constantly bugged me: - It was very difficult to read. W
by kevincox 6y ago
I still don't think Go is a good language. I had notable experience at Google and the following things constantly bugged me:
- It was very difficult to read. When trying to review the code every detail was left out. While each line was simple it was hard to actually get the high-level picture of what code was doing.
- Very error prone. Maybe it isn't C dangerous but "defaults are useful" is the breeding ground of bugs. The number of outages we had due to trivial Go bugs was embarrassing and time consuming.
- Some simple things are just too hard. Most of these boil down to lack of generics. For example inserting an element into an array needs multiple lines of code.
- Many common functions and buitins have very questionable decisions that are huge footguns. Especially the fmt library. (It tries its absolute hardest not to fail. Instead it just outputs garbage and "succeeds")
I get that it is easy to write, and that each line of code is simple. However I think they went way too far.
I see Go as a slightly higher level C. You get better package management, memory management and interfaces. However C is still way too basic for my preferences.
It is a weird spot though. It is sitting in about 2x C performance. It is unclear what to recommend in that spot as many languages are significantly slower. Rust is probably roughly as productive, but much harder to learn. Most of the interpreted languages are significantly slower.
There are some JVM languages that are better and have similar performance. However there is a memory and startup overhead. However I think they make more sense in the end. JavaScript is also a pretty good choice. It is in roughly the same performance realm but much more productive I think. (Especially TypeScript).
- skyde 6y agoAre you saying that python is better than GO on syntax alone? Like easier to review code ...?
- kevincox 6y agoIn many ways yes. The high level code it is far easier to review the semantics of the change. With Go I feel like I am too bogged down in all of the unimportant implementation details. (I don't really care how you implemented `map` I don't need to see the 4 lines of that loop) Of course with minimal static typing it is easy to miss more "typo" style bugs but those tend to be caught fairly easy in tests and are obvious when they fail.
- wahern 6y ago> With Go I feel like I am too bogged down in all of the unimportant implementation details. But then when people praise Python and Rust, getting bogged down with "unimportant implementation details" like specialized async typing and colored functions becomes an absolutely essential and useful aspect of the language. There's just no accounting for taste...
- kevincox 6y agoI agree that async creating coloured functions is a compromise. However in practice I don't find it too distracting. At the very least it is less distracting then Go's error handling. (Although IIRC that is going away thankfully) However if you put N:M threading against 1:1 threading then you can argue about that all day. I think the implementations in Rust and Go are very effectively implementations of each model. The threading model difference is *not* something that I hold against Go. It is possible for a language to handle some things well but have other downsides that makes me prefer to avoid it.
- mpfundstein 6y agoin all seriousness, but how many golang and python code bases of roughly equally the size have you reviewed and examined? Python is HELL if you are new to a codebase. Everyone has their own conventions, lack of typing means you need to do a lot of guesswork, dynamic calls break up control flow etc. Yes, go is more explicit (lack of generics...), but at least its straightforward. Just compare k8s codebase with nomad with your homegrown stuff. It will likely look a bit like the same sauce...
- Agingcoder 6y agoWell, like everything in life, it's not perfect. However, after initially intensely disliking the language, I found out that I was surprisingly productive, and that the lack of abstractions made for very readable code. The toolchain and standard library are also very good (coverage, race detector, cross compiler, etc). Compared to python, I get fewer bugs (no surprises, and compile time instead of runtime) and faster code, and compared to rust, I get readable code. It's strictly better than C / C++ (lack of generics aside until now) , unless you have strong performance constraints (and I'd probably use rust these days anyway). In the end it's good at some things, not great in any way, not highly appealing but curiously effective. I think I like it just because it works surprisingly well, even though it initially went against my gut feeling.
- kevincox 6y agoI totally agree. I don't think it is possible to build a perfect language. However I don't think there are many sets of requirements were Go is the best option. However there are many situations where it isn't a terrible option, and maybe that is its secret.
- Agingcoder 6y agoThis is a very good point. Basically bounding the worst case can be more valuable than optimizing for a specific use case.
- eznzt 6y ago>There are some JVM languages that are better and have similar performance. How about a single example?
- kevincox 6y agoJava I mean you can argue about the productivity all day but I think I would slightly prefer it. But there are a handful of JVM languages hovering around 2x C performance (after being warmed up)
- vips7L 6y agoCan't wait til they complain that Java is too verbose while they're manually writing for loops in GO.
- DLA 6y agoJava is insanely verbose. Fact.
- vips7L 6y agoIts less verbose than Go. Fact.
- Jyaif 6y agoDo you have anything to back this up? I haven't done any scientific comparison, but my personal feeling is that Go is terser.
- vips7L 6y agoYes the simplest being writing a loop to filter or map. In go you will be writing full loops and intermediate variables. I'm not going to list the go versions because I'm on mobile. In Java: arr.stream().map(SomeClass::someFn).collect(toList()) How about writing a min function for all number types? In go due to no generics you'd have to write a function for every type. In Java: static <T extends Number> T min(T a, T b) { if (a < b) return a; return b; } My comment was more tongue in cheek at the guy above me for stating "facts" though.
- yrgulation 6y agoSorry to hijack your comment about Go, and the thread about Rust. But has google at any point tried using D for anything? Seems like an easy to read language, implements templates and has good portability - wondering why its not gaining traction?
- vips7L 6y agoD is amazing. High level AND low level when you need it. The ecosystem is just lacking and doesn't have a big player backing it like go, java, c# etc.
- kamranjon 6y agoI have worked on a considerable amount of Go code over the last 5 years and I diametrically disagree with almost every single one of your points here. Just wanted to share. Basically take any bullet from that list of what you think about Go and I have the exact opposite opinion, not sure what that means in the end but I found it interesting: - Go is easy to read - Go is much less error prone and encourages good testing habits - You can build complex things with very simple primitives without relying on magic. - The fmt library just works
- DLA 6y agoTotally agree and very well said. Go just works. I find it insanely easy to read. The comments about the JVM ... no. thank. you. Single no-dependency go binaries are beautiful. Cross compilation and hooks to C when needed are also big wins.