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

Rust for JavaScript Developers – Functions and Control Flow

sheshbabu.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Rust for JavaScript Developers – Functions and Control Flow

#71

Post by nyanpasu64 »

MuffinFlavored wrote: post #9

I just converted a relatively simple node.js program to Rust (because the native libusb bindings for node.js crash immediately on Windows 7 64-bit) Rust made me worry about a lot more than I wanted to. Threads, locking, mutability. What was 80 lines of: 1. open USB device, get handle 2. start a WebSocket server, accept clients 3. proxy incoming USB device traffic to all WebSocket clients 4. proxy incoming WebSocket t…

> You can't just "move variables from one scope into callback/lambda" scope with any sort of ease in Rust.

Have you tried `move || {...}`?

Re: Rust for JavaScript Developers – Functions and Control Flow

#72

Post by nyanpasu64 »

delta1 wrote: post #52
eximius wrote: post #24

Earlier quoted context omitted.

Rust can also match on ranges which is perhaps the most idiomatic form for this.

fn calculate_tax(income: i32) -> i32 { match income { 0..=9 => 0, 10..=49 => 20, _ => 50, } } https://play.rust-lang.org/?version=stable&mode=debug&editio...

This behaves differently for negative incomes, which are not prohibited by the i32 argument passed in (u32 cannot take on negative values).

Re: Rust for JavaScript Developers – Functions and Control Flow

#73

Post by wenc »

Chris_Newton wrote: post #69
wenc wrote: post #65

Earlier quoted context omitted.

As you alluded to in your 3rd paragraph, that is exactly the problem that "language servers" [1] aim to solve. The API is JSON-RPC based, which is callable from any tool. If every modern language shipped with a canonical language server, machine parseability becomes a non-issue since the parser would be the same as that of the compiler's. For instance, VS Code already uses language servers to support autocomplete/ref…

It probably won’t surprise you to learn that I had LSP in mind when writing my previous comment. :-) I think there is a wider issue here than the (still very useful) scope of LSP, though. If you are building a tool that depends heavily on the semantics of the source language, beyond common operations like “go to definition”, you might need more than a standardised language server can provide, and then you’re back to…

I had the sense it was on the tip of your tongue since the way you described it matched to a T, but I decided to flesh it out for folks who hadn't heard of LSPs. :)

You're right, at this moment, the LSP is circumscribed in that it doesn't expose the AST (even though it could) which means one is limited to the capabilities it does expose. The claim is that the goal is parity across languages and exposing the ASTs is contrary to this [1]. I'm hoping this philosophy is challenged. In the mean time one might have to rely on languages themselves exposing their ASTs, eg. Python is able to expose its ast (via the ast module).

So yes, right now one wouldn't be able to write say an IntelliJ IDEA type IDE based off a language server alone -- one wouldd have to be able to create the AST oneself.

[1] https://github.com/Microsoft/language-server-protocol/issues...

Re: Rust for JavaScript Developers – Functions and Control Flow

#74

Post by eximius »

nyanpasu64 wrote: post #72
delta1 wrote: post #52

Earlier quoted context omitted.

fn calculate_tax(income: i32) -> i32 { match income { 0..=9 => 0, 10..=49 => 20, _ => 50, } } https://play.rust-lang.org/?version=stable&mode=debug&editio...

This behaves differently for negative incomes, which are not prohibited by the i32 argument passed in (u32 cannot take on negative values).

Ranges support negatives, so thats nice. Though i32::MIN..=9 is at least slightly odd.

Re: Rust for JavaScript Developers – Functions and Control Flow

#75

Post by delta1 »

nyanpasu64 wrote: post #72
delta1 wrote: post #52

Earlier quoted context omitted.

fn calculate_tax(income: i32) -> i32 { match income { 0..=9 => 0, 10..=49 => 20, _ => 50, } } https://play.rust-lang.org/?version=stable&mode=debug&editio...

This behaves differently for negative incomes, which are not prohibited by the i32 argument passed in (u32 cannot take on negative values).

Yeah I was just literally translating the previous code as an example, I didn't get the business rules specification

¯\_(ツ)_/¯

Re: Rust for JavaScript Developers – Functions and Control Flow

#76

Post by IshKebab »

jfkebwjsbx wrote: post #54
IshKebab wrote: post #48

Earlier quoted context omitted.

Yeah part of this is definitely true - Rust is more more verbose about things you often don't really care about (e.g. `String`/`str` in code that only runs once - who cares?). But a lot of the extra effort in writing Rust code is about moving runtime errors to compile time. It's like static types - more effort writing it but you don't spend ages debugging typos at runtime. I've had way more instances of spending seve…

> In C++ it's so rare If you were talking about C, perhaps. Modern C++ has a strict type system if you don't walk around it. Nevertheless, the borrow checker can help with bugs that otherwise could be hiding, which is the actual advantage over C++. But those are not the kind you see right away after running your program again.

I'm not just talking about the borrow checker though - Rust has a much more strict type system in general. It's really explicit about everything, for example you can't just `println!("{}", some_path)` because `Path` might contain invalid UTF-8 that can't be converted to a string.

Re: Rust for JavaScript Developers – Functions and Control Flow

#77

Post by jfkebwjsbx »

IshKebab wrote: post #76
jfkebwjsbx wrote: post #54

Earlier quoted context omitted.

> In C++ it's so rare If you were talking about C, perhaps. Modern C++ has a strict type system if you don't walk around it. Nevertheless, the borrow checker can help with bugs that otherwise could be hiding, which is the actual advantage over C++. But those are not the kind you see right away after running your program again.

I'm not just talking about the borrow checker though - Rust has a much more strict type system in general. It's really explicit about everything, for example you can't just `println!("{}", some_path)` because `Path` might contain invalid UTF-8 that can't be converted to a string.

That is the same in C++.

Again, I think you are talking about C's type system, not C++'s.

Re: Rust for JavaScript Developers – Functions and Control Flow

#78

Post by kybernetikos »

29athrowaway wrote: post #11

Doing currency manipulation using with i32 as an example for developers of a language that only supports float. What can go wrong? Not only this is a bad idea from a programming perspective, or a teaching perspective, it is also a bad idea from a taxation perspective. In terms of taxation, what you suggest would result in [at least] civil penalties. If you are going to create examples of code that manipulates currenc…

> Doing currency manipulation using with i32 as an example for developers of a language that only supports float. What can go wrong?

Using i32 for currency calculations is probably a bad idea (although there are situations where it would be OK), but this has absolutely nothing to do with javascript - it's no worse in js than it is in rust, since javascript fully supports all i32 numbers. In fact, it has a number of bitwise operators that operate on i32 numbers, and a bitwise operator that even works on u32 numbers.

Post reply on HN