fsdjkflsjfsoij

> That is, when you stripe out all the actions that make javascript slow, it very often ends up being just as fast as a compiled language.

ok...

> In fact, there are some circumstances where it can beat a language like C++ or Rust due to the fact that it has to incorporate runtime information into optimizations.

People used to make the same claim about Java and in every single example I've ever seen the Java/Javascript is extremely optimized, performance isn't consistent across VM versions, and the C++/Rust is extremely naive (usually allocating unnecessarily and not using arenas in hot paths that are allocation heavy).

Trivial benchmarks where all of the significant data structures and networking are done in C++ and the tiny amount of Javascript is just passing some strings around. I guess it's "fast" if you can restrict yourself to little more than hello world where you do nothing more than pass a few strings to functions written in faster languages.

Notice that in the Java, C#, Go, Rust, Swift or Ocaml benchmarks almost all of the underlying data structures and much of the networking stack are built in the respective language. This is not possible with Javascript, Python, Ruby etc. because it would be ludicrously slow and extremely memory inefficient.

> but for what it is, JavaScript is pretty damn fast already.

It's fast compared to other dynamically typed language implementations but it's still very slow compared to basically all of the popular statically typed languages.

This is basically where I am at. Most libraries and applications are trivially typed even in languages with relatively poor type systems like Go and Java. The necessity, or even benefit, of weak and/or dynamic typing is extremely rare and most languages have workarounds or escape hatches for those exceedingly rare cases.

Dynamic typing also makes a ton of optimizations basically impossible and even after monumental efforts languages like Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.

For a trivial example, let's say I have some message type that has multiple variants with differing fields:

    enum Message {
        Action1(String, Option<Mode>),
        Action2(String),
    }

Action1 and Action2 are variants not types and I cannot make functions that take an Action1 or an Action2 as a parameter. To get around this people will often make each enum variant just a container for some struct with the same name but that's more verbose and matching becomes slightly uglier. Code like this is fairly common:

    struct Action1(String, Option<Mode>);

    struct Action2(String);

    enum Message {
        Action1(Action1),
        Action2(Action2),
    }

Ideally I'd like to be able to succinctly say something like:

    type A = B | C

and have A be dependent on B and C but have both B and C be completely independent types.

I hope Go will eventually get sum types but I hope they're better than Rust's where each variant is its own type.

> If you're more of a generalist though? I can see productivity gains of 25% maybe.

I really doubt this. Copilot/ChatGPT are not useful at all for the hard problems and they're not trustworthy enough for the small problems. Even for the simplest things I have to comb over the generated code very carefully because I've seen them be subtly wrong dozens of times in my relatively short use. If I have to go over everything they generate with a fine tooth comb it's just easier and less error prone to write it entirely myself.

> Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay

This is unironically a very serious problem and why most of the best open source projects are basically corporate FAANG projects that are really only open source for optics.

> Seems debatable and debated, reading through the rest of this thread.

Most of the people commenting in this thread haven't looked at the code and anyone saying the two patches are equivalent can be safely ignored. Out of the issues kazinator pointed out, 1 and 2 are definitely major issues and 3 is debatable although it is definitely suboptimal.

> some of those consequences may be deleterious to a project's health

Of course, but I think it might not be in the way the "everyone can be a valued contributor" crowd thinks.

> feel violated and humiliated

A lot of contributors are going to feel like this if their patch doesn't get accepted immediately and the maintainer in this case was extremely respectful even though the offered patch had multiple major issues. Contributors shouldn't feel entitled to free tutoring.

So the maintainer now has to tutor this guy for god knows how long until he gets it right? All three issues brought up by kazinator are reasonable grounds for ignoring the patch. Do you think that the already overworked maintainers should have to spend significant amounts of their time tutoring every potential contributor? Are you going to pay them for that?

A lot of these maintainers are already overworked and don't have time to tutor every single person that wants to put kernel contributor on their resume. A lot of people have this extremely idealistic view of open source but the reality is that the vast majority of patches you receive will be atrocious and you shouldn't have to tutor every single "potential" contributor. This case is even worse since this issue was posted to a security mailing list which means time to resolution is important.

You can't do the exact same thing in Go because Go doesn't have a way to define a sum type yet outside of generic constraints. The closest you can get is using an interface and a type switch but that won't give you exhaustive matching.