However, at this point, I'm mostly of the opinion that langs need some notion of mechanical sympathy if they want to be used for high-performance. JS engines probably have tens of millions of dollars of dev effort poured into them by now, yet they get soundly beaten by WASM, which is much younger. The conceptual foundation matters a lot.
That said, there's probably a nice space for an ergonomic, reasonably fast PL that sits between Rust and JS.
Other than not running natively in web browsers, isn't that language called Ocaml?
I'd written off Dart as "Google's Swift" for the most part, but this makes a lot more sense. Thanks for the comment.
And JS engine JIT codegen modules are put to good use compiling wasm.
My initial instinct is that putting such considerations behind a preprocessor syntax has the disadvantage of making them more opaque and magic, and that I personally would continue to do such things more explicitly - which I realise is an ironic thing to say about an untyped, interpreted language, it's probably just the little pseudo "grey beard" on my shoulder which occasionally whispers silly things about "building their own computer out of rocks and twigs".
I guess the point is that there's a balance to the cost vs benefit: making it more convenient (what you call ergonomics), making it more accessible to those that were less likely to manually use that technique, and perhaps resulting in an average of more performant code; but at the cost of more obscurity, and more "magic", perhaps resulting in less educated programmers.
I'm probably overthinking it. Ultimately this argument even applies to for loops, but it's worth being conscious of that cost - it's likely a good idea.
> Another idea to make Typescript–– a bit less restrictive and more ergonomic, would be to use reference-counting of objects, and then try to optimize most away using compile-time reference counting as pioneered by Lobster. This gives most of the advantages of manually managed memory, but makes the ownership model much easier to reason about. It is however slightly less performant, and more importantly, makes performance less predictable, since it becomes more reliant on compiler cleverness.
Even Rust can hide actual performance behind abstractions, and I've already been bitten by that a few times.. Not sure what the right solution is here, but I agree that it's super important to think about this when designing a language like this.
What projects were you working on that required that? It sounds interesting
Beyond that, it's more of a personal philosophy than a requirement (I could easily have done all those things more carelessly, but the result wouldn't be so nice, some people's laps would be hotter, and some people would end up with a slow or jerky simulation). I like things to be efficient, I enjoy finding a balance between "efficient" and "minimal". That doesn't mean I avoid GC all over the place adding unnecessary complexity and over optimizing, it just means being considerate where it matters and "idiomatic" where it doesn't - in a physics engine (or any kind of posteriori simulation) it matters because it's running on an interval and will constantly cause perceptible GC hiccups if you don't be considerate with memory.
It's certainly not helped by the latest language fads just completely flooring the GC gas pedal; special mention should go to for...of creating a brand new object for each loop iteration. That's usually the first thing I rip out of tight loops.
A bit of care can make this stuff go 3x fast on PC, and I've gotten completely unusable experiences on mobile (most websites) to be 30-40fps.
I was doing some high-level research on a related question the other day: https://transitivebullsh.it/webassembly-research-9e231b80e6d...
I know you've responded to a few people on here that Assemblyscript doesn't address the main issues you're talking about in the article, but honestly it does have a lot of things going for it.
I'd love to see a more direct breakdown of this space that explains why prior works like assemblyscript, nectarjs, walt, etc all fall short, and where an ideal solution would need to do better.
^^ this is the type of thing I'd love to chat about if you're interested btw
I support efforts to tune existing tech stacks. But there is such a more direct path to performance, reliability, etc etc by dropping (alt)JS entirely now that anything can compile to WASM.
I suspect that if you could come up with an easy way to express a large tree really efficiently in a TypedArray in a relatively generic way, that you already will do better than most attempted solutions here.
Maybe there are some ideas there.
It doesn't look like you're making the same mistakes, but why trigger that prejudice?