111–120 of 186 posts
I don't want to write a webapp in Rust. It'll always be second class (though maybe that won't be a problem if the WASM apis get good enough...).
I'm continually surprised by the Rust -> WASM pressure. I see projects like Redox and Servo and ripgrep and Tokio and, well, native or systems level things being it's true calling. I don't want to write a webapp in Rust. It'll always be second class (though maybe that won't be a problem if the WASM apis get good enough...).
Very few of these changes are VM specific or likely to change (or any more so than WASM implementations)
- choose your algorithm carefully - make sure you’re paying attention to the data you’re applying the algorithm to is a good fit - pay attention to arity & GC pressure.
None of these are hard to do in JS & most of the VM debugging was to help identify problems in existing unoptimized code.
The rest are lessons you can take into ANY JS data processing.
The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back th…
The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).
The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…
Earlier quoted context omitted.
One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?
>how does correctness transfer? The same way it transfers when the language is compiled to x86 instructions! By adding a pre-written and pre-compiled runtime.
Earlier quoted context omitted.
What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.
It's not: the TypeScript type system is unsound (accepts code that violates it), and there are no runtime checks, so it doesn't actually guarantee anything: a TypeScript variable may in fact contain any value regardless of its declared type. I'd say the best type systems are found in Rust (naturally models zero-cost abstractions but doesn't have dependent types) and Idris and Coq (have dependent types but don't natur…
Earlier quoted context omitted.
It's not: the TypeScript type system is unsound (accepts code that violates it), and there are no runtime checks, so it doesn't actually guarantee anything: a TypeScript variable may in fact contain any value regardless of its declared type. I'd say the best type systems are found in Rust (naturally models zero-cost abstractions but doesn't have dependent types) and Idris and Coq (have dependent types but don't natur…
TypeScript intentionally strikes a balance between strict soundness and developer productivity, and I've personally been pretty happy with that balance. There's more to language design than soundness, and I've been happy with TypeScript's willingness to get out of my way for little snippets of unsafe code, especially when interfacing with external libraries. Within my own code, I've never had the unsoundness actually…
Earlier quoted context omitted.
Dart came way, way later. And it was a new language, while they could have just used an existing one. They could have implemented lua, ruby, Python, anything with a good track record. With the millions spent on V8 with those geniuses working on it, can you imagine how fast one of those language would have become ? The tooling it would have had ?
Actually, Google tried to make Python faster, with Unladden Swallow project. They failed miserably. And several other projects failed miserably at the same thing as well. Either way, speed was not the main reason they created Dart. Dart was designed for writing large web apps. Dart's top design constraints was good interop with JavaScript meaning transpilation of Dart to decent JavaScript and consumption of existing…
That's actually an interesting claim, and so I would really appreciate if you could provide a (possibly informal) proof that justifies it?
The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…
Does this suggest that all you got to to do is compile the JS to WASM, to have it be just as appealing?