Technology

62936 readers

4239 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each other!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed
Accounts 7 days and younger will have their posts automatically removed.

Approved Bots

founded 2 years ago

MODERATORS

[email protected]

309

Rust is Eating JavaScript (leerob.com)

submitted 3 days ago by [email protected] to c/[email protected]

104 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 70 points 3 days ago* (last edited 3 days ago) (54 children)

The JS tooling universe has always seemed like a Lovecraftian hellscape to me. I've managed to stay away from it so far, but if I were caught in it, of course I'd be trying to escape any way I could. It sounds like Rust's attraction here has been as a viable escape corridor rather than anything about Rust per se.

In particular, I get that everyone wants their code to be faster, and I get that certain bloaty apps (browsers) need to get their memory footprint under control, and a few niche areas (OS kernels, realtime control) can't stand GC pauses. Other than that though, what is the attraction of Rust for stuff like tooling? As opposed to a (maybe hypothetical) compiled, GC'd language with a good type system and not too much abstraction inversion (Haskell's weakness, more or less).

Has Golang fizzled? It has struck me as too primitive, but basically on the right track.

Rust seems neat from a language geek perspective, but from what I can tell, it requires considerable effort from the programmer handle a problem (manual storage reclamation) that most programs don't really have. I do want to try it sometime. So the Rust question is intended as more inquisitive/head scratching rather than argumentative.

[–] [email protected] 15 points 3 days ago (6 children)

I usually pick Rust for CLI tools because:

It's statically compiled and isn't dependent on system binaries and won't break if there if the system has the wrong version like C/C++, allowing you to distribute it as a single binary without any other installation steps
Still produces fairly small binaries unlike languages like Java or C# (because of the VM)
Is a modern language with a good build system (It's like night and day compared to CMake)
And I just like how the language works (errors as values etc.)

[–] [email protected] 8 points 3 days ago (5 children)

It's statically compiled and isn't dependent on system binaries and won't break if there if the system has the wrong version like C/C++, allowing you to distribute it as a single binary without any other installation steps

You can do that with C++ too.

Still produces fairly small binaries unlike languages like Java or C# (because of the VM)

I mean, the jars are actually pretty small; but also I really don't get the storage argument. I mean we live in a world where people happily download a 600 MB discord client.

Is a modern language with a good build system (It's like night and day compared to CMake)

Meson exists ... as do others.

And I just like how the language works (errors as values etc.)

Fair enough; though why? What's wrong with exceptions?

I work in a code base where I can't use exceptions because certain customers can't use exceptions, and I regularly wish I could because errors as values is so tedious.

[–] Zykino 1 points 2 days ago (2 children)

Is a modern language with a good build system (It's like night and day compared to CMake)

Meson exists ... as do others.

But they are not the default option. And your new job may not use them.

And I just like how the language works (errors as values etc.)

Fair enough; though why? What's wrong with exceptions?

Exceptions is a non standard exit point. And by "non standard" I'm not talking about the language but about its surprise appearance not specified in the prototype. Calling double foo(); you don't know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?

By contrast fn foo() -> Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it's good:

foo().unwrap() panic in case of error (see also expect)
foo().unwrap_or_default() to ignore the error and continue the happy path with 0.0
foo().unwrap_or(13.37) to use your default
foo()? to return with the error and let the parent handle it, maybe

[–] [email protected] 2 points 2 days ago (1 children)

That sounds a lot like how checked exceptions work, though with some terser handling syntax.

[–] Zykino 2 points 1 day ago (1 children)

First time I hear about checked exceptions. How do you use them ? Are you forced to handle them explicitly ? Is the handling checked at compile time ?

[–] [email protected] 2 points 1 day ago

Checked exceptions require a function to declare the exceptions it can throw. The caller function must then catch and handle the exception, or the exception would bubble up a level, in which case the caller must also include that exception among the exceptions it declares that it can throw. I don't know if C++ does this, but Java/C# do. It sounds exactly like Rust's system except with different syntax.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago)

But they are not the default option. And your new job may not use them.

Who cares if it's the default? If it's the best tool, use it.

It's silly to have a reason for "going Rust" be the build system, especially in the context of something as new as a WASM context where basically any project is going to be green field or green field adjacent.

Exceptions is a non standard exit point. And by "non standard" I'm not talking about the language but about its surprise appearance not specified in the prototype. Calling double foo(); you don't know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?

And that's a feature not a bug; it gets incredibly tedious to unwrap or forward manually at every level.

By contrast fn foo() -> Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it's good:

You can do this in C++ https://en.cppreference.com/w/cpp/utility/expected (and as I said, if you feel so inclined, turn off exceptions entirely); it's just not the "usual" way of doing things.

load more comments (2 replies)

load more comments (49 replies)