318
Rust is Eating JavaScript
(leerob.com)
Honestly those usecases described here shouldn’t have been done in js in the first place.
Look, I'm in no position to talk seeing as I once wrote a cron job in PHP, but the profusion of JavaScript in the late aughts and early teens for things that weren't "make my website prettier!" feels very much like a bunch of "webmasters" dealing with the fact that the job market had shifted out from under them while they weren't looking and rebranding as "developers" whose only tool was Hammer.js, and thinking all their problems could be recontextualized as Nail.js.
I agree.
I'm noticing this species has a problem with doing things the obviously correct way the first time.
It's as though we'd rather put 100x more effort for 10% of the results just to prove that we "can" do it.
Well I see huge benefits in building the tools used by a community with the technology this community masters. IMO the Python's stdlib sucks because it's written in C which is a huge barrier to entry.
Not all of the stdlib is written in C. Some parts cannot be Python because it’s critical code that needs to be as fast as possible.
Python is already slow for many use cases, if the standard lib was all built in Python it would be just too slow for much more use cases.
I didn't mean it's a bad choice !
But I think it's a good example of the compromise that has to be made here : what's the best fitting technology vs. how to ensure easy onboarding for future contributors.
Good!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Can we please go back to making programs for the target OS and skip the browser dependency?
Sure! Here! Electron.
[Screams internally]
Browsers have almost become the OS. At least in user land.
load more comments
(1 replies)
JavaScript has its place as a lightweight runtime interpreter.
Rust has its place as a secure and modern way to engineer and produce dependable software.
with wasm and friendly new web frameworks, the only thing keeping js alive is inertia
Essentially, JS is the new Flash….
Eh, it's not that lightweight, Lua is much better for that.
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.
I think once you get into rust you just have a hard time going back, and it doesn't feel "hard" anymore. I can practically rust as easily as I can python for scripting and for API servers.
Rust really only gets hard when doing library development IMO. That's when you need lifetimes and well chosen types. But that's also why Rust libraries are superb.
load more comments
(10 replies)
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.)
- 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.
- 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 alsoexpect)foo().unwrap_or_default()to ignore the error and continue the happy path with 0.0foo().unwrap_or(13.37)to use your defaultfoo()?to return with the error and let the parent handle it, maybe
That sounds a lot like how checked exceptions work, though with some terser handling syntax.
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 ?
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.
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.
Go is fine, but it has its flaws. I prefer Rust because:
- memory safety is a compiler check, not a runtime check, so you catch issues earlier
- locks contain their values, so you can't accidentally do anything unsafe
- no nil (
()is semantically different), so no surprises with contracts - everything is an expression, which lends itself really well to FP concepts
- actual dependency management at 1.0
- pretty much no runtime, so calling from another language is super easy
- targets WASM and microcontrollers
- no pointers (not exactly true)
It takes longer to learn, but I'm about as productive with both now.
load more comments
(1 replies)
- Rust is the best language for writing WASM in, so you can write Rust and run it in the browser without transpiling to JS.
- Rust isn't just about speed or GC pauses. Its type system is amazing and allows you to encode things that you cannot in any other mainstream language.
- It's so incredibly well designed, it fewla like that clip from Ricky and Morty where Morty feels what standing on a truly even plane feels like then has a panic attack when he leaves. Rust rethought everything from scratch, and isn't just some new syntax or fancy compiler tricks. No null, no exceptions, no inheritance, new typing capabilities, etc.
Go made some pretty poor design choices, and now even Google is choosing Rust for a lot of stuff instead.
load more comments
(7 replies)
Maybe give it a try; it's my favorite language to write programs in now, it has an extremely good standard library, and for everything else there's a mass of high quality crates, its build system is actually competent and makes compiling on Windows or Linux trivial, plus many, many more quality of life features.
load more comments
(10 replies)
Has Golang fizzled? It has struck me as too primitive, but basically on the right track.
My biggest issue with Golang by far is the close tie to Google. They are not our friendly innovator, time and time again they make decisions that will help them earn more ad money, and nothing else. And they have a lobg history of releasing something and then never fix the issues with it, and then more or less abandon it.
Other than that there are afaik some other issues with go, I'm not an expert but from what I hear the GC is quite aggressive and you can't tell it to run when you want. Doing something time sensitive? Well, bad luck. GC time!
load more comments
(5 replies)
load more comments
(6 replies)
Thank god.
Nom nom nom
Everything eventually becomes a crab.
That means eventually everything tastes great when smothered in butter. 🤤
load more comments
(2 replies)
Can browsers run rust in the front end instead of javascript, or is it limited to build time and backend stuff?
Sort of, browsers can run rust code through webassembly. But i dont think this is a full replacement for JavaScript as of yet.
Yeah, you need to have some JS to manipulate graphics, so the Rust web frameworks have a JS shim to do that and communicate with the WebAssembly Rust code as necessary. It works surprisingly well tho.
load more comments
(1 replies)
Is this a 2yo write up, considering the last update was in 2023?
Originally 4 years old at this point it looks like, and the great shift to wasm has failed to manifest.
It was recently shared on Hackernews, I assume that's why it's showing up here now.
Can I just say how beautiful that page is? Such a delight to read the text on it. The legibility. The simplicity. 😙👌
Guten Appetit!
view more: next ›
this post was submitted on 16 Feb 2025
318 points (100.0% liked)
Technology
62853 readers
3618 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