If your primary exposure to programming is only typescript or JavaScript maybe you shouldn’t be jumping straight into something like rust.

That completely contradicts any claim that Rust is user-friendly and provides a decent user experience.

It’s from 2015, so its probably what you are doing anyway

No, you are probably not using this at all. The problem with JSON is that this details are all handled in an implementation-defined way, and most implementation just fail/round silently.

Just give it a try and send down the wire a JSON with, say, a huge integer, and see if that triggers a parsing error. For starters, in .NET both Newtonsoft and System.Text.Json set a limit of 64 bits.

https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.maxdepth

I’ve never heard of evading null with a Null object.

This is quite standard, and in fact it's even a safety feature. C++ introduced nullptr defined as an instance of std::nullptr_t explicitly with this in mind.

https://en.cppreference.com/w/cpp/language/nullptr

This approach is also quite basic in monadic types.

I often felt that current ML speeds up newbie devs by effectively teaching them the language and libraries — but slows down experts that already know the stack well from memory.

It depends. You don't need LLMs to write stuff for you that you already know. You use them to take.care of the drudge work or explore things you are not familiar with. Things like Copilot's /explain can speed up onboarding even for seasoned developers, and Copilot can also help you speed up iterations on proofs of concept. For example, I've been using Copilot to experiment with some changes to the software architecture of some projects I own, and it's fantastic at generating code following specific design patterns. It's also fantastic to get it to iterate designs in near-real.time by prompting it with directives such as "repeat the last example but implementing X with design pattern Y and moving the implementation to Z". You are presented with examples that you can browse through and get a taste of what you'd get, but with a fraction of the time. To top things off, you can prompt Copilot to present pros and cons and even propose optimizations.

Like any tool, it has its purposes. You just need to learn how to use it.

I don’t have an account there because of that reputation, and why would I now that I have access to chatgpt?

I think StackOverflow is rolling out a GPT-based service that generates answers to your questions based on SO's data.

You need to train ChatGPT to get it to output decent results. SO seems to be working to do that for you.

This might sound silly but I think that coding challenges like HackerRank, CodeSignal help me improve/learn programming.

At first I thought they were utter crap, and recruiters used them to test candidates on artificial problems that matter nothing and reflected no relevant skill. I still do, they are awful at that. What a complete waste of time and effort.

However, these coding challenges are like crossword puzzles. They present us with nonsense challenges that provide us with the opportunity to employ obscure programming constructs on a multitude of programming languages in a way that rarely happen in real world professional settings. I use them to explore obscure corners of standard libraries, solve the same problem in multiple ways, employ different idiomatic ways to iterate over data structures, etc. That's helpful in a way.

how centeralised GitHub

It's a pointless and irrelevant remark. Mozilla uses Git to track work on Firefox. GitHub provides Git repositories. I can clone Firefox out of GitHub, create an account on GitLab/Bitbucket, push the code there, and GitHub does not feature as a concern at all.

What point can you possibly think you're able to make regarding GitHub?

GitHub is enshittifying everything that has to do with Git.

Nonsense. Speaking as someone who actually hosts the same projects on GitHub and other version control providers, GitHub does not even feature as an implementation detail.

I'm starting to think you're just trolling.

You should care.

I do my best to not waste my time with irrelevant nonsense. It's silly to believe that the version control system you use has any influence on the quality of the software you deliver.

I don't think that this blog post adds much to what's already stated in JEP 444, right in the summary.

I imaging trying to be a professional electrical engineer (despite having a degree)

That's the definition of specious reasoning, and fails to address the point I made.

Which is what putting most of this stuff on the background accomplishes.

The part you're missing entirely is the complexity that's hidden behind the weasel word "most".

The majority of event handlers from a GUI app do not do anything complex, computationally expensive, or blocking. They do things like setting flags, trigger changes in the UI state (i.e., show/hide/update widgets) bump counters, etc.

No one in their right mind would ever consider going through the trouble of doing this stuff in separate threads/processes. "Most" handlers run perfectly fine on the main thread.

Nevertheless software changes, and today's onClick handler that sets a flag to true/false tomorrow is required to emit a metric event or switch a different treatment depending on the state of a feature flag or A/B test, or is required to write a setting to disk or something like that.

How do you draw the line in the sand that tells whether this handler should run on the main thread, should trigger a fire-and-forget background task, or should be covered by a dedicated userflow with a complete story board?

That's the stuff that's hand-waved away with weasel words like "most".

This blog post delivers a crisp mental model to tell which approach is suitable: follow the real time computing rulebook, acknowledge that each and every handler has a time budget, and if a handler overspends it's budget them it needs to be refactored.

Does it have to?

If you're a developer looking for a pastime working on a personal project, no. You're free to waste your time and effort doing anything that pleases you.

Everyone else in the world only bothers with something if it provides any value at all. If a project such as this one fails to provide any value them no one will have any reason to waste their time with it, no matter how many times you rewrite it in Rust.

It’s very weird to me that Python, as an inherently untyped language

I don't think this is true. Python is dynamically typed, but types exist. More importantly, Python is the poster child of duck typing. What is duck typing if not a way to implicitly specify protocols? If you're relying on protocols to work, why not have tests for it? If you want to test protocols, aren't you actually doing type checks?

If typing is a good thing,

...which undoubtedly is.

(...) why not make it an optional first-class part of the language?

It already is, isn't it?

But some people already have Python code that does not do type checking. What would be the point of refusing to run that code?