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

61–70 of 78 posts

Re: Rust for JavaScript Developers – Functions and Control Flow

#61

Post by deleuze »

oaiey wrote: post #34

Now it is official: I like (modern) JavaScript. I am a C# guy and every time I see modern Rust, C++ or Go syntax I am really surprised by its deviation from the norm (which is interestingly no longer C but a hybrid between JS/Java/C#). I mean why different Rust syntax for closures and functions. || vs (). On the other hand, the linage is not Java/JS/C# to Rust but C/C++ to Rust. Considering that, it is an improvement…

Syntax is the least interesting thing about a language (unless it's a lisp ^^). Why not different syntax for closures?

Re: Rust for JavaScript Developers – Functions and Control Flow

#62

Post by untog »

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…

As another JS -> Rust dev I do agree. Over time I have grown to understand why it complains when I do X, Y and Z and I like having deeper visibility into what's going on. That said, I did some experimentation with Nim and it truly feels like a language that does the best of both. But the community isn't so huge.

Re: Rust for JavaScript Developers – Functions and Control Flow

#63

Post by GrayShade »

65536 wrote: post #7
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

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…

It's probably not the most idiomatic thing, but in Rust you can write:

    let foo = match () {
        _ if x  0,
        _ if something_else > 50 => 9000,
        _ => 42,
    };

Re: Rust for JavaScript Developers – Functions and Control Flow

#64

Post by Chris_Newton »

esperent wrote: post #44
chrismorgan wrote: post #36

Earlier quoted context omitted.

Rust has a philosophy of easy machine and human parsing. ECMAScript-style `(…) => …` requires that you get to the => before you know whether the (…) is a parenthesised expression or function arguments. With `|…| …`, you know you’re dealing with a closure immediately because there’s no unary pipe operator.

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.

There is at least one compelling argument for making new languages easy for machines to parse: it makes it easier to write good supporting tools.

We don’t just use a compiler or interpreter any more. We also use editors and refactoring tools and debuggers and profilers and style checkers and source formatters and static safety analysers and diff tools and… If the developers of these tools don’t have to worry so much about the mechanics of parsing the source, that leaves more resources to spend on making each tool useful.

To some extent you could achieve the same benefit by making a library available to parse the source and return some sort of annotated AST or similar data structure. However, unless you can provide an easy way to call that library from every language someone might want to use to write a tool, avoiding unnecessarily complicated parsing still seems advantageous.

Re: Rust for JavaScript Developers – Functions and Control Flow

#65

Post by wenc »

Chris_Newton wrote: post #64
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.

There is at least one compelling argument for making new languages easy for machines to parse: it makes it easier to write good supporting tools. We don’t just use a compiler or interpreter any more. We also use editors and refactoring tools and debuggers and profilers and style checkers and source formatters and static safety analysers and diff tools and… If the developers of these tools don’t have to worry so much…

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/refactoring for languages like Python and they're pretty zippy (I used to have concerns about speed, but in practice it's a non-issue). Those same language servers are also supported in Vim, emacs, etc. The editor itself doesn't need to know anything about the underlying language. And it looks like a Rust language server exists:

https://rls.booyaa.wtf/

In fact, to take the idea further, the goal of the Roslyn [2] project is to expose APIs to the compiler itself in order to provide services to external dev tooling. Imagine a third-party generic debugger being able to tap into compiler or runtime internals and provide services around them it without explicitly knowing anything about the underlying language.

[1] https://en.wikipedia.org/wiki/Language_Server_Protocol

[2] https://en.wikipedia.org/wiki/Roslyn_(compiler)#Architecture

Re: Rust for JavaScript Developers – Functions and Control Flow

#67

Post by steveklabnik »

wenc wrote: post #65
Chris_Newton wrote: post #64

Earlier quoted context omitted.

There is at least one compelling argument for making new languages easy for machines to parse: it makes it easier to write good supporting tools. We don’t just use a compiler or interpreter any more. We also use editors and refactoring tools and debuggers and profilers and style checkers and source formatters and static safety analysers and diff tools and… If the developers of these tools don’t have to worry so much…

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…

> And it looks like a Rust language server exists:

There are two, actually. That one, and https://github.com/rust-analyzer/rust-analyzer which is quickly supplanting it.

The intention is that the compiler will eventually be a language server. Someday.

Re: Rust for JavaScript Developers – Functions and Control Flow

#68

Post by amenod »

giantDinosaur wrote: post #35
amenod wrote: post #22

Earlier quoted context omitted.

True, or even: Cond1 // if this ? Result1 // return this : cond2 // else if this ? Result2 // return this : cond3 // else if this ? Result3 // return this : ResultElse // else return this

Goodness me that has potential to become something truly hideous.

It's actually not that bad in practice... But I guess the pragmatic formatting is "whatever `prettier` does by default" anyway. :)

Re: Rust for JavaScript Developers – Functions and Control Flow

#69

Post by Chris_Newton »

wenc wrote: post #65
Chris_Newton wrote: post #64

Earlier quoted context omitted.

There is at least one compelling argument for making new languages easy for machines to parse: it makes it easier to write good supporting tools. We don’t just use a compiler or interpreter any more. We also use editors and refactoring tools and debuggers and profilers and style checkers and source formatters and static safety analysers and diff tools and… If the developers of these tools don’t have to worry so much…

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 the position I described before.

Re: Rust for JavaScript Developers – Functions and Control Flow

#70

Post by giancarlostoro »

crazypython wrote: post #57

In response to this post, I wrote "Dlang for JavaScript Developers." Here it is: https://news.ycombinator.com/item?id=23747652

Thanks for that, I don't do enough D to know some of these syntatic features but I do love the language. I do plenty of JS so this overview is spot on for me.
Post reply on HN