4 ms·

> This is powerful because you [can] use Rust or C++ as your scripting language. Do people really want to use such complex, heavyweight languages for scripting

by pansa2 6y ago

> This is powerful because you [can] use Rust or C++ as your scripting language. Do people really want to use such complex, heavyweight languages for scripting? > WebAssembly enables predictable and stable performance because it doesn’t require garbage collection like the usual options (LUA/JavaScript). Do garbage collection pauses cause significant issues when embedding Lua or JavaScript? If so, I would expect implementations of those languages to switch to reference counting, but none of them are doing so. > Extremely fast programs in environments where you can’t JIT for reasons. To get good performance, don't WebAssembly implementations need to use JIT-compilation internally?

geofft 6y ago
As I understand it: > Do people really want to use such complex, heavyweight languages for scripting? The way I'm reading this, "scripting" should be taken to mean "embedding." Sometimes you do want to run significant amounts of code in a context where traditionally you'd want an embeddable language like Lua or JavaScript, but the fact that such languages are built for scripting (i.e., more optimized for connecting other high-performance components together in a flexible way than for being a high-performance component itself) becomes a limitation. Some historical examples of where people have wanted complex languages in embedding contexts where scripting languages would have been an easy choice: Google Web Toolkit (write webapps in Java compiled to JS), ActiveX, eBPF, the very idea of loadable native-code modules itself. All of those approaches to the problem have their downsides. > Do garbage collection pauses cause significant issues when embedding Lua or JavaScript? Yes, https://www.google.com/search?q=javascript+gc+pause https://www.google.com/search?q=javascript+gc+pause > If so, I would expect implementations of those languages to switch to reference counting Reference counting and tracing garbage collection are duals of each other (Bacon et al. 2004, "A Unified Theory of Garbage Collection," which is a great read). You're going to do the same amount of work in both cases if you manage to clean up the same garbage (i.e., if you deal with cycles), it's just a matter of when/how you do it. Technically, yes, reference counting gets you predictable performance (unless you solve the cycle problem with a backup tracing GC), but it may not have the characteristics you want. Knowing in advance that you're going to decref a bunch at an inconvenient time doesn't really help the underlying problem of GC pauses. :) > To get good performance, don't WebAssembly implementations need to use JIT-compilation internally? I think only if you are running wasm that changes dynamically / independently of the application, which on at least one "for reasons" platform (iOS) you can't do anyway. If you're willing to ship the wasm with your application, you can AOT-compile it.
Skinney 6y ago
> To get good performance, don't WebAssembly implementations need to use JIT-compilation internally? No. JITs are great when you're executing code which is very dynamic in nature (either because of dynamic types, or because you're using a lot of interfaces) because the JIT can make use of speculative optimizations based on runtime information. WASM, however, doesn't really support the notion of compound types and the few types that are supported (int32, int64, float32 and float64) is required to be specified up front. WASM doesn't really have the notion of of ad-hoc polymorphism either. In other words, there's very little for a JIT to speculate about, and so there aren't much insight a JIT can get from having runtime information available. This might change as newer features are added to WASM in the future.
danShumway 6y ago
> Do people really want to use such complex, heavyweight languages for scripting? This is a surprising reaction to me, given the history of Javascript and NodeJS in general, but you're not the only person I've seen bring this up. Ask yourself, 'do people want to use such a strange, high-level language as Javascript for programming servers?' Of course they do, because the primary factor in choosing a language isn't whether or not it's perfectly suited for a specific task, it's how familiar you are with it and how much tooling you already have built up and available around it. Being able to program your back-end and front-end in the same language is a massive productivity win. It allows you to do all kinds of cool things with architecture and code reuse, and most importantly you don't need to switch mental contexts as often while you're programming. So if it was reasonable for JS devs to bring their scripting language to the server, it is just as reasonable for Rust/C++ devs to want to bring their server language to the browser. It's not about the language semantics; if someone is primarily familiar with Rust then they'll be faster building web apps in Rust than they would be in Javascript.

by pansa2 6y ago

geofft 6y ago

As I understand it: > Do people really want to use such complex, heavyweight languages for scripting? The way I'm reading this, "scripting" should be taken to mean "embedding." Sometimes you do want to run significant amounts of code in a context where traditionally you'd want an embeddable language like Lua or JavaScript, but the fact that such languages are built for scripting (i.e., more optimized for connecting other high-performance components together in a flexible way than for being a high-performance component itself) becomes a limitation. Some historical examples of where people have wanted complex languages in embedding contexts where scripting languages would have been an easy choice: Google Web Toolkit (write webapps in Java compiled to JS), ActiveX, eBPF, the very idea of loadable native-code modules itself. All of those approaches to the problem have their downsides. > Do garbage collection pauses cause significant issues when embedding Lua or JavaScript? Yes, https://www.google.com/search?q=javascript+gc+pause https://www.google.com/search?q=javascript+gc+pause > If so, I would expect implementations of those languages to switch to reference counting Reference counting and tracing garbage collection are duals of each other (Bacon et al. 2004, "A Unified Theory of Garbage Collection," which is a great read). You're going to do the same amount of work in both cases if you manage to clean up the same garbage (i.e., if you deal with cycles), it's just a matter of when/how you do it. Technically, yes, reference counting gets you predictable performance (unless you solve the cycle problem with a backup tracing GC), but it may not have the characteristics you want. Knowing in advance that you're going to decref a bunch at an inconvenient time doesn't really help the underlying problem of GC pauses. :) > To get good performance, don't WebAssembly implementations need to use JIT-compilation internally? I think only if you are running wasm that changes dynamically / independently of the application, which on at least one "for reasons" platform (iOS) you can't do anyway. If you're willing to ship the wasm with your application, you can AOT-compile it.

Skinney 6y ago

> To get good performance, don't WebAssembly implementations need to use JIT-compilation internally? No. JITs are great when you're executing code which is very dynamic in nature (either because of dynamic types, or because you're using a lot of interfaces) because the JIT can make use of speculative optimizations based on runtime information. WASM, however, doesn't really support the notion of compound types and the few types that are supported (int32, int64, float32 and float64) is required to be specified up front. WASM doesn't really have the notion of of ad-hoc polymorphism either. In other words, there's very little for a JIT to speculate about, and so there aren't much insight a JIT can get from having runtime information available. This might change as newer features are added to WASM in the future.

danShumway 6y ago

> Do people really want to use such complex, heavyweight languages for scripting? This is a surprising reaction to me, given the history of Javascript and NodeJS in general, but you're not the only person I've seen bring this up. Ask yourself, 'do people want to use such a strange, high-level language as Javascript for programming servers?' Of course they do, because the primary factor in choosing a language isn't whether or not it's perfectly suited for a specific task, it's how familiar you are with it and how much tooling you already have built up and available around it. Being able to program your back-end and front-end in the same language is a massive productivity win. It allows you to do all kinds of cool things with architecture and code reuse, and most importantly you don't need to switch mental contexts as often while you're programming. So if it was reasonable for JS devs to bring their scripting language to the server, it is just as reasonable for Rust/C++ devs to want to bring their server language to the browser. It's not about the language semantics; if someone is primarily familiar with Rust then they'll be faster building web apps in Rust than they would be in Javascript.