Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oxidizing Source Maps with Rust and WebAssembly

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Oxidizing Source Maps with Rust and WebAssembly

#21

Post by jlebrech »

carlmr wrote: post #18
seba_dos1 wrote: post #10

Earlier quoted context omitted.

I would guess that a language in where the compiler holds your hand so you don't shoot yourself in the foot is probably by definition a bit easier than one that hides traps for you behind corner every now and then :)

While I generally agree with that sentiment, Rust's compiler is so hard to please that a lot of C/C++ developers find it hard to do it. I think for a beginner it's even harder. C is so small a language that you can learn it much quicker. The problems surface later on.

I guess even the most legible but slow C code is faster than the same code for javascript with all the speed tricks.

Re: Oxidizing Source Maps with Rust and WebAssembly

#22

Post by carlmr »

neikos wrote: post #19
carlmr wrote: post #18

Earlier quoted context omitted.

While I generally agree with that sentiment, Rust's compiler is so hard to please that a lot of C/C++ developers find it hard to do it. I think for a beginner it's even harder. C is so small a language that you can learn it much quicker. The problems surface later on.

What do you mean by 'hard to please'? The joke about the compiler being some beast you need to sacrifice a goat to seems to put the blame on the wrong end of the computer imo. Unless what you are doing is not fit for what guarantees Rust gives you, the compiler should just be a crutch in case you missed a step.

I thought the same until I actually tried Rust. The compiler will complain in a some places which are ok if you know what's happening. It was probably easier to implement the borrow checker that way. At the same time a lot of the error messages are very cryptic if you haven't seen them before. It is in that sense hard to please. A lot of this might become better with coming iterations though.

Re: Oxidizing Source Maps with Rust and WebAssembly

#23

Post by carlmr »

Tade0 wrote: post #20
carlmr wrote: post #18

Earlier quoted context omitted.

While I generally agree with that sentiment, Rust's compiler is so hard to please that a lot of C/C++ developers find it hard to do it. I think for a beginner it's even harder. C is so small a language that you can learn it much quicker. The problems surface later on.

> While I generally agree with that sentiment, Rust's compiler is so hard to please that a lot of C/C++ developers find it hard to do it. I think for a beginner it's even harder. I think it's hard for those who carry "mindset-baggage" from C/C++. My first attempt at Rust was a failure mostly because I thought it was sort of a "weird C/C++".

Mindset baggage is a valid criticism. However I think Rust is a lot noisier and less obvious about many things which you have to get accustomed to. It's a very different mindset baggage in Rust.

Re: Oxidizing Source Maps with Rust and WebAssembly

#24

Post by steveklabnik »

carlmr wrote: post #22
neikos wrote: post #19

Earlier quoted context omitted.

What do you mean by 'hard to please'? The joke about the compiler being some beast you need to sacrifice a goat to seems to put the blame on the wrong end of the computer imo. Unless what you are doing is not fit for what guarantees Rust gives you, the compiler should just be a crutch in case you missed a step.

I thought the same until I actually tried Rust. The compiler will complain in a some places which are ok if you know what's happening. It was probably easier to implement the borrow checker that way. At the same time a lot of the error messages are very cryptic if you haven't seen them before. It is in that sense hard to please. A lot of this might become better with coming iterations though.

Now, this is true in many senses, as it's inherently how static analysis works, but I've also had many experiences where someone joins one of our IRC channels, shows some code and says "hey the borrow checker won't let me do this thing that's totally safe" and then I or someone else replies "well, what about this?" to which the answer is "...... oh. yeah." This is virtually almost always from C++ programmers.

It's hard to escape the mindset of languages we're used to!

> At the same time a lot of the error messages are very cryptic

You should file bugs! We care deeply about the legibility of error messages, and the whole --explain system is there to try and go above and beyond.

Re: Oxidizing Source Maps with Rust and WebAssembly

#25

Post by steveklabnik »

js2 wrote: post #15

FYI, the Sentry folks have also written a Rust-based sourcemap decoder: https://github.com/getsentry/rust-sourcemap

The authors of it and the authors of this were talking on Twitter; the one in the article is pretty specialized, so that's why they didn't use this. They recommend Sentry's library for every non-wasm use case, basically.

Re: Oxidizing Source Maps with Rust and WebAssembly

#26

Post by carlmr »

steveklabnik wrote: post #24
carlmr wrote: post #22

Earlier quoted context omitted.

I thought the same until I actually tried Rust. The compiler will complain in a some places which are ok if you know what's happening. It was probably easier to implement the borrow checker that way. At the same time a lot of the error messages are very cryptic if you haven't seen them before. It is in that sense hard to please. A lot of this might become better with coming iterations though.

Now, this is true in many senses, as it's inherently how static analysis works, but I've also had many experiences where someone joins one of our IRC channels, shows some code and says "hey the borrow checker won't let me do this thing that's totally safe" and then I or someone else replies "well, what about this?" to which the answer is "...... oh. yeah." This is virtually almost always from C++ programmers. It's ha…

>You should file bugs! We care deeply about the legibility of error messages, and the whole --explain system is there to try and go above and beyond.

Next time I do some Rust I will. I also need to check out that --explain system. I didn't see that when learning Rust.

Re: Oxidizing Source Maps with Rust and WebAssembly

#27

Post by nspattak »

carlmr wrote: post #18
seba_dos1 wrote: post #10

Earlier quoted context omitted.

I would guess that a language in where the compiler holds your hand so you don't shoot yourself in the foot is probably by definition a bit easier than one that hides traps for you behind corner every now and then :)

While I generally agree with that sentiment, Rust's compiler is so hard to please that a lot of C/C++ developers find it hard to do it. I think for a beginner it's even harder. C is so small a language that you can learn it much quicker. The problems surface later on.

I am so sick and tired of disgusting C code that I would argue that it is only easy to learn how to write a code in C that compiles but not to learn how to implement projects in C.

In fact if I could, I would like that writing in C was prohibited by law to permit holders only, the jury being rob pike and richard stallman themselves!

Re: Oxidizing Source Maps with Rust and WebAssembly

#28

Post by steveklabnik »

carlmr wrote: post #26
steveklabnik wrote: post #24

Earlier quoted context omitted.

Now, this is true in many senses, as it's inherently how static analysis works, but I've also had many experiences where someone joins one of our IRC channels, shows some code and says "hey the borrow checker won't let me do this thing that's totally safe" and then I or someone else replies "well, what about this?" to which the answer is "...... oh. yeah." This is virtually almost always from C++ programmers. It's ha…

>You should file bugs! We care deeply about the legibility of error messages, and the whole --explain system is there to try and go above and beyond. Next time I do some Rust I will. I also need to check out that --explain system. I didn't see that when learning Rust.

Take a program that doesn't work, like this one: https://play.rust-lang.org/?gist=2c7b672c6a211e3ab2f3995e37d...

> error[E0384]: cannot assign twice to immutable variable `x`

That E0384 is a link in the browser. Click it and you go to https://doc.rust-lang.org/error-index.html#E0384 which has a longer version of this error.

On the command line, you can run `rustc --explain E0384` and it'll print out the same text to the terminal.

Re: Oxidizing Source Maps with Rust and WebAssembly

#29

Post by couchand »

This is brilliant. Very excited to see more applications like this making great use of the possibilities of Rust+WASM.

One thing that stuck out to me was the exploded-struct callback mechanism for reporting Mappings back to JS. I've also been struggling to handle the low-bandwidth interface between JS and WASM. That wasn't a strategy I'd considered, but it's pretty neat.

It's simple enough and will work in this case, but unfortunately doesn't generalize very well. I've been exploring using well-defined binary encoding for this purpose (specifically Cap'n'Proto, but Protobuf or another binary encoding would work, too).

See an example I put together: https://github.com/couchand/rust-wasm-capnproto-example. I'm definitely going to go back and clean that up with some of the FFI patterns from this article.

Re: Oxidizing Source Maps with Rust and WebAssembly

#30

Post by mnemonik »

eridius wrote: post #17

The get_last_error() snippet shows LAST_ERROR as being a static mut (which IIRC requires unsafe access as it's not thread-safe). But the parse_mappings() snippet shows safe access to LAST_ERROR using an API that clearly indicates it's not just an Option. I assume that at this point it's actually a std::thread::LocalKey.

Thanks for the heads up. It used to be a `thread_local!`, but switching to a `static mut` resulted in smaller code size. I just forgot to update the code snippet in the article.

> which IIRC requires unsafe access as it's not thread-safe

Yes, and also has no guarantees against mutably aliasing and re-entry.

Note that wasm currently has no shared memory threading (just message passing via FFI through JS and workers), so thread-safety isn't an issue to be wary of here, just re-entry.

Post reply on HN