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

51–60 of 78 posts

Re: Rust for JavaScript Developers – Functions and Control Flow

#51

Post by Kkoala »

mekkkkkk wrote: post #40
bobbylarrybobby wrote: post #12

Earlier quoted context omitted.

I find ternary operators perfectly readable if you split the parts across lines — they map exactly to the conditions and statements in an if-else group. Cond1 // if this ? Result1 // return this : cond2 // else if this ? Result2 // return this : cond3 // else if this ? Result3 // return this : ResultElse // else return this

I've come to hesistently accept nested ternaries, but I try to have all lines lead with a colon. This kinda mimics a switch statement with returns. firstPossible ? thenThis : secondPossible ? thenThisOtherThing : thirdPossible ? thenThisThirdThing : defaultThing Always fun to see how people treat ternary nesting. They still feel a bit naughty to me. The terseness is sort of unbeatable though.

It's funny how people have so many different preferences for ternary formatting. I can't think of any other operator that would have tens of different format prefs.

Re: Rust for JavaScript Developers – Functions and Control Flow

#52

Post by delta1 »

eximius wrote: post #24
hardwaregeek wrote: post #2

It'd be nice to mention that Rust has if expressions, not if statements. Therefore the example could be simplified to: fn calculate_tax(income: i32) -> i32 { if income = 10 && income

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...

Re: Rust for JavaScript Developers – Functions and Control Flow

#53

Post by FranceBacce »

dgb23 wrote: post #47
esperent wrote: post #42

Earlier quoted context omitted.

> "Arrow functions" are just sugar This statement is incorrect. There are important differences between arrow functions and regular function. > An arrow function expression is a syntactically compact alternative to a regular function expression, although without its own bindings to the this, arguments, super, or new.target keywords https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I include this in sugar as in: You can refactor an arrow function into a specific regular function but you usually end up with something more verbose. Or in other words you can express all things "arrow" before it existed. Which is exactly what we did before they were adopted. And we still in fact do, just automated by transpilers like Babel[0]. But more importantly, in the context of the article: all functions in JS…

Well you couldn't resolve "this" lexically without some closure tricks like that = this , so sure, you could do everything you do with arrows without them, but not with one function alone

Re: Rust for JavaScript Developers – Functions and Control Flow

#54

Post by jfkebwjsbx »

IshKebab wrote: post #48
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…

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.

Re: Rust for JavaScript Developers – Functions and Control Flow

#55

Post by jfkebwjsbx »

skocznymroczny wrote: post #25
65536 wrote: post #7

Earlier quoted context omitted.

Speaking of which, coming from Rust (well, when I say it like that it sounds like Rust is the only language I ever used which is of course not true. I think Rust as a first language would be highly unusual still), I enjoyed being able to say Rust code: let foo = if x 50 { 9000 } else { 42 }; And I miss this in Swift. The ternary operator is fine on its own but I’m not a huge fan of nested ternary operators. With a bi…

I dislike the ternary operator in languages like C++. And many languages copy-paste it because they are used to it. I much prefer the more literal and reversed form in Python. Instead of: int salary = isEmployed() ? 2000 : 0 I prefer: int salary = 2000 if isEmployed() else 0

I love that idea, but I still prefer it’d read the same as an if. Meaning the condition first and the false case last.

Re: Rust for JavaScript Developers – Functions and Control Flow

#56

Post by FranceBacce »

Coming from writing JS all day, I've recently started learning Rust and I find it extremely refreshing. Yes, it is heavy, low level and forces you to think about how things work under the hood, but it empowers me to do high performance stuff I just coulnd't do in JS before.

Def recommend it as a second / third language

Re: Rust for JavaScript Developers – Functions and Control Flow

#58

Post by esperent »

dgb23 wrote: post #47
esperent wrote: post #42

Earlier quoted context omitted.

> "Arrow functions" are just sugar This statement is incorrect. There are important differences between arrow functions and regular function. > An arrow function expression is a syntactically compact alternative to a regular function expression, although without its own bindings to the this, arguments, super, or new.target keywords https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I include this in sugar as in: You can refactor an arrow function into a specific regular function but you usually end up with something more verbose. Or in other words you can express all things "arrow" before it existed. Which is exactly what we did before they were adopted. And we still in fact do, just automated by transpilers like Babel[0]. But more importantly, in the context of the article: all functions in JS…

> I include this in sugar as in:

Fair enough, but you are probably alone in doing so.

Re: Rust for JavaScript Developers – Functions and Control Flow

#59

Post by oaiey »

chrismorgan wrote: post #46
esperent wrote: post #44

Earlier quoted context omitted.

What's the reason for including ease of machine parsing? Aside from the fact it might make the compiler slighty easier to write I guess. I'm sure that code that's easy for machines and humans to parse is harder for humans to parse than code where humans are the first class citizens.

Many languages require arbitrary lookahead in order to parse code. (Some are even worse, e.g. C++ requires a full compiler to parse it because of the question of whether `(a (d))` is calling a generic function a , or doing two comparisons; and Perl is unparseable, you’ve got to run it before you can figure out how certain things should be parsed.) Rust’s philosophy has been to avoid that, and make it simple to parse,…

I agree to avoid look ahead etc, however, that could be solved more consistently when you look holistically at the beginning of your language design. Considering Rust was fresh restart (similar to C#), I expected more consistency.

But maybe I should take a step back, considering my limited Rust knowledge :)

Re: Rust for JavaScript Developers – Functions and Control Flow

#60

Post by nicoburns »

jfkebwjsbx wrote: post #55
skocznymroczny wrote: post #25

Earlier quoted context omitted.

I dislike the ternary operator in languages like C++. And many languages copy-paste it because they are used to it. I much prefer the more literal and reversed form in Python. Instead of: int salary = isEmployed() ? 2000 : 0 I prefer: int salary = 2000 if isEmployed() else 0

I love that idea, but I still prefer it’d read the same as an if. Meaning the condition first and the false case last.

Rust implements this:

    let foo = if is_employed() { 2000 } else { 0 }
Post reply on HN