Что не так с Go. Цитаты

Антон на стримах

Рассказал про доклад On bloat Роба Пайка и коротенько коснулся критики (Pike is wrong on bloat). Пайк ис вронг - лайтовенький разговор про зависимости.

Но листая бложик нашел парочку занимательных постов:

А потом нашел золото.

Золото

В самое сырдечко мне попали несколько статей. Я сохранил себе понравившееся фрагменты, но ознакомления достойны обе статьи.

I want off Mr. Golang’s Wild Ride

Simple is a lie

Most of Go’s APIs (much like NodeJS’s APIs) are designed for Unix-like operating systems…

…( Дальше большой фрагмент с примерами, где показывается что на винде многие вещи (от прав доступа к файлам, до парсинга путей) отличаются в поведении. И местами реализация просто отсутствует. )…

“But these are little things!”

They’re all little things. They add up. Quickly.

And they’re symptomatic of the problems with “the Go way” in general. The Go way is to half-ass things.

The Go way is to patch things up until they sorta kinda work, in the name of simplicity.

Parting words Over and over, Go is a victim of its own mantra - “simplicity”.

It constantly takes power away from its users, reserving it for itself.

It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness.

It is a minefield of subtle gotchas that have very real implications - everything looks simple on the surface, but nothing is.

fake “simplicity” runs deep in the Go ecosystem. Rust has the opposite problem - things look scary at first, but it’s for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately.

At this point in time, I deeply regret investing in Go.

Go is a Bell Labs fantasy, and not a very good one at that.

If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip something up quickly, but making the result “production-ready” is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all.

Lies we tell ourselves to keep using Golang

Evidently, the Go team didn’t want to design a language. What they really liked was their async runtime. And they wanted to be able to implement TCP, and HTTP, and TLS, and HTTP/2, and DNS, etc., on top of it. And then web services on top of all of that.

And so they didn’t. They didn’t design a language. It sorta just “happened”.

Because it needed to be familiar to “Googlers, fresh out of school, who probably learned some Java/C/C++/Python” (Rob Pike, Lang NEXT 2014), it borrowed from all of these.

Just like C, it doesn’t concern itself with error handling at all. Everything is a big furry ball of mutable state, and it’s on you to add ifs and elses to VERY CAREFULLY (and very manually) ensure that you do not propagate invalid data.

…

you are living in the Plan 9 cinematic universe.

The Go toolchain does not use the assembly language everyone else knows about. It does not use the linkers everyone else knows about. It does not let you use the debuggers everyone knows about, the memory checkers everyone knows about, or the calling conventions everyone else has agreed to suffer, in the interest of interoperability.

Go is closer to closed-world languages than it is to C or C++. Even Node.js, Python and Ruby are not as hostile to FFI.

…

Making Go play nice with another language (any other language) is really hard… Calling Go from anything involves shoving the whole Go runtime (GC included) into whatever you’re running: expect a very large static library and all the operational burden of running Go code as a regular executable.

After spending years doing those FFI dances in both directions, I’ve reached the conclusion that the only good boundary with Go is a network boundary.

Integrating with Go is relatively painless if you can afford to pay the latency cost of doing RPC over TCP

…

All or nothing (so let’s do nothing)

(там большой кусок, который я не вижу смысла перепечатывать целиком. А цитировать куски - потеряет наглядность. Вкратце, там про то, что где-то язык прощает не-инициализированные значения, а где-то нет и требует их. Это непродуманность языка. И требует кучу повсеместных проверок) …

Go as a prototyping/starter language Go is an easy language to pick up (because it’s so small, right?) … All the complexity that doesn’t live in the language now lives in your codebase.