I've yet to dip my toes into Wasm. This might push me to finally get going. Based on a quick search, Wasmer and Wasmtime appear to be the two most popular runtimes with the latter being backed by some big names (via the Bytecode Alliance). Wasmer seems to push new features first. Can someone share what their experience was like with either or why they chose one over the other?
In my experience Wasmer is generally disliked by the rest of the WASM community. There’s a long list of reasons for this, including attempting to copyright the term WASM and pushing their own proprietary specs and calling them “standards” while not implementing existing standards.
Their main benefit, from what I can tell, is their “retargetable” compiler architecture, but Wasmtime is improving here as well. Wasmtime is also generally faster at implementing standards.
I sometimes assume people have the same context as I do, and your comment made me realize that it was not the case. Here's some context:
https://wasmer.io/posts/wasmer-and-trademarks
Regarding standards, I assume the mention is referring to Wasmer push for WASIX [1]. Which is a specification & implementation that welcomes anyone to participate (even on it's governance model), so I don't think the stance of the previous comment is accurate.
wasmtime is closely aligned with where active development is happening in WebAssembly, WASI, and similar standards. You can expect that as the folks working on WebAssembly itself establish support for (for instance) async, or GC, or components and linking, or other new APIs, wasmtime is where those are going to show up first and be aligned with the rest of the industry. It's easy to embed and reasonably easy to expose your own APIs through, so that you can use it for plugins.
The community is also friendly and inviting for folks trying to get started.
I'm using it for my latest project - writing a cashflow calculator and graphing tool. Really cool to be able to write all the business and graphing logic in Go, then share it with the front end via WASM, so I don't need to implement the same logic in both Go and JS separately.
Things I learned: TinyGo works to get the package size down. Translating values between JS and Go is straightforward (with a lot of boilerplate), but trying to do the JSON dance wasn't worth it - too brittle. Creating SVG in Go and then using it as the innerHTML for a div actually works really well :)
Edit: to be clear, I'm using Go's WASM implementation, not Wasmer
> I have two young kids and I'm constantly humbled by how fearless they are...There's this tremendous power in "not knowing what you don't know" that sometime in university disappeared from me...
"The teenage spirit." There was an interview[1] with one of the founders of Teenage Engineering (makers of the OP-1 synth) that drew from this line of thinking when naming their company:
> They took their name Teenage Engineering from an early prototype that they never launched, but it fits the company and its philosophy well. “The teenage spirit is sometimes about doing things without having any knowledge of how to do them,” he says. “You just do it. That’s often how we go about things. If there’s something we don’t know, say electronics, we learn; we don’t let it stop us. It’s about having more will than knowledge, which is a more rock ’n’ roll way of solving things.”
An interpreter for AMPscript (DSL for personalizing emails) that I used when I was at ExactTarget/Salesforce. I wanted to learn Rust and needed a project-based approach.
It doesn't really have a real-world use case since it's not integrated with any email platform (e.g., Marketing Cloud). I had loads of fun working on it though! Oh, and it's still missing a garbage collector.
Books/tutorials/etc. never really worked for me because they were all "happy path" exercises (read: too boring). Things only started clicking when I had to overcome obstacles while porting projects written in different languages over to Rust.
If you're like me and more interested in language additions, each release entry has a "Language Updates" section (under "Language and Libraries") with example code/usage.
I've spent the last several weeks porting a backend I had written in Go over to Rust (using Axum) and so far so good. But I don't know if I can call things in the Rust world like Axum/Actix/etc. "frameworks" anymore considering all the time I've had to spend researching/vetting crates to get the same functionality that comes out of the box in Spring/ASP.net/Django/etc.
Take handling datetimes for example. Do I use time or chrono? The initial developer/maintainer of chrono left[1] and for the longest time the crate was unmaintained while a CVE remained open[2] until a new maintainer finally came along and addressed it (I think?). All right, so, time it is then... but it uses its own custom format specifiers[3] that I had to get used to coming from the more familiar strftime used by other languages.
Or how about input/form validation. One of the most popular crates for that, validator, had its maintainer admit that they don't even use it themselves?[4] Of course I can already hear people yelling at me, "well, why don't you contribute then?!", and I certainly would love to if I could! But I have to finish what's in front of me first.
That being said, I still very much enjoy using Rust. Maybe less so for web-related projects. I just have to stay on an even keel despite the growing hype.
> But I don't know if I can call things in the Rust world like Axum/Actix/etc. "frameworks" anymore
A "framework" is a thing which calls your code rather than the other way around. You're confusing framework and "full stack" framework.
Actix or Axum are web frameworks in the same sense Flask or Sinatra are web frameworks: they deal with the HTTP lifecycle, and call your code when certain conditions are met (usually around routing).
We're working on this solution. Most housing projects have a semi-permanent dumpster, but GC's often have problems with people dumping in their houses' dumpsters, causing them to pay for more refills on their dumpster, which can get expensive.
Since we record motion on site, we typically catch the illegal dumpers, but it's hard to pick out from the many motion events that may occur on a construction site.
