CryZe

11 ms·

91.
by CryZe 6y ago
Works in VSCode too, not sure what specifically their problem is.
92.
by CryZe 6y ago
I'd argue that for the most part Rust is not really gaining more features. Instead rough edges are being polished. GATs for example sound like a fancy feature, but in reality, it just allows you to make your associated types generic, j
93.
by CryZe 6y ago
And you can assign a hotkey to open the docs in the browser for the symbol under the cursor.
94.
by CryZe 6y ago
It's not your addon entirely. All the text has white underlines, you usually just don't see it on the white background.
95.
by CryZe 6y ago
That does not seem true at all. The only two things that slow you down is: 1. The compile times. But those are comparable to C++. 2. The borrow checker and ownership rules. But you get used to those rules and eventually they are ingrained f
96.
by CryZe 6y ago
That's auto generated and will shrink more and more in the future as WASM gets more abilities to directly call into DOM APIs and store JS objects.
97.
by CryZe 6y ago
Rust compiled to WASM is still vastly faster than JS (often even by about 10 times or more). But yeah you probably should be fixing your JS at that point if it matters that much.
98.
by CryZe 6y ago
On algorithmic code, idiomatic Rust + WASM is often about 10 to 40 times faster than idiomatic JS. The problem however is that each call between WASM and JS has a hefty cost of about 750ns. So your algorithm needs to be doing a significant
99.
by CryZe 6y ago
Chrome has this as well. However it's kinda hidden (in that you need to trigger it from JavaScript / need an extension to trigger it for you).
100.
by CryZe 6y ago
Well it seems like the clock example they have can't even hit 60 FPS without consuming 100% cpu (of one core). So yeah you probably don't want to actually use Python in the browser (via a JS interpreter).
101.
by CryZe 6y ago
It seems like it's about 40 times slower than JS or so, if not more.
102.
by CryZe 7y ago
Actually even for wasm you can make `cargo run` work. You just need to write a script for it and use it as the target runner. Especially for WASI this is great where you can just specify wasmtime as the runner and then cargo test / ben
103.
by CryZe 7y ago
At least in VS Code it's formatted nicely (at least most of the time, there are some ugly edge cases). Might depend on your editor integration though.
104.
by CryZe 7y ago
In addition to what the others said there's another point: async fn's implement Future, otherwise you wouldn't be able to use them. So it's essential for Future to be in the standard library so that async fn can work.
105.
by CryZe 7y ago
Unless I'm wrong, this is NLL, not two phase borrows (which may contain two phase borrows). But considering two phase borrows are still a problem for the memory model, they might actually somewhat unstabilize them to a certain degree a
106.
by CryZe 7y ago
And Futures are about to be stabilized any moment now (and with that I mean within a few hours probably).
107.
by CryZe 8y ago
Not when you have a proper IDE setup where building + running it in debugging session are all done with a single action. I've done print debugging for a long time, and here and there it still makes sense, but I've found that it&#x
108.
by CryZe 8y ago
I think what's unexpected is that (0..10).map(|x| x * x) doesn't implement Copy. I think that's something that could be implemented as Copy closures are a thing now (or maybe soon). Although wait, the problem is more that (0.
109.
by CryZe 8y ago
The point is rather that Rust has a bunch of methods on integer for dealing with overflows in a variety of ways, like saturating, wrapping or returning an Option with a None value on overflow (there's also one that returns a tuple with
110.
by CryZe 9y ago
I compiled a GB emulator written in WASM to Rust yesterday and benchmarked it. The Rust one was about 7 times faster.
111.
by CryZe 9y ago
You are not forced to use C or C++. Rust has automatic memory management via its Ownership System. Once you get used to it, it feels a lot like a garbage collected language.
112.
by CryZe 9y ago
Without finalizers in JavaScript, WASM Libraries don't work out well, as you need to do manual memory management in your JavaScript code then, as you won't be able to hook the native destructors into the Garbage Collector of JavaS
113.
by CryZe 9y ago
This isn't just because of 2 GC's working side by side. This happens to any memory that isn't a JavaScript object. So every asm.js and WebAssembly library is affected by the same issue, even if it doesn't have its own ga
114.
by CryZe 10y ago
I've written all my Advent of Code 2016 puzzles in Rust that I've then compiled to asm.js and WebAssembly and both asm.js and WebAssembly always outperformed the idiomatic JavaScript solutions by a factor of 10x and sometimes even
115.
by CryZe 10y ago
I'm not 100% sure if I tried it in any of my apps, but I think I did, and can't recall it not working. I'll try again soon and will tell you if it works.
116.
by CryZe 10y ago
There doesn't seem to be anything unstable about it, even now. I've compiled tons of Rust code to asm.js over the last few months and there's not a single thing that didn't work. Modifying the DOM also works fairly well
117.
by CryZe 10y ago
Depending on the cargo version, wasm might not actually work in 1.14 (couldn't check which version it uses yet). It's definitely broken in the next release, which is quite unfortunate :/
118.
by CryZe 10y ago
I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were de
119.
by CryZe 10y ago
Nah, I'm talking about running an algorithm.
120.
by CryZe 10y ago
It absolutely will. I've compiled like 30 projects to the web now and across the board I'm seeing 10x to 40x improvements in speed compared to idiomatic JavaScript. Here's one of the Benchmarks I ran: Native: 57.26 ms wasm Fi

More ›