Earlier quoted context omitted.
Well put and I agree with most points but > Go is not a fun language to program in Not having to think about how something should be done in the most elegant way, instead focus on the problem at hand is a lot of "fun"
True, fun is certainly different for everyone! I also enjoy being able to just focus on a real world problem, but I also programmed Scala professionally for many years, and I found it a lot more fun purely from the point of view of writing code. Writing a really elegant for comprehension or using currying in clever ways to make your code "elegant" was just enjoyable in and of itself, regardless of what problem you we…
I want off Mr. Golang’s Wild Ride (2020)
161–170 of 477 posts
Re: I want off Mr. Golang’s Wild Ride (2020)
#162Earlier quoted context omitted.
Inversely, virtually all languages with "easy FFI" end up being even more hostile in that a significant chunk of the ecosystem depends on C build tooling which is almost always fragile: C build systems have implicit dependency management, so you don't know what dependencies you need to have installed on your system or where they need to be installed. This means that something which builds on one machine may fail to b…
The Rust ecosystem does one better and packages the C libraries and build configuration (including making it portable across platforms) as part of the crate. So you just add the dependency to your Cargo.toml and the C library will build as part of the regular `cargo build` process.
In Go, it's just `CGO_ENABLED=0 GOARCH=armv7 GOOS=linux go build` for pure Go programs.
Re: I want off Mr. Golang’s Wild Ride (2020)
#163Go has a lot of issues. Some of them would be easily fixable if people promoting and developing Go actually admitted the problems. However, the fanbase usually acts as a cult pretending that issues are features. Thing is, just like broken, hackish dependency "management" had to be fixed (introducing tons of complexity for the sake of not destroying backward compatibility), other problems will have to be fixed as well…
> However, the fanbase usually acts as a cult pretending that issues are features. Per Rob Pike (Lang NEXT 2014), golang was created for fairly young programmers that are fresh out of school and don't know many other languages. So, something I've observed: When somebody doesn't know many things but is building a career, planning their life, on one of the things they know, they're going to take that one thing more per…
In my experience most Golang developers are highly experienced... Same with Rust.
Re: I want off Mr. Golang’s Wild Ride (2020)
#164Earlier quoted context omitted.
The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…
> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.
Re: I want off Mr. Golang’s Wild Ride (2020)
#165"Cross platform handling is bad." That's all I've had the energy to extract. Isn't cross-platform software always a nasty compromise between not being able to do anything useful and being too specific to some OS or another. IMO go write a library if it really annoys you. There are much more unpleasant problems that I've had with the language but I've had more with C++ so ... it's a step up for me.
Re: I want off Mr. Golang’s Wild Ride (2020)
#166Earlier quoted context omitted.
The latter is a much stronger argument than the former (no idea why people get so worked up about character counts), but even then, "shit" is really strong considering how often one experiences exception traces when using an application written in Python or Java or some other exception-based language. Point being, we should probably evaluate error handling schemes based on results rather than ideology (even though I…
Screen real estate is limited, especially vertical real estate. Compared to languages with saner error handling, I can read approximately 25% as much Go code at once. That's a real cognitive burden when maintaining code or learning your way around a new codebase, which seems especially egregious from a language whose community consistently proselytizes about how the lack of language features is great for maintainabil…
Re: I want off Mr. Golang’s Wild Ride (2020)
#167I took a look early on at Go. I tinkered with it and decided it would not work for me.
It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decades. It was clearly the result of a lot of NIH syndrome. It was built by Plan 9 guys to solve their problems on their preferred platform. For their purpose, I am sure it works just fine and is very comfortable for them. To expect it to be adapted to other kinds of problems and platforms is just wishful thinking.
For years, I have been hearing that Go will get generics and that it will be easy to add and use. I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. This made me skeptical that Go with generics would be as good as it could be. Now Go finally has generics and many are not happy. This should not be surprising.
This is why I see it as an abusive relationship. That partner you are so fond of is not going to change. Accept that and stay or move on.
Re: I want off Mr. Golang’s Wild Ride (2020)
#168Earlier quoted context omitted.
And as a bonus, be statically linked with all the benefits that brings.
I recall statically compiling Rust to be a big pain (like, actually statically compiling, no dynamic dependencies on libc in Linux). I assume this is all the more true with arbitrary C dependencies?
If you have C dependencies, then it does become a pain, depending on how well those dependencies' -sys packages interface with whatever build system they use.
Re: I want off Mr. Golang’s Wild Ride (2020)
#169> I've been suffering Go's idiosyncracies in relative silence for too long, there's a few things I really need to get off my chest.
this notion that because someone designed a tool in a way that is not exactly the way you wanted it to be is a form of suffering is ridiculous. You're not suffering, you are at best mildly inconvenienced.
> Most of Go's APIs (much like NodeJS's APIs) are designed for Unix-like operating systems.
This whole angle of attack is frankly absurd. Go's APIs (and the APIs of countless other ecosystems) are Unix-like because the Unix-like ecosystem is structured around interoperability. The reason that Go's APIs for dealing with Windows aren't as good as for other systems is that Microsoft has at every turn made their environments subtly different from other things often for no good reason at all.
This whole thing with making a file path with arbitrary byte strings that aren't representable in utf-8 is frankly embarassing. He's spinning a yarn about filesystem APIs and then goes on a tangent about string handling and how great it is that Rust displays one thing and Go displays another, but here's the rub: he used the `%s` format string operator, whose entire function is to print the uninterpreted bytes; if you want to print something quoted in a string-safe manner, you use `%q`. That entire section can be summarized in three lines of code:
s := "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98"
fmt.Printf("Hello, %s\n", s)
fmt.Printf("Hello, %q\n", s)
https://go.dev/play/p/NVbLMhb7UkVHis examples are always like this: long, convoluted, and so complicated that people who know what's going on don't bother to interject because it's an impossibly tedious waste of time.
Re: I want off Mr. Golang’s Wild Ride (2020)
#170Earlier quoted context omitted.
And as a bonus, be statically linked with all the benefits that brings.
I recall statically compiling Rust to be a big pain (like, actually statically compiling, no dynamic dependencies on libc in Linux). I assume this is all the more true with arbitrary C dependencies?