Today’s JavaScript, from an outsider’s perspective (2020)

I was hoping a young Amish farmer goes on his rumspringa to decide if he wants to continue on as Amish farmer, he likes the modern world well enough but is so scarred by the JavaScript experience he runs back to the safety of the church, never to stray again.

I won't disagree with you about the needless complexity, but OTOH programming does have a certain level of essential complexity, and profanes don't realize that "just upload the CSV" is fundamentally not an easy task; think about what you'd need to do if you were to do it from scratch in assembly. Lines in a text file is not something "the computer" or many OS have a concept of. I think a few developers could ragequit.

Of course, there is the "batteries included" solution - that is gluing together libraries with a simple language. Here I would rather see something like Lua rather than Python because OO is already an interference for normies. This is doable, the particular failures of Python here (or any of the languages I've mentioned) are to blame on Python's ecosystem (perhaps being too normie-friendly is a curse, because you sometimes end up with poorly done tools and libs - I see it in Lua too).

One last word: I learned programming from books alone with Basic (back in the days when phones had wires and I didn't have to shave). The books provided the source of simple games that I were to type in (Basic was a CLI but you could list and edit lines, better than the "Python Box" :-), test and then hack. This is a much easier approach than starting from scratch, and by the end of the Twitter thread it seems that this is what this person eventually came to - people would give them a basic program they could hack.

I don't have a single, definitive, clear solution -- as pointed out by others -- nobody does. It's not a simple problem.

That doesn't mean that steps can't be taken to improve the situation, perhaps dramatically in some cases.

1) Enforced MFA to publish a crate -- credential theft is semi-regularly seen as an attack vector.

2) Strong links between the "source ref" and the specific crate versions. An example of this done super badly is NuGet. All of the hundreds (thousands?) of Microsoft ASP.NET packages point to the same top-level asp.net or .net framework URLs. E.g.:

https://www.nuget.org/packages/Microsoft.Extensions.Configur...

Links to "https://dot.net" as the Project Website, and "https://github.com/dotnet/runtime" as the repository. This couldn't be more useless. Where is the Git hash for the specific change that "7.0.0-preview.4.22229.4" of this library represents? Who knows...

3) Namespaces. They're literally just folders. If you can't code this, don't run a huge public website. This is more important than it sounds, because wildly unrelated codebases might have very similar names, and it's all too easy to accidentally drag in entire "ecosystems" of packages. Think of the Apache Project. It's fine and all if you've "bought in" to the Apache way of doing... everything. But imagine accidentally importing some Google thing, some Netflix thing, some Apache thing, and some Microsoft thing into the same project. Now your 2 KLOC EXE is 574 megabytes and requires 'cc', 'python', and 'pwsh' to build. Awesome.

For example, in ASP.NET projects I avoid anything not officially published by Microsoft and with at least 10M downloads because otherwise it's guaranteed to be a disaster in 5-10 years. Ecosystems diverge, wildly, and no single programmer or even a small group could possibly stitch them back together again. Either it's a dead end of no further upgrades, or rip & replace an entire stack of deeply integrated things.

4) Publisher-verified crate metadata / tags. You just cannot rely on the authors to be honest. It's not even about attacks, it's also about consistency and quality. All crates should be compiled by the hosting provider in isolated docker containers or VMs using a special "instrumented build" flag. Every transitive dependency should be indexed. Platform compatibility should be verified. Toolchain version compatibility should be established for the both the min and max range. Flags like "no-std" or whatever should be automatically checked. CPU and platform compatibility would also be very helpful for a lot of users. The most important one in the Rust world would be the "No unsafe code" tag.

This would stop "soft attacks" such as the guy spamming C++ libraries as Rust crates. Every such crate should have been automatically labelled as: "Requires CC" and "Less than 10% Rust code".

Similarly, if a crate/package changes its public signature in a breaking way, then the publishing system should enforce the right type of semantic versioning bump.

Essentially, what I would like to see is something more akin to a monorepo, but not technically a single repository. That is, a bunch of independent developers doing their own thing, but with a cloud-hosted central set of tooling that helps gain the same benefits as a monorepo.

I'm expecting a lot of arguments along the lines of "that sounds like a lot of work, etc..." Meanwhile Mozilla had a large team for this, millions of dollars of funding, and did not do even 0.1% of what Matt Godbolt did in his spare time...

Not every programming project is a project that takes hundreds of skilled engineers. Not every programming project needs to deliver a product for others to use.

What Aella wants to do is something pretty simple, and it's frustratinc that this is so hard.