> what can you expect from a language that uses "+", the quintessential notation for commutative operations, for the (very non-commutative) operation of concatenation?
Is this any worse than using `+` for floating-point addition, which isn't even associative?
Even if it wasn't, floating point numbers are very often regarded as approximations of real numbers, where addition is associative. String concatenation cannot be construed to have any resemblance of commutativity.
So, Envoy will be embedding WebAssembly alongside (or instead of) Lua?
Are other projects moving from Lua (or other embedded scripting languages) to WebAssembly? What are the benefits of compiling an extension to WASM rather than writing it in Lua?
To me the big improvement over Lua won’t be security, or necessarily performance. It’s the ability to target a WASM runtime with your desired language, and it would still be a safe environment.
Be it Rust, C, C++, Typescript, and I bet there will be a Lua interpreter in WASM at some point too.
It will be more flexible, and possibly more performant.
I think the future is still hazy for managed languages, the GC side of Wasm is still in the design phase and it's not clear how widely it will be implemented. And it's been quiet for a long time, is the effor even alive? (https://github.com/WebAssembly/proposals/issues/16)
If it's going to encompass the possibility to hook into the JS side GC engine, this might not be implemented at all in headless Wasm applications, and so you wouldn't be able to use the GC'd languages on those platforms, just C(++)/Rust. Which is not very attractive compared to the easier / safer high level languages most programmers are used to.
You’re right. I should have said AssemblyScript, not TypeScript.
Also, As someone familiar with Rust, it is a very high-level language. It’s zero-overhead features make it a bit of a steep learning curve, but you rarely need to drop to its low-level unsafe features.
That being said, incorporating it into a new WASM environment probably means doing a lot of low-level stuff.
You can use GC languages. One of them is Go. WASM support is pretty good though direct dom access or some well tested wrappers would make it even better.
The obvious benefits (to me) are performance and security.
Performance: Other than the need for trampolines between the host and the wasm code, WebAssembly runs at essentially full speed. Lua is fast for an language built on dynamic types and dynamic dispatch - which is to say, quite slow.
Security: The reference Lua implementation was not designed for untrusted code; there have been various attacks where loading invalid bytecode could grant arbitrary execution. Using a format designed for executing untrusted code has real advantages there.
Isn’t the performance claim a bit of a misconception?
Lua with JIT is very fast even compared to statically typed, compiled languages.
The bottleneck doesn’t seem to be dynamic types or dispatch but rather relying on garbage collection. Another example of this would be Julia.
Admittedly WASM is typically targeted by languages like C and Rust, but I wouldn’t put Lua in the same, general performance category as for example python or most other dynamically typed languages with dynamic dispatch.
The cost of interop in WASM is currently very big as there's no way to pass non-numeric data to the host language without explicit conversion, which is very slow. WASI is trying to address this but as far as I know it's very far from being used by WASM language implementations. Most WASM implementations , by the way, are completely experimental at this point... listing 30 languages as supporting WASM seems highly misleading to me, as someone who has played around with a few languages compiling to WASM. I would say that only C, C++ and Rust have decent support. Even the Go support is currently extremely experimental and limited when compiling to WASM, and that would be the next "best" option. Lack of GC is a huge problem here and the current approach seems to be to allow runtimes to only optionally provide one.
No one is using the Lua reference implementation when performance is required. I haven't used Lua(JIT) for years, but when I did, its performance was approaching C-compiler in some cases. Although a tracing JIT does have its weaknesses as well.
I think all your points are more wrong than right since you pick the weakest possible constructions to attack (reference Lua implementation, invalid bytecode) and seem not to be aware of how good LuaJIT is performance-wise.
I think the first link is missing? But emulators are pretty unrepresentative for this use case and they're often written in low-level & unsafe languages.
The second is about benchmarking C, I suspect it doesn't give us a lot of information in this question either.
What is the state of the art for WASM VM scripting? Adding Lua to a C program requires very little effort. Is the same true of WASM? What is the best “drop in” WASM VM for C programming?
I've recently been working on WASM VM embedding with C (well, via libffi) for a personal project and uncovered a couple of WASM VM options, wasmtime & wasmer:
Not sure if Wasmer is aiming for compatibility with the official WASM C API currently.
From my experience, Wasmtime's C support is probably best described as "under-documented but functioning".
I haven't implemented anything with Wasmer.
My impression is that Wasmer may offer a higher level API than Wasmtime but not sure if it counts as "drop in" yet.
Part of the reason why I ended up going with Wasmtime was...I kinda forgot Wasmer existed. :D But also I do like that they're targeting what will hopefully become a standard API--but I think that results in a lower level API than what is most "friendly" for starting out.
Been meaning to make this embedded Wasmtime C API example--created while figuring things out--public after tidying it up a bit more but... well, I just now made it public, as is (it at least has a ReadMe now :D ): https://gitlab.com/RancidBacon/wasm-embed-test :)
At least among myself and friends, we didn't care about that - we had to decide which system we wanted because our parents would only get one, and went for the bigger name/more familiar games.
(To my and my brothers' initial disappointment, my parents didn't understand why we wanted a PS2 and got us a Dreamcast instead, then refused to get a second game system. One of my brothers still has and plays that Dreamcast.)
But the PS4 never got a UHD Blu-ray player, some think it was an obvious candidate for the 4K pro model. Or perhaps we've gone the other way again and discs are dead, streaming is king.
You have to keep in mind that when the PS2 was released, the DVD was also just released. I remember a stand alone DVD player by itself was ~$200 during the PS2 launch. So part of the argument of it being $299 is that it was a bargain to get it and then not have to buy a DVD player on top of it.
The Xbox required the IR remote controller to play a DVD (So you had to pay $300 plus that price), and the Gamecube could not play a DVD at all (but it was $150 at release).
Isn't code generation during parsing still common today? In particular, bytecode generation in interpreters (and JIT compilers) for scripting languages, e.g. Lua?
It's sometimes a good idea to do it that way in practice, but it's still a conflation of two conceptually distinct processes. I think it is a bad approach when teaching compiler implementation, as it means you avoid the extremely core concept of an abstract syntax tree.
But it isn't a core concept if you do not need it. And an AST builder can be "injected" between the parser and codegen at a later point in time, if needed. You do not even need to do it in one go, e.g. if your compiler has something like a "ParseExpression" (assuming recursive descent parsing that spits out code as it parses), you can start by making a partial AST just for the expressions and leave everything else (e.g. declarations, control structures, assignments - assuming those aren't part of an expression, etc) as-is.
This is useful for both practical and teaching purposes: for practical because it keeps things simple in case the additional complexity isn't needed (e.g. scripting languages) and for teaching purposes because someone learns both ways (which are used in real world problems) while at the same time learning why one might be preferable to the other. And if you do the partial AST bit you even introduce the idea of an AST gradually by building off existing knowledge and experience the student has acquired.
Yes, it is. It also doesn't really make much difference per se, as e.g. Wirth-style compilers still maintain careful separation of the code generation and parsing.
And if you want to/need to later, you can trivially introduce an AST in those compilers by replacing the calls to the code-generator with calls to a tree builder, and then write a visitor-style driver for the code generation.
Yes, it's work of course, but it's quite mechanical work that requires little thought.
Instead of calling the code emitter, you call an AST builder.
Then you build a tree walker that call the code emitter.
At least the Wirth Oberon compiler was retrofitted with an AST by at least one student in Wirth's group as part of experiments with optimization passes.
If all we do is write Pythonic code (especially now that "Pythonic" seems to include type hints), what's the benefit of the highly dynamic CPython virtual machine?
Surely a faster VM, or even an ahead-of-time compiler, would be possible if we give up on some dynamism? Is that a direction the community should take?
(I think Guido's answer would be no, based on his apparent dislike of existing "Python compiler" projects such as Nuitka.)
The Wren scripting language supports this kind of "overloading by arity" [0].
Wren therefore allows overloads such as `range(stop)` and `range(start, stop)`. This is more intuitive than Python's `range(start=0, stop)`, which might be the only function in the language that has an optional parameter before a required one.
That's the thing - it's documented as overloaded, because that's the most intuitive explanation. Wren would allow it to actually be implemented as an overloaded function.
Python doesn't support overloading, and it doesn't support optional arguments before required ones, so the actual implementation in Python is a bit messy - something like:
there is no optional positional in the implementation. range is overloaded in the raw sense of the term as the implementation checks the number of arguments and their types and does the right thing.
it could have been implemented in pure python as well by doing args, *kwargs.
`range(stop)` and `range(1, stop)` are both supported, but without overloading, the implementation of `range` is messy as it has to work out the meaning of each argument manually.
Why is that a problem? I want the standard library to contain all messy stuff so my code doesn't have to.
From the call site there's no difference between Python's optional-first-argument range() function and a hypothetical overloaded one. Any perceived complexity in usage, therefore, can be fixed with better documentation.
Indeed, you said "Distances longer than a few kilometers are measured in miles", which made it sound almost like someone starts a journey in km and then once it gets past say 10km switches to miles.
If you're pointing out the inconsistency of the UK using metric units for i.e. weight and then not for travel distances, I agree, its a bit of a schism.
"Distances longer than a few kilometers are measured in miles" was a direct reference to the OP's "yards to measure distances shorter than a few kilometers".
Exactly. And that's why the UK is especially stupid with units. At least in the US they are consistently idiotic with Fahrenheit and Miles and BTUs and so on. In the UK, they understand what a kilogram is, but measure weight in stones anyway. Fucking stones! And then this thing with yards and miles.
I don't see anything idiotic about Fahrenheit. With distances I can see why powers of ten make a difference, but we don't vary temperatures by orders of magnitude in regular life.
Nor do I spend much time around freezing or boiling water. Fahrenheit has 9/5th more specificity.
Is the point that it's different than the rest of the world? I can see that point, but am I missing anything particularly bad about the Fahrenheit scale?
> Is the point that it's different than the rest of the world? I can see that point, but am I missing anything particularly bad about the Fahrenheit scale?
Mainly that it doesn't make any sense. Why was 32F made the magical number for the freezing point of water? The "well known" temperatures like freezing/boiling points of water are based on observations after the scale was invented. The secrets to the F scale died with Fahrenheit and today nobody knows for sure what 0F actually means.
I wonder if they're keeping fixing this as a backup plan for a rainy day? Say one day UK's GDP goes down harder than they'd like, so in order to burn some money and boost it back without making it look obvious, they'll announce the country has made up its mind, and is switching to full and proper metric starting next year. Cue the economy going to overdrive, as everything and the kitchen sink has to be relabeled or replaced...
(And if that doesn't help for long, they can stimulate the economy further by changing the driving side to the right one.)
It’ll go the other way: the next time they need to leave something, they can have a referendum to leave the metric system, then go through a few governments to get it done.
Actually, I'm Indian, and we have our steering wheel on the right side, just like the Brits. It's one of the less fortunate things we picked up from them.
UK went a little crazy sometime after the American colonies split.
I mean, the US screwed up their fluid ounce / weight ounce so that a US fluid oz of water doesn't quite weight a US oz, but the UK redefined a hundredweight as 112 lbs to make it an even number of stones, and even though they kept their ounces correct, they redefined a pint to 20 ounces so now there's nowhere in the world a pint's a pound.
Good point. The biggest factor that determines an engineer's salary is location, followed by years of experience. Not whether they work on compilers/embedded/web/whatever.
If you are suggestingn that kdb+ salaries are extremely high, like I often read here, I disagree. I did some research in this area, and despite the rumors, found lots of kbd+ jobs posted with very mediocre salaries. It seems unlikely that such jobs would been filled if salaries are as high as people have suggested on HN.
For example, here's a senior kbd+ deb job in Manhattan (high cost of living) that pays 165-185,000/year. I make almost that much as a senior dev in a low cost of living area. I'd expect to make at least $250,000/year in NYC or California.
So would you please give me an idea of what market rate is for a senior dev working with kbd+ in NYC? Roughly? If it's well above 180,000, what is it? Thank you.
And I don't mean quants. I mean software developers.
And yes, it's true that every job category will have outliers (high and low), but after spending some time several years ago looking at jobs and speaking with recruiters, I'm skeptical. I've enjoyed learning about array languages, and had heard the rumors of high kbd+ salaries, which is why I was curious.
And I get that kbd+ is just a technology, and much more depends on individual qualifications. So let's say, an experienced, highly-qualified senior dev who has taught themselves kbd+, just for arguments sake.
Seems to me that MIR operates on a (much) lower level, basically abstract away the physical machine and its finite register set. As such, it would replace LLVM (or GCC) middle and back end. The goal is much faster compilation without sacrificing more than ~20% of performance.
Dynamic types and garbage collection would then be implemented on/for the abstract MIR machine.
It's probably like how V8 works. Even though JS is dynamically typed, V8 will keep internal static type definitions around based on what it sees when running, and trap out internally to the slow path when the types don't match what it thinks should happen rather than throwing type errors.
Is this any worse than using `+` for floating-point addition, which isn't even associative?