lsofzz

Hmm. There are "plenty" of Rust jobs outside of crypto stuff. They are:

- Your typical service driven stuff (aka full-stack/backend/microservice et. al)

- Tons and tons of opensource projects from AWS (investing), Microsoft (investing) and Google (yes, investing) to name a few off the top of my head.

- Startups have so to speak started embracing Rust https://corrode.dev/podcast/

- Embedded Systems <- C/C++/ASM's bread and butter traditionally.

- Rust ecosystem is maturing faster than anything I have seen in the past (ok, maybe Go's ecosystem was fast as well).

Regarding AI and ML stuffs: While I do agree that chasing such hype may be intangible in the very short to short time frame. No doubt, the AI winter may follow a typical curve and follow up with a AI "summer". _Every_ major technology in the past 20-30 years has followed a V curve. AI/ML probably won't be an exception.

I understand that the OP may have hobbies outside of "learning" but making a dedicated time outside of it will yield by leaps and bounds. Always be learning (make time for it) - that's the gist in short without going into the nitty gritties.

Nice. I don't have anything for you but maybe this will be useful:

My two cents: o Learn machine learning, artificial intelligence - fast.ai

o Learn Rust, Rust, Rust and some Go

o Scala is good. Keep it. All the stuff you learnt whilst using Scala and Python will be useful in _Rust_.

o SDE is huge. Try something other can webdev and gamedev.

No matter what others may say next frontier will be roughly these: - Artifical Intelligence - Quantum Computing

Get good at these. Now, is the right time.

Oh no. A really sad moment. My condolences are with him. RIP.

> And you can't find typical business rules on Stack Overflow.

Heh. Thanks for raising. I am very well aware of it.

> Getting this right is much harder than it sounds.

Let's call a duck a duck. Unless, you tell me you are designing guidance system for NASA, I'd be happy to leave this pedantic discussion aside.

> Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase.

Fair dinkum. That's you. You may be biased towards it due to past experiences and I understand it. However, with that mentality where there are no "innovation"(s) involved, you'll only get donkeys that live within the echo chamber. And, may be that's what you want.

My thoughts are with you Woz. I hope you recover soon buddy!

> But because they, especially QA & ops, tend to be viewed as lower on the hierarchy they often have lesser talent filling the ranks.

Geez ever wondered why? It is partly due to the "monkey" work that's required. I feel the "ops" world needs a heavy reset (may sound like broken record again: eliminate toil, eliminate side-effects, chicken/egg problems, test? what test? etc..). Geez and I wonder why positions at "FANG" like places require software engineers to fill in the ops work - the engineers, the thinkers and the leaders at these companies understood pretty early on the importance of "engineering" applied to these "ops" and "qa" disciplines.

> overburden developers

Given by today's standard, _most_ if not all the code I review out in the wild are these: - Search your question on $search_engine - Land to stackoverflow - Copy - Paste - Write some crappy unit test (important but still crappy IMHO) - CI - Boom land on production

Where is this special fairy of "overburden"'ed devs you speak of?

Very few code today are _true_ innovations. It's a pile of abstractions over abstraction shite.

> That is true. It is every one's responsibility to inform mgmt of this and keep open channel.

And vice-versa (should of said).

> overburden developers

Please. Doing a perfunctory role does not equate to "overburden". I'll get grads from a third-world who will _happily_ take the burden off these developers if you so insist.

> I do think management often has no idea how many different specialties and expertise there are within engineering.

That is true. It is every one's responsibility to inform mgmt of this and keep open channel.

> I'm convinced that shift left is just a way for management to eliminate QA jobs and push that work onto existing devs. Just like DevSecOps. Most people can't do that many things at an expert level.

Not necessarily. Those functions carried out by experts are best left to the experts. What software devs in a "shift left" environment _can_ and _should_(IMHO) do is to augment their capability via "self-service" platforms and those experts should do everything they can to make it accessible. It may take few rounds of PoCs/Experiments but it is well worth the endeavour.

I may sound like a broken record. Sorry.

> For roles like QA, Ops, Infosec I've found that the good ones are so much harder to find than good developers. And when you find those good ones, they're worth their weight in gold.

I agree to that 100%. This is why I keep sounding like a broken record to young devs.

To the gargantuan number of people I meet everyday: Shift left in this context talks about SDLC (which is useful but quite old and unsurprising by today's standard).

There are far more important and larger piece of shifting "left" which developers do not yet fully come to grapple with. Let me spell it out for you: - Information Security practices - Platform/DevOps practices - Networking Concepts 101: Are these new 20 something devs cognisant of the famous "fallacies of distributed computing"?

why?

United States of China.

Peoples Republic of United States.

Sounds the same.

> author is focused on the input ("I wrote this in X") not the output (value the user gets)

Possibly, a lot of us enjoy developing X in Y for the sake of doing so. Not everyone may end up caring about the value that the user gets.

I could possibly not have explained as well as you did. Thanks for such a great articulation. It is _exactly_ what I wanted to say.

> It's apparently cheaper to buy Splunk than to a buy Splunk license.

Amen :)

Here's the thing:

Imagine you are in a boxing match, and your opponent looses the fight. The person who wins the fight would tell the opponent that they did well regardless; It's a courtesy. A sane person does not go around the ring saying "Ha ha you lost the fight". Is that right?

Similarly, I disagree that things need to be __that__ explicit.

Yep agree.

Be.

Wrong.

More.

Corollary: Be right less.

Being, wrong is a humble space to be in! Mind you, you can be the smartest chipmunk in the room; But, i think being curious _and_ being inquisitive is more important than *trying* to be right and turning out to be wrong.

RIP, Kris.

Déjà vu I wrote an implementation that _exactly_ did this PoC a decade ago.

Modern network protocols have so much extra reserved bits that you can add pretty much anything want in it; keep going ;)

> Linux has achieved a 3% desktop market share (linuxiac.com)

And the desktop market amongst servers, cell phone, consumer electronics is?

Linux doesn't need to play this game because it has already won it - a long time ago.

A "faster" CPython is a decade plus minus four years old story ;_;

I'll check back in a decade.

> I feel old now, as I continue to deploy Apache :-)

we wrote bash scripts backends. don't worry about being old. keep going ;)

some even had their cgi code running in kernel.. all the more reason to be merrier.

We did this on production (still runs at webscale) but we abandoned dev effort on it for ${reasons}. I _loved_ it though :) Hook Lua on the HTTP event processing stages and add icing on the cake with Lua modules to hand-off non-trivial stuffs..

Run Kubernetes. Install the open-source Kubernetes ingress controller with your favourite load balancer. I'd wager that'd solve majority of your use cases.

this is NGINX Inc. talking. grain of salt.

This is one of the pet peeves of HN submitters and readers :)

Sure, here is my two cents FWIW - Kubernetes is complex for some set of folks but not for others. So, the answer is - depends; On a lot of external factors outside of just technical capabilities of team.

Kubernetes solves many non-trivial challenges but its not a silver bullet. I could certainly learn from Mercedes platform/infra team's "story from the trenches" (they reportedly run 900+ k8s clusters on production:)