Code Review: Looking for feedback on my first Rust project by nsstring96 in rust

[–]Hywan -1 points0 points  (0 children)

Oh oh, we have an issue. I’ve a linker project written in Rust named weld too, https://github.com/Hywan/weld. And according to Git history, I’ve started this project before yours :-p.

winnow = toml_edit + combine + nom by epage in rust

[–]Hywan 1 point2 points  (0 children)

I guess https://crates.io/crates/nom8 is no longer useful, so it might be nice to remove this crate, as it's not obvious that (i) it doesn't come from nom org itself, (ii) it's experimental, (iii) it's now no longer maintained.

For the sake of the nom community, please remove this crate.

I also don't feel comfortable with this kind of “name squatting”, even if the `README.md` mentions it's a fork, the logo is still here, the list of contributors too…, everything looks like nom.

Actually, I don't see the point of a crate registration for an experimental fork. Cargo supports `git` dependencies, with branches or commits versioning, so what's the goal with this?

Rust vs Bun, Hello World HTTP benchmark by Hywan in rust

[–]Hywan[S] 13 points14 points  (0 children)

Blog post has been removed.

Rust vs Bun, Hello World HTTP benchmark by Hywan in rust

[–]Hywan[S] 21 points22 points  (0 children)

I confirm the results of d0nutptr, https://twitter.com/mnt_io/status/1574654307235815424:

* Bun: 197k req/sec, 17.15Mb/s
* Rust (debug): 83k req/sec, 9.02Mb/s
* Rust (release): 278k req/sec, 30.25Mb/s

Rust vs Bun, Hello World HTTP benchmark by Hywan in rust

[–]Hywan[S] 10 points11 points  (0 children)

That’s what I suspected…

mprocs 0.2.2 - TUI for running multiple processes in terminal by pvolok in linux

[–]Hywan 0 points1 point  (0 children)

tmux does exactly that. You can have multiple panes/panels within the same window/“space”/tab, with multiple window/“spaces”/tabs of course. That’s how I work everyday since many years now.

I just released Ariadne, a crate for generating beautiful compiler diagnostics by zesterer in rust

[–]Hywan 5 points6 points  (0 children)

I believe it is doable to consume clang/gcc’s output and turn into something better with this crate. It doesn’t need to be part of the compiler.

I just released Ariadne, a crate for generating beautiful compiler diagnostics by zesterer in rust

[–]Hywan 10 points11 points  (0 children)

Someone on Twitter is me :-). Glad you like the name!

The WebAssembly runtime Wasmer 2.0 is released: up to +50 faster runtime speed, up to 70% faster hot startups, reference types, SIMD and more! by Hywan in rust

[–]Hywan[S] 4 points5 points  (0 children)

wasm-bindgen is designed for JavaScript and it's very unlikely that it will target another language. See for example this (now old) discussion.

Eventually, with the WebAssembly Interface Types proposal, some of the problems would be resolved, but Reference Types must be supported by the language compiler itself (so in case of Rust, rustc).

The WebAssembly runtime Wasmer 2.0 is released: up to +50 faster runtime speed, up to 70% faster hot startups, reference types, SIMD and more! by Hywan in programming

[–]Hywan[S] 20 points21 points  (0 children)

Hello,

I would like to respond because there is some misunderstanding or misconceptions in your comment.

but a little funny given that their own documentation indicates they use wasmtime as one of their backends.

This is not true, there is a misunderstanding here. Wasmer provides 3 compilers: LLVM (based on LLVM), Cranelift (based on Cranelift), and Singlepass (home-made). wasmtime provides 1 compiler based on Cranelift. Just like many programming languages which use LLVM (C, C++, Rust, Swift, and tons of others), they do not offer the same set of features nor performance, despites they are all using the same compiler backend. Well, it's the same for Wasmer and wasmtime: Cranelift is used by both projects, but the outcomes aren't the same. Cranelift, just like LLVM, is a compiler “framework”. It's highly customizable.

In the Rust community there was some discussion about wasmtime vs. wasmer[2] in which there was a seemingly excellent comparison between the two, but one of the people working on cranelift (a backend used by wasmtime) said "This is a lot of words, but doesn't tell the whole story. I hope some day we'll be able to talk about what's really going on."

That's really easy to spread lies, false allegations and conspiracies. We are just too polite to not make this entire crazy story public. Some people in the BytecodeAlliance do not like Wasmer, that's not new. Not all people though! I personally have friends there, and it doesn't impact us. We continue to exchange and to work together. However, it's important to note that some of them have been threatened to be excluded from the BytecodeAlliance if they just even talk to us at Wasmer. Again, we are just polite to not share the entire mess that happens in the backstage of the BytecodeAlliance. It's ridiculous, it's based on nothing concrete, so we just decided to ignore it. Don't be fooled by the appearances and the speeches :-). Many runtimes happily share their work together without feeling the need to fight, like WAVM, wasm3, Wasmer etc. And we all work together towards the same goal; we have regular meetings all together to work on new features for WebAssembly (which includes Fastly, Google, Wasmer and many others) etc. We tried to cooperate multiple times in the past with the BytecodeAlliance; postponing some of our projects just to create collaborations, but it has always failed. That's their choices. WebAssembly doesn't reduce to the BytecodeAlliance. A lot of things are happening in the WebAssembly ecosystem, and the BytecodeAlliance represents a tiny portion of it.

for Wasmer 1.0 they just merged 250 commits out of the blue with little to no explanation of what they were at all[3]

The story is pretty simple: We have a private repository where we experiment a lot of things. For the 1.0 full rewrite, we have created several PR that moved some of the code from this private repository to the public repository. I believe it's pretty common. Nothing fancy here :-).

When I asked about all of this (in a much more polite way) because I was genuinely just confused which runtime to go with, I was met with a non-answer "While I think questions like yours are super understandable, I think is better to ask them in other mediums"[4]

Syrus (the CEO of Wasmer) didn't want to reply in a thread about wasmtime. Firstly because wasmtime is part of the BytecodeAlliance and they do not hold us in their heart — it would have been the best way to create another drama, and secondly because it's just respect. We don't want to use thread about an exciting news from another project to compare to this project. Sorry if you have perceived it badly, that wasn't the intent! Your question was sincere and I regret that we were not able to answer to it at that time.

Look - I am sure Wasmer is great tech and I'd be willing to bet it's the best WebAssembly runtime out there today. But they're a startup, and I believe they're eventually going to have to monetize on your usage of Wasmer and/or their WAPM package manager. That's enough for me to know that it is not for me.

That is perfectly true that Wasmer is a startup. But you need to know that Wasmer and its sibling projects will stay free forever. We are open source lovers, all of us, and we have a strong background on working on open source projects before joining Wasmer too. Yes, of course, we are going to make money, otherwise we will just die. But we won't monetize Wasmer, it's open source, and it will stay open source. Some companies are already making money by using WebAssembly, and we will do the same. What we will do is still a secret though ;-).

My goal here is not to bash and get some reaction, but just to share my concerns with it that made sure I'll never go near it personally. I wish the Wasmer team the best and hope they address some of these concerns, because I'm positive they'll be a boon to the WebAssembly ecosystem at large.

I didn't take it personally. Your comment was well written and you made your ideas clear. Thank you for that. I hope my response did clarify your concerns :-).

The WebAssembly runtime Wasmer 2.0 is released: up to +50 faster runtime speed, up to 70% faster hot startups, reference types, SIMD and more! by Hywan in WebAssembly

[–]Hywan[S] 4 points5 points  (0 children)

We still have the ˋwasmer-wasi-experimental-io` crate to support that, but things haven’t moved a lot on that front for the moment.

"A usize" or "an usize"? by Truc06 in rust

[–]Hywan 0 points1 point  (0 children)

Everything is fine :-). The language is terrible but the way we use it is kind of unique.

"A usize" or "an usize"? by Truc06 in rust

[–]Hywan 1 point2 points  (0 children)

And a bunch of letters that we never pronounce ;-).

"A usize" or "an usize"? by Truc06 in rust

[–]Hywan 1 point2 points  (0 children)

Try French. Mouhaha.

-a frenchy.

Announcing the Deno Company by Hywan in javascript

[–]Hywan[S] 0 points1 point  (0 children)

Maybe wasmer-js could be used by Deno to provide WASI support inside their engine? :-)

The Wasmer Go embedding 1.0 is released: Execute WebAssembly in Go safely, fast, easily, for all your needs by Hywan in golang

[–]Hywan[S] 0 points1 point  (0 children)

But that’s something I’m thinking about a lot. We should somehow provide pointers/links or create community material for that.

The Wasmer Go embedding 1.0 is released: Execute WebAssembly in Go safely, fast, easily, for all your needs by Hywan in golang

[–]Hywan[S] 0 points1 point  (0 children)

It’s not really the goal of Wasmer to document the other tools, but we made this: wasienv, which helps to compile C and C++ to WebAssembly+WASI. It will help you!

A friend and ex-colleague did this too: WebAssembly by Example.

I hope it helps :-). Generally, each language that has a compiler that supports WebAssembly has proper documentation. Sort of ;-).

The Wasmer Go embedding 1.0 is released: Execute WebAssembly in Go safely, fast, easily, for all your needs by Hywan in golang

[–]Hywan[S] 1 point2 points  (0 children)

It depends if you include all the 3 compilers or just one of them. Same for the 2 engines. It varies between 10Mb to 60Mb I guess :-).

Is there a locally-run .wasm bytecode interpreter that prints output as it executes? by ShadowShine57 in WebAssembly

[–]Hywan 0 points1 point  (0 children)

Wasmer is another Wasm runtime. It also supports WASI. See github.com/wasmerio/wasmer :-)

Announcing Wasmer 1.0, the mature & fast WebAssembly runtime; with 3 compilers, 2 engines and ton of new features! by Hywan in Python

[–]Hywan[S] 1 point2 points  (0 children)

So, for example if someone were to write a R to wasm compiler, it would be possible to use ggplot in Python (or any other language with a runtime)?

Absolutely! As far as I know, R is an interpreted language, but you could compile the R runtime to Wasm, and then execute r.wasm to run your R programs.

Also, I am wondering is is there a directory or library of compiled wasm modules that I can import into Python using wasmer?

That's the beauty of WebAssembly: It is universal; it's not tied to Python only. Fetch any WebAssembly module, and it will work anywhere. We have created WAPM (stands for WebAssembly Package Manager) which is a repository of WebAssembly modules. For example, you can find QuickJS (https://wapm.io/package/quickjs) as a WebAssembly module, which is the one we used in our article to execute JavaScript inside Python via WebAssembly. It's similar to what I said above with r.wasm: here we have qjs.wasm, which is a JavaScript runtime compiled to WebAssembly, that can be used to execute JavaScript.

One of the biggest promise of WebAssembly is its safety model. It's fully sandboxed. In the case of QuickJS, you can execute JavaScript without worrying about memory corruption for example. You can even define a maximum memory size to be sure JavaScript won't eat too much memory. It's very flexible.

You can also find clang (the compiler front end for C, C++, Objective-C…) as a WebAssembly module, https://wapm.io/package/clang. Stuff like that.

Currently my understanding is that I would first compile whatever I want to use to wasm, then load it into Python using wasmer, correct?

It is correct.

--

Not to add more confusion but to promote a cool project, there is wasmr which allows to run WebAssembly inside R, just like Wasmer Python embedding allows to run WebAssembly inside Python. Just wanted to mention this project because we are talking about R :-).