61–70 of 253 posts
Go is making a large push to wasm as well. There is a branch/fork with a near complete wasm Go compiler. I'm interested in seeing how Rust and Go will compare in the future of the web. Who will win? ;)
So all languages will win, with the exception of JavaScript.
If browser vendors keep moving the browser into a general purpose VM, lets see how long JavaScript keeps being the "browser systems language".
As someone who does a lot of firmware I think I really need to explore more of what Rust brings to the table there. Interrupts are a major source of concurrency and I'd like to be fearless about those issues.
Go is making a large push to wasm as well. There is a branch/fork with a near complete wasm Go compiler. I'm interested in seeing how Rust and Go will compare in the future of the web. Who will win? ;)
Let me throw Nim into the mix and say that it has had a JS backend for years now. It's officially supported so it's very stable. Native WASM support isn't there yet, but if you want extra speed you could combine Nim's JS backend and Nim's C backend + emscripten to compile to WASM. You can see this approach in action in a game called Reel Valley [1][2]. The advantage is that you can access the DOM from Nim using the J…
> (you cannot do that in WASM yet AFAIK)
wasm can do anything JS can by calling out to JS. What people mean when they ask for "DOM support in WASM" is to have it be direct, skipping the need for the JS call.
https://crates.io/crates/stdweb is an example of using WASM to manipulate the DOM through JS in Rust today.
I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…
What I hadn't considered: specialized syntax leads to better error messages for the most common cases. That's probably quite a good thing, especially since descriptive error messages make me much more productive. (Not to mention that specialized syntax also acts as a type annotation of sorts too; a common problem I have in Haskell is figuring out _which_ monad a certain `do` block is using.)
As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open about drawbacks of the choices. As well as the use of precise language instead of trying to be too cute and overly beginner friendly.
An example for this is the lengthy page on Strings: https://doc.rust-lang.org/book/second-edition/ch08-02-string...
It really makes me feel you want me to understand what I'm doing from the start instead of getting a generic app out of the door as quick as possible and then tediously figure out the next basic steps from screencasts, scattered blog posts etc.
Also big plus for having the book and api doc available offline by default!
I'm going to try to come by #rustdoc and see if there something I could contribute.
I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…
I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…
This trait of documentation (the "why" & openly discussing pros and cons) seems to be a property of great systems being well-documented.
I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…
I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…
It would be nice to see examples of these new systems hypothetically working together... what does an async DB access within a web request look like with async/await+tokio 0.2?