I seriously doubt that a dual-language platform is ever going to supplant Electron. Electron has the major advantage that the entire app is written in one language. And according to Stack Overflow’s 2023 developer survey, 66% of devs use JavaScript, 45% use Python, 43% use TypeScript, and 12% use Rust. More devs use Java, C#, C++, PHP, and C than Rust. So 2/3 of developers wouldn’t have to learn a new language to use Electron, and only a small fraction of the remainder knows Rust.

I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.

I thought it was clear I was saying JavaScript is not a sane language for this very reason

Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.

I used GitLab’s version of Copilot when it was free and that was net helpful. It predicted for loops and stuff and was close enough, enough of the time that it was net positive. Not enough that I’d actually pay for it…

If I designed the schema it is most certainly going to be structured. Unstructured databases are awful.

Sure, there are worse languages and environments to get stuck with. But I can avoid those jobs. And if I get hired as a SomeLang developer and they force me to work in Java or whatever, it’s time to dust off the resume.

I am aware of that, but Java is the most popular language that runs on the JVM. I don’t specifically dislike other JVM languages, though one of my issues is type erasure and that’s partially a limitation of the JVM.

Obviously OpenJDK is superior to dealing with Oracle’s bull. But even more superior (IMO) is simply not using Java. My life has been noticeably more pleasant since I started refusing to touch Java.

To me this is an argument for why Go should not add type inference to function/method declarations. Go is like Rust (I guess, I haven’t used Rust) - type inference works for declaring a variable (or const) and generic type parameters but not for type declarations, methods, functions, etc. I was in the “more inference is always better” camp but now I’m thinking Go has the perfect level of inference. Except for function literals/lambdas. I really want go to infer the argument and return types when I’m passing a function literal/lambda to a function.