For fucks sake. And I get downvoted for this? Are we serious?

I've been articulating the problem for months now as have others. Obviously there's no intention from the benevolent dictators of HN to change anything. That's fine. Their house, their rules. But I for one refuse to put myself through the toxicity of a troll-gutter.

I'm done here.

Bye

>> 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.

> 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.

> 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.

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

>> 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.

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.

> 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?

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.

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

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

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

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.

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.

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!

> 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.)

I understand the layoffs in Airbnb and the airlines. But I'm not sure I can justify the layoffs in linkedin. If anything there are more people looking for a job than before so I'd guess more people would go for the premium (paid) service at least in US.

Beats me...

I'd add to the disadvantages:

* Cold start time may hurt your latency

* Max timeout which makes serverless a non-option for long-running processes

Maybe you're looking something like this https://docs.tremor.rs/

That's true but it also goes the other way. Assume you're living in a mid-range western-world city, e.g. Berlin. And assume you're competing with a similar to you dev who's living in Cebu (Philippines). The difference of what constitutes a good salary between you two is way too large for the company offering a position to ignore.

Insert obligatory warning about timezones here.

Seriously, I've been working with the US west coast for most t of the last decade (i'm in Europe) and its reall realluy hard because of timezones.

So companies offshore north-south instead of east-west, I don't want to compete with Latin American or African salaries any more than Asia.

If SV companies genuinely embrace the idea of working with much cheaper remote developers I don't think you'll have a choice.

It's not that easy tbh. Languages are also important.

Like I guess Brazil and Argentina would work, but you'll essentially just cause wages to equalise over time.

This will happen to some extent, but it's much more likely that US software engineers pay will normalise first.

Sound great, from a utilitarian pov.

I was afraid of that myself -working somewhere in a middle-ground country. That my job would soon be offshored to a cheaper country in a race-to-bottom way. But then I started looking for a remote job and I was either ignored or turned down for people that were: 1. native speakers 2. remote but within reach 3. strong OS committers etc

I don't think that companies can offshore anything but the trivial tasks which you wouldn't want to do anyway. They're definitely after it and would love to but in my experience I don't see it happening. On the other hand you find yourself competing with very high quality devs from all English-speaking countries in the world.

Dunno. I guess we'll see how it plays out. Either way COVID seems to be driving things now and for foreseable future. Not much you can do.

IMO you should have ended the interview the moment you detected that you were being treated poorly. Let alone not doing the homework.

There. That's it. All this is a far-from-optimal filter for the total strangers. Get a foot in the door with an established insider and you get right to the last interview(s). No WBs, no take-home projects.

Does this actually work in practice? From my understanding knowing someone might get you past the initial HR / ATS hell to a first round, but you mostly have to follow typical processes after that.

In some cases yes.

In my experience they were even apologetic "sorry, we have to do this, let's get over it".

Once the pull to get you in is in place - it will help to put a checkmark in internal bureaucracy checklist and minimize unrelated interactions.

I've done this a couple of times. All for German companies in Germany. The last one took me a weekend. They liked it and booked me a ticket for on-site. Where they whiteboarded the hell out of me and rejected me on the basis of not getting the right answer fast enough and using wrong syntax in a couple of statements. And there was not a single question about the take-home project.

After that I just decided I'm not going to put the time and effort in that sh*t anymore. I'm not even going to go out of my way to accommodate interviews in my working hours.

Next time it happened I replied back that I'm not interested. For the record, they wanted a silly automation in AWS and kubernetes. Most of the time would go to setup everything up as my future-employer assumed that I had an AWS account and that AWS is the only cloud that matters. (I work on a different provider daily).

Both times it was automotive-related IT. Dunno if that's something to do with it.

My take-away so far: Whiteboard sucks but at least it respects your time while the take-home proj does not necessarily keeps you from wb and is usually ridiculous to a large extent.