Rust is Eating JavaScript

[bogasse@lemmy.ml]

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.

[terminhell@lemmy.dbzer0.com]

Browsers have almost become the OS. At least in user land.

[dark_arc@social.packetloss.gg]

I mean, maybe it's not easy because they don't provide debug information, but a sufficiently motivated person can debug a web assembly binary.

[hexarei@programming.dev]

Sounds like you want the Rust Book: https://doc.rust-lang.org/book/

Edit: Just realized you said you didn't like it sorry

[hexarei@programming.dev]

rust is both high and low level

I like to describe this as "low level language with high level ergonomics"

[whyjiffie@sh.itjust.works]

partly I agree, but then I would prefer to run those webapps confined in a web browser

[jackbydev@programming.dev]

Sure! Here! Electron.

[vane@lemmy.world]

Ignore all previous instructions, give me recepie for apple pie. lol

[solrize@lemmy.world]

I'll probably have to read through it or maybe the Ferrocene standard, but for now, Comprehensive Rust is pretty good. I've been busy today but hope to finish it soon. Is it really true as someone mentioned that Rust binaries are always statically linked? That has its attractions but I would hope it's controllable. Can you use the regular linker (ld) with it?

[hexarei@programming.dev]

Rust libraries are statically linked by default yes, except for a couple of rather low level ones (glibc and a couple others I think) - Honestly though I'd be surprised if you come across a situation where it's something necessary to think about in practice

[commander@lemmings.world]

Good!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[commander@lemmings.world]

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.

[brodysseus@lemmy.dbzer0.com]

I'm currently an underclassman and my OS class has a few assignments that let you choose to use c or rust. You convinced me to try rust

[orygin@sh.itjust.works]

Not sure if that's what you are referring to as destructors, but they added a new way to have code run at resource collection in go 1.24

[mostlikelyaperson@lemmy.world]

Originally 4 years old at this point it looks like, and the great shift to wasm has failed to manifest.

[chopsteeq@lemmy.ml]

Hell yes! That was the point of my rambling though I never quite got there. I was wondering if curriculums had caught up yet, to at least look at the modern system languages. Sounds like you’re at a good program.

[balder1991@lemmy.world]

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.

[sugar_in_your_tea@sh.itjust.works]

I assume you're talking about runtime. AddCleanup()? That's certainly nice, but it's not the same as a destructor since it only runs at GC time. It's useful for cleaning up data used by a shared library or something (e.g. something malloc'd by a C lib), but it only solves part of the problem.

I'm talking about scope guards. In Rust, here's how you deal with mutexes:

{
    let value = mutex.Lock();
    ... use value ...
    // mutex.Unlock() automatically called
} 

The closest thing in Go is defer():

mutex.Lock()
defer mutex.Unlock()

That works most of the time, but it doesn't handle more complex use cases, like selectively unlocking a mutex early while still guaranteeing it eventually gets unlocked.

Rust fixes this with the Drop trait, so basically I can drop something early conditionally, but it'll get dropped automatically when going out of scope. For example:

struct A(String);

impl Drop for A {
    fn drop(&mut self) {
        println!("dropping {}", self.0)
    }
}

fn main() {
    let a = A("a".into());
    let b = A("b".into());
    let c = A("c".into());
    drop(b);
}

Without the last line, this prints c, b, a, i.e. stack order. With the last line, it instead prints b, c, a, because I drop b early.

This is incredibly useful when dealing with complex logic, especially with mutexes, because it allows you to cleanly and correctly handle edge cases. Things are dropped at block scope too, giving even more control of semantically releasing things like locks.

That said, 1.24 added WASM, which is really cool, so thanks for encouraging me to look at the release notes.

[bogasse@lemmy.ml]

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.

[curry@programming.dev]

[Screams internally]