[malechimp]

>> I want a very simple language for my teammates to learn

I feel this is said in a demeaning way plus it is not true IMO plus if I had a penny for every time I read that I'd probably be much richer by now.

Go is not a simple language to learn correctly. It is only simple if what you're trying to do is simple which goes for almost any production language that is not designed to drive you nuts. And it should be simple at that. A language is a tool. It should be easy to use in order to solve easy(ish) problems and feel progressively more difficult as the problem domain gets more complex. Having a language that gets in the way right from the beginning makes you focus on the language rather than at the problem at hand which makes for bad overall solutions.

Example: If you still feel that Go is simple to learn try to read some kubernetes code.

Having said that, I accept that Rust is way harder to get to grips with. My question is why should I though? I understand the appeal of Rust up to a point but I think much of it as a bad form of machismo - something quite common in the industry and also quite destructive. To me Rust is a better alternative maybe to C and C++ but that's about that. If you program systems and you absolutely do not want a garbage collector doing its thing then by all means go for it. For everyone else though I don't get why you should try to climb your project mountain in flip-flops. Not saying that it can't be done. Not saying that you won't get extra wow points for doing it. Just saying that you don't need to.

[mountainriver]

> If you still feel that Go is simple to learn try to read some kubernetes code

The Go code in K8s is simple, the system of Kubernetes is complex

Rust isn’t about machismo, it’s about high performance computing. Try writing graphics or machine learning code in Go, it’s not about being tough it’s about having a tool that can actually do the job.

[cies]

> it’s about high performance computing.

And zero runtime cost abstractions. And having a non-profit to shepherd the project (and thereby having a good chance that you may influence the project). And strong typesafety. And design by committee (see how async-await was "agreed" upon).

Also Rust is called a multi-paradigm prog lang in the article: I dont think so. Scala is. Rust is not. It brings as much FP features into the language without sacrificing its core paradigm: an imperative systems language.

[yahyaheee]

Yea I would agree, Rust is imperative with some functional concepts baked in like a lot of languages have.

[malechimp]

>> it’s about high performance computing.

Yes. That's what I said. So, advocating for Rust in a non-high-perf requirement project makes for extra effort/optimization where it is not needed. Speed of dev, correctness, ease of maintenance are needed though. Optimizing for the sexy rather than the needed is a textbook machismo attitude. Good for CV-builders and for ego maybe but it usually hurts the company and the maintainers down the road.

[yahyaheee]

Yea agree, if your looking at it to just understand what writing a CLI in Rust is like, there are a lot of use cases in which a CLI can benefit from performance, but this isn't one of them and he doesn't call that out.

[harpratap]

> The Go code in K8s is simple, the system of Kubernetes is complex

Can you link me to a doc which explains the runtime scheme type system of Kubernetes? Could never wrap my head around how that even works. And why they had to even do this in the first place?

[yahyaheee]

This is the best I can find https://kubernetes.io/docs/reference/using-api/api-concepts/ there used to be a better doc on this but I can't seem to find it again.

Runtime scheme and the k8s machinery can be pretty awkward. Scheme is just a way of registering the available datatypes by group/version/kind so the client can look at any given object and figure out if it knows how to decode it.

[harpratap]

This doesn't explain it at all, specially the ecosystem surrounding schemes - informers, cache clients and various other code generators for typed as well dynamic API clients

[majewsky]

> why they had to even do this in the first place?

Because they wanted stuff like Watcher<T>, but Go does not have generics.

[mhaberl]

As I see it, Go could be a nice alternative to Java or C# for most problems, and Rust looks like a nice alternative to C++ for most problems.

One could go and compare Javascript to COBOL code solving some random problem, and perhaps even that can be helpful in some way, but the result of that comparison should not imply that one of these is, in general, better than other.

I guess Rust and Go are compared so frequently because they are both becoming very popular and people are tring to figure out which one of them is worth investing time to learn.

A lot of these comparisons remind me of java vs c++ discussions 2 decades ago.

[tapirl]

Most code in the k8s project is easy to read and understand. There are really some parts in it which are not so easy to grasp. One reason is k8s was written in Java and there are several over-abstractions in the code design. The other reason is there are too much generated code.

I do agree that thinking Go is simple to learn is bad in learning Go (I mean it is not good to learn Go seriously). On the other hand, I also think Go is a quite readable language.

[untog]

Not having garbage collection isn’t a personal preference, it’s something that enables high performance, low footprint programming.

I’ll agree that I personally am a little confused by the HTTP web server frameworks I see written in Rust, it feels like overkill there. But Rust definitely has a place. If you don’t see it that’s absolutely fine, it just means you’re not in a space that would benefit from it!

[zeroxfe]

> Go is not a simple language to learn correctly.

I mean, can't that be said for any language? I've worked with a lot of languages over the decades, and find Go extremely refreshing in it's simplicity.

Kubernetes is an extremely complex system, and Go isn't the reason that k8s is hard to understand. (I could say the same thing about C and the Linux kernel.)

[flumpcakes]

I think there are plenty of tools out there that wouldn't be classified as "systems programming" but frankly should be written in an extremely performant way.

A lot of the excuses I see for slow (or just bad/sloppy) code is that it would cost more to the business to improve it than to leave it alone. This is a fine argument but I don't believe the cost analysis is ever correct.