Hacker News Reader

Comment by throw_m239339 | Hacker News Reader

> - Go aims to be simple enough for many engineers to be productive with little investment.

Go isn't simpler, there is just a defered cost engineers pay later on when it turns out one cannot just do away with complexity by deeming it irrelevant.

View on HN

But swift isn't as easy as python or javascript either. It is arguably more complex than Java, C#. And probably more complex than Kotlin. It is sure less complex than scala.

IMO Swift is easier than JS or python for medium to large projects. Once you get to a certain scale of codebase where you can't keep all the systems in your mind at one time, weakly typed, interpreted languages start to reach a point of diminishing returns, and the inability to catch issues at compile time starts to be missed. You can mitigate this by writing a lot of tests, but this creates a large additional workload which more than outweighs the additional complexity you would have encountered working with a language like Swift in the first place.

I know the advantage of static typing (see my other comments).

Swift just seems quite more complex for average programmer.

I think one advantage of Swift, as compared to say Rust, on this topic is that one of it's core values is the concept of "gradual disclosure". In other words, Swift is designed in such a way that you can start programming at a low level of complexity and produce functional programs, and over time you can introduce more complex and esoteric concepts into your code as you become more familiar with the language.

If you're jumping straight into a large, mature code-base I can understand how it might seem complex, but it's very possible to write Swift code which is as simple and readable as Go code. The same can probably not be said for C++ or Rust, where there's a certain baseline complexity which cannot be escaped.

Some FUD right there... What exactly is the deffered cost? Give real examples please.

I love Go, but there is a strong case that Kubernetes has a messy codebase because Go didn’t have good dependency management or generics when they started it. The strength of the ecosystem in other areas let them get started and now they have the tragedy of success, a la Wordpress.

Part of the issues with Kubernetes is that it started as a Java project and then it became a Go project. If anyone started a large Go project with that mindset it would look messy no matter what you did.

Can you point to any large Go project that isn’t a mess?

I agree that from a single sample you can’t reach conclusions, but “it was their fault” isn’t a great defense.

Can YOU point to any large project that isn’t a mess?

Servo

Ahh with 3250 open issues and 8k closed ones? With the main-driver being Mozilla?

Isn’t mess relative to the beholder of the eye.

Many large projects may look like a mess but their success is because they got the high level architecture right and perhaps had the moat of a large tech behemoth behind them.

VSCode, Tensorflow, Kubernetes, Go, Typescript, React. These are a few that come to mind.

At a high level, they are all fantastic projects and perhaps messy in their own way, but they are absolutely fantastic, hardened proven codebases with ~millions of users.

Is rclone a mess? I don't do Go, but some glances at it don't scream "mess". https://github.com/rclone/rclone

https://github.com/thanos-io/thanos

There is one video about the Kuberentes code base: https://www.youtube.com/watch?v=4VNDjwzzKPo and it has nothing to do with Go language iteself, it's about organizing the repo and code strucutre.

Kubernetes is a complex distributed system with over 2M loc, not matter what the language you use there going to be some issues.

It's probably one of the largest open source project out there.

2MLOC is too big for what it’s supposed to be doing. That’s a sign that something went wrong. I wouldn’t blame Go qua language per se, but the lack of generics and lack of dependency management (when they started) couldn’t have helped.

Yeah lets just use Docker Swarm or Nomad. Or which features would you remove to make it less bloated?

The argument - as I understood it knowing only little about Go and Kubernetes - wasn't about bloat in application features, but bloat caused by the language. The stated argument was "missing generics" - missing generics means that similar algorithms have to be re-created multiple times instead of being reused. Thus comparing this tonnaother language might be interesting.

For example C++ is extremely powerful in writing generic code: Make it a template and and provide a set of of traits to modify the behavior and you get a set of algorithms you can re-use for anything – at the cost of unreadable code in the impelemntation (if you aren't careful; with a chance of quite precise code on the call side) and of course with the bloated version in the resulting binary (after compiler instantiated and inlined (thus copied) everything; where the programmer typically doesn't have to care (till the binary is too large to handle) all of it)

So the better question ist ... What code got duplicated exactly and if the one mentioning can't give examples which make a dent in 2MLOC then it is not due to the language in the first place.

I assumed it is about features because there are really a lot of features inside Kubernetes which are not available in Swarm or Nomad by default.

2 MLOC is insane. I assume some of that might be test code and other infrastructure, and it's basically impossible to compare apples to apples in terms of code size. But for reference, 2 MLOC is around the same code size as PostgreSQL, which is also a complex distributed system, has arguably a lot more user-exposed features and a long history, and is written in C of all things.

Kubernetes is exception, not the norm.

Because of no overloading and generics, you are often forced to repeat code or resort to unsafe runtime practices.

Everyone is posting some stuff about the kubernetes codebase, but:

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

The monotonic time thing is an especially good example.

Reply on news.ycombinator.com