A lot of software development seems to take a "if it's runny, it's money" approach where it doesn't matter as long as it works long enough to reach a liquidity event or enough funding to hire someone to review code.
I would very much appreciate the same for RUNE if you feel motivated.
I'm looking now to choose the obsidian plugin that helps me take advantage of the vast amount of notes I have created with obsidian over the last few years.
Front end web development is an ever revolving carousel of pain.
20 years ago I was in the same place as you but with Enterprise Java.
I stuck with simpler environments where my ability to write and test code worked and code bases could be kept simpler.
You can consider switching to “backend” programming, manipulate data and databases with python. Build APIs with Ruby on Rails. Help business automat some software workflows with Autohotkey.
There are a million niches in software, try another.
I took a 3 year break from front-end and when I came back, everything had changed.
Nobody understands React because it doesn't make sense. It breaks all the rules of programming all the time. E.g. calling `useState` multiple times with different (or the same!) arguments and getting different things back. Hooks are an abomination.
tl;dr it's not your fault, everyone in JS is struggling the same way until they eventually memorize the magic incantations. Don't let that stop you.
If you think that revealing the name of a business discloses the vulnerability, then I question whether you are using "vulnerability" in the standard way or that what you have found is a vulnerability as understood by the software community.
Unfortunately many people do this, thinking that a potential bad outcome of a business process is a "vulnerability" - perhaps they are using vulnerability in the non-technical sense, as in "we're vulnerable to supply chain disruptions".
It's also valuable for running code written in <random language> to be executed in <another random language>.
Write a library in Rust and compile it to WASM, theoretically any language with WASM bindings could run it.
This could really make niche languages more easily adopted if their execution environment supported libraries in WASM.
Imagine using Java's JDBC from something like Nim. Nim could take advantage of a 30 year old mature and fast database access framework without haveing to envest that ime and effort themselves.
Or even something more modern like the polars dataframe library.
Firefox uses this approach to create a lightweight, in-process sandbox (called "RLBox") for some third-party libraries. The library is compiled from C/C++ to wasm and then wasm is transpiled back to C++, all at Firefox compile time so no wasm compilation is needed at Firefox run time.
this misses the fact that (unless I'm wrong), WASM by itself can't really do anything like file system/network operations
I know that's not the main usecase of where to put WASM logic that needs to be performant (it's the opposite really)
I just think it's worth calling out that a WASM library really can't do much from what I understand. Like... basic math? You have to supply it (through a WASM runtime) interop to other functions it can call... I think?
I have a hard time taking this seriously, it's the objections of one individual who seems to be seeing ulterior motives behind WASI... I don't think their objections are really as strong as they make out. Big red "In violation" labels are a bit much.
WASI is trying to be a cross language API for use by multiple languages that target WASM. But the author wants this API to more closely follow existing JS conventions? Sure that's useful to JS/Web, but it's not useful for anyone else trying to target WASM with a language that's not JS. And if you want to target Web API's with JS, can't you already just write native JS?
Bikeshedding over string encoding for example and objecting to WASI's promotion of UTF-8 because it doesn't match the encoding used by JS.
Let me ask you this. All nonsense aside about like... standard discussion and what not.
Say I write a Rust program to use `reqwest` to make a HTTP request to some API that is going to return me JSON.
I can compile it to... ELF with Rust I guess on Linux, or I can use Rust to compile it to:
> wasm32-wasi - when using wasmtime this is likely what you'll be using. The WASI target is integrated into the standard library and is intended on producing standalone binaries.
> wasm32-unknown-unknown - this target, like the WASI one, is focused on producing single .wasm binaries. The standard library, however, is largely stubbed out since the "unknown" part of the target means libstd can't assume anything. This means that while binaries will likely work in wasmtime, common conveniences like println! or panic! won't work.
> wasm32-unknown-emscripten - this target is intended to work in a web browser and produces a .wasm file coupled with a *.js file, and it is not compatible with wasmtime.
Say the Tokio async runtime works for wasm32-wasi (I don't think it does currently, I could be wrong) and reqwest + all of its network dependencies compile to wasm32-wasi (not sure if they do, I think there is progress) and say lite-json or some kind of JSON de-serizaliation works
Why would I compile + run as wasm32-wasi instead of stable-x86_64-unknown-linux-gnu?
It's my understanding that WASI is using Unix-like abstractions, because they also target native execution, while the AssemblyScript would prefer web-like abstractions, because they exclusively target the browser. From your second link at least, this seems like the main technical complaint:
> Languages that would naturally fit the Web platform not only are overlooked, but WASI's self-imposed abstinence of Web concepts undermines other languages' interoperability potential with JS and the Web platform specifically.
The problem is that objectively, the web platform is garbage. Half-baked, weirdly incomplete abstractions, most of can only be rationally explained as either historical accidents or the aftermath of political fights on standards committees. Why would anyone base a new abstraction around those if they don't strictly have to?
After looking at the objections from these guys, they seem to boil down to, "but it makes non-web development more viable again, and that's bad for the web". The first part is true. The second part is arguable, but IMO if it is true, then balance needs to be restored.
More like dcodeIO and his AssemblyScript ambitions are considered harmful to us not having to live with the legacy hacks. The sad part is that it seems they have won, and the standard will be uglified on the fundamental level: https://github.com/WebAssembly/stringref/blob/main/proposals... Now the time came for WASI to submit, hence the "fatwa".
> Imagine using Java's JDBC from something like Nim.
You can already do this with JNI. How does WASM improve things? In both cases (WASM or native code) you get the overhead of two runtimes and the hassle of converting data types, don't you?
WASM is executable from every language to every language, you wouldn't have to write code specifically targeting the JNI for example. Say you want to use a PDF library from Java, a web server from C# and some scripts someone wrote in Python, and for whatever reason your preferred language of the day is Haskell. In the normal case you'd have to rely on someone to maintain Java -> Haskell, C# -> Haskell and Python -> Haskell glue code. But with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three.
It's often the case that people choose languages based on the availability of the libraries written in those languages. The goal of non-browser WASM is to get rid of that and to minimize the friction of inter-language communication, so you don't have to rewrite it in $language. WASM is not tied to any language (like the JNI).
> But with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three.
A bit of a rant, but there's nothing specific to WebAssembly about this.
Whether you're using WebAssembly or native code:
- The basic interface you get between caller and callee is a low-level calling convention, where essentially all you have are integers (which can be pointers), and any higher-level data structures need to be built out of that.
- A slightly higher-level interface is the C ABI; many languages support exporting and consuming APIs using the C ABI, but it can be frustratingly low-level.
- To provide an even higher-level interface, there are bindings generators, which could in principle either be designed as direct language-to-language bridges, or as a single common standard that any language can provide and consume APIs for.
The WebAssembly Component Model standard and the wit-bindgen tool are an example of the latter. They happen to be defined specifically for WebAssembly rather than generically for any architecture. If they become ubiquitous at some point in the future like they're supposed to, then WebAssembly will have an advantage when it comes to high-level bindings, not because of any fundamental technical aspect of WebAssembly itself, but just because people building these bindings on top of WebAssembly have more motivation and more consensus. (WebAssembly does have a technical advantage when it comes to sandboxing between components, but this is relatively unimportant for most use cases.)
But for now, wit-bindgen isn't ubiquitous, and most of those languages don't even work in WebAssembly yet…
I work on wit-bindgen. One major advantage of the WebAssembly VM is that we can trust the call stack, which gives cross-language calls optimization opportunities to skip serializarion or copies. This will be an even more important when we add async to the component model, and e.g. async rust can await on async typescript, all in the same “executor” in Rust terms.
Sandboxing also goes a long way towards containing the supply chain security issues that every language is susceptible to.
What do you mean by ‘trust the call stack’? Do you mean trusting that a function you call won’t longjmp out or otherwise break out of the call without returning? (Plenty of native code already assumes that functions it calls won’t do that.) Or something else?
Wasm doesn’t yet have any sort of longjmp instructions. Stack switching is currently a proposal and the leading candidate is based on delimited continuations. Additionally, there are no wasm instructions that can manipulate the control stack besides call, indirect call, and return, which are always typechecked. So, if you call untrusted code, you can be assured that it will not be able to manipulate your stack and that it will either return or trap.
Native code might assume that code it calls won’t misbehave in these ways, but wasm guarantees it, and that allows wasm VMs which run untrusted code to have more efficient implementations.
you wouldn't have to write code specifically targeting the JNI for example
Why not? You still need operations like "create object", "look up method", "invoke method", "convert type between languages" etc. WASM doesn't have any kind of polyglot layer that does this automatically.
Ironically, Graal/Truffle actually do. There's a whole infrastructure where languages can expose their structures, functions, objects etc via a language-neutral in-process protocol and the compiler understands how to optimize across the transitions, so you can actually load JavaScript into Python and do those sorts of things:
The API you use to import code from other languages is standardized, so it doesn't matter what language the other side is using. But WASM doesn't do anything like that.
"with wasm, you just pull in csharp.wasm, python.wasm and java.wasm, so it's just one binding layer, not three"
Are these real files/projects you're talking about here? If so, can you show us these things? Because WASM seems far too low level to define a Truffle-like polyglot layer let alone make it fast.
In the short term, you wouldn't want to run databases in WASM. You could, but it's not really worth the effort, as long as the WASM runtime allows TCP connections, you can just connect to any hosted DB as usual.
For performance, we ship three compiler backends: LLVM (fast execution, but slowest compilation), cranelift and singlepass (our own compiler, very fast compilation and you can compile untrusted code - but slowest execution). There is a slowdown, but the goal is to keep that at a minimum (proper performance tracking is on the bucket list). We are pre-compiling the python.wasm (which was already pre-optimized when the compilation to WASM happened) with LLVM, so you should get assembly that is very close to the native execution, with the exception of the necessary VM overhead. The goal is to make it so that the interoperability gains are worth the performance hit.
Sure, maybe it's not as fast to execute as another implementation, but having ANY implementation is far more useful than none at all.
Here's an example where performance wouldn't matter as much:
Let's say I'm the author of a programming language and I want to add a db layer to my standard lib.
Via WASM I can use a working backend while I'm protyping the API for my db layer. If the performance isn't fast enough I can start implementing my own "native" version with feature parity.
I can then use some of the tests from the original library (via WASM) to make sure my implementation has feature parity to the original.
Even if the feature set were limited to what’s possible with Java/JNI, the fact that Oracle does not own any piece of it is a feature in its own right.
GraalVM’s polyglot execution does solve this problem, it can even optimize across language barriers. (But it runs native languages as LLVM “bitcode” basically, not natively)
GraalVM will Not succeed, because every language needs Tour be reimplemented in graal, in wasm every language just needs a wasm Target.
Also Java is really slow Boy adding a wasm Target. Most languages have a way to run on a wasm engine.
It's not useless, it's just a lower layer in the stack. Decoupling high-level managed runtimes from underlying low-level bytecode makes a lot of sense. Delivery is another question, and we'll probably solve that by caching common runtimes.
