Comment

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 this post is intended as more inquisitive/head scratching rather than argumentative.

source

Sort:hotnew top

sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
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.
source
- solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
  Thanks, “Comprehensive Rust” is readable so far, though I haven’t gotten to the “fun” (memory management) parts yet.
  
  source
qaz@lemmy.world ⁨1⁩ ⁨year⁩ ago
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.)
source
- Dark_Arc@social.packetloss.gg ⁨1⁩ ⁨year⁩ ago
  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.
  
  source
  - Zykino@programming.dev ⁨1⁩ ⁨year⁩ ago
    
    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
    
    source
    Dark_Arc@social.packetloss.gg ⁨1⁩ ⁨year⁩ 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 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++ 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.
    
    source
    tzrlk@lemmy.world ⁨1⁩ ⁨year⁩ ago
    That sounds a lot like how checked exceptions work, though with some terser handling syntax.
    
    source
    -> View More Comments
rottingleaf@lemmy.world ⁨1⁩ ⁨year⁩ ago

The JS tooling universe has always seemed like a Lovecraftian hellscape to me.

That’s most of any programming of today for me.

If it can’t be grasped in a couple of days - then na-ah.

I can patch something I need working which doesn’t, written in C.

autotools ftw

source
pr06lefs@lemmy.ml ⁨1⁩ ⁨year⁩ ago
I think there’s room for a rust-lite language that is GCed. Something with a functional-style type system and that compiles to machine code.

Roc is a candidate for this language. Basically Elm that compiles to machine code, but with a number of tweaks to make it work for more than just a web front end. Like Elm, the type system is haskell like, but simplified.

source
- sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
  Sounds kinda like Go. It’s not functional, but functional patterns work well there.
  
  It’s not great for FE though.
  
  source
  - pr06lefs@lemmy.ml ⁨1⁩ ⁨year⁩ ago
    What’s FE?
    
    source
    sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
    Front end
    
    source
- balder1991@lemmy.world ⁨1⁩ ⁨year⁩ ago
  There’s already Swift, which isn’t garbage collected, but the ref. counting does the same in practice.
  
  The only problem with Rust and Swift, Kotlin etc. in my opinion is that they keep growing and getting more complex with no signs of stopping.
  
  source
- solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
  Thanks, Roc sounds interesting. Ocaml also maps more closely to machine operations than Haskell does, so it has always seemed like another alternative. AMD has something called ROCm which is their version of CUDA, but I assume that is unrelated.
  
  source
Glitchvid@lemmy.world ⁨1⁩ ⁨year⁩ ago
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.

source
- CHOPSTEEQ@lemmy.ml ⁨1⁩ ⁨year⁩ ago
  If Rust had been around when I was an underclassman, I would have been totally locked into the full CompSci track. Instead, I got introduced to Java and C (and calculus…) and that looked like a nightmare compared to what I had been playing with in JS/Python land, so I noped on out of there and got a Comp Sci Lite degree.
  
  Years later, I’m just completely in love with Rust.
  
  source
  - Brodysseus@lemmy.dbzer0.com ⁨1⁩ ⁨year⁩ ago
    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
    
    source
    CHOPSTEEQ@lemmy.ml ⁨1⁩ ⁨year⁩ ago
    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.
    
    source
- solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
  Yes it’s on my infinite todo list. I’m just being too much of a curmudgeon about the available textbooks, and had a sinking feeling when the main one didn’t get “hello world” out of the way on page 1, and shift to the specifics of the language.
  
  source
  - Glitchvid@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Rust By Example is very good for showing the ropes in a very practical way, that’s how I got up and running with it.
    
    Secondly is the O’Reilly book Programming Rust, which is probably closer to what you want, it explains the actual technical details of much of the language, and to me seems written for an audience that already knows programming. Lastly would be Rust for Rustaceans by No Starch Press, if you actually do want to pursue Rust further, as it discusses very, very in detail the systems of the language, and how they can be used to make something so powerful like Serde.
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Thanks, Rust by Example looks ok, and I’m acquainted with one of Programming Rust’s authors, which is cool. I’m currently looking at “Comprehensive Rust”. All these though seem to be about the Rust software ecosystem (compilers, package tools, libraries) as much as they are about the language. I had hoped to start by just reading about the language, if something like that exists. I don’t particularly want to write any Rust programs until I’ve finished reading some kind of language overview, which means that all the stuff about build tools are just a distraction during that stage. As another commenter in this thread said though, ecosystems and languages have become pretty much inseparable, so maybe that’s why the books are that way.
    
    This also looks interesting:
    
    dr-knz.net/rust-for-functional-programmers.html
    
    This says nothing about Rust, but it’s a humorous classic. I’d be interested to know how to describe Rust in these terms.
    
    …blogspot.com/…/brief-incomplete-and-mostly-wrong…
    
    source
  - thejml@lemm.ee ⁨1⁩ ⁨year⁩ ago
    I’ve used it the last few years to do Advent of Code (adventofcode.com) and that’s been fun and challenging. Definitely recommend it. Better than trolling through a book of “now do this” examples if you’ve done other languages in the past.
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    I know that the “project” approach to learning a language works for some people, but I’ve found l greatly prefer to read a book from beginning to end before undertaking any projects. It helps me start out with a clear picture. I’m finding “Comprehensive Rust” to be fairly good so far. Thanks for all the help, everyone.
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Thanks, I was looking for a more straightforward academic-style textbook for non-beginning programmers, but I’ll make do with what is out there.
    
    source
    -> View More Comments
Tanoh@lemmy.world ⁨1⁩ ⁨year⁩ ago

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!

source
- sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
  The GC in Go is fantastic IMO since it runs in a separate thread. I used it since 1.0 (switched our product from node.js), and dealt with all the the pain of an imprecise GC (fixed in 1.5?) and all the little improvements to arrive at it’s current state.
  
  The main issues I have with it are pretty core to the language, unfortunately, such as:
  
  interface{} is basically a void*, but since it’s a fat pointer, it can hold nil without itself being nil, which can happen by accident
  
  runtime reflection is a bad habit, but it’s unfortunately really common
  
  it’s really easy to deadlock by making stupid mistakes; if it had automatic unlocking based on scope (like Rust, or something like Python’s context managers), we could solve this, but defer just isn’t good enough
  
  no destructors - with destructors, we could build a solution to deadlocks
  
  Maybe they fixed some of those issues, idk, I haven’t used it for several years.
  
  source
  - Orygin@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
    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
    
    source
    sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
    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.
    
    source
    -> View More Comments
- 0x0@programming.dev ⁨1⁩ ⁨year⁩ ago
  
  the close tie to Google.
  
  Guess who’s one of the rounders of the Rust Foundation…
  
  source
- solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
  True about Google ;). Yes, there are programs that really don’t want GC. I consider those to mostly be niche applications since most of us are fine with using e.g. Python, which has automatic storage management (won’t quibble about whether it is GC per se) that has occasional pauses. SImilarly, tons of important programs are written in Java, which is GC’d. Of course Java is tied up with Oracle just like Go is tied up with Google.
  
  Go’s main problem from what I can tell is that the language itself is too old fashioned. I’ve used it but am not expert. It feels like an improved version of C, rather than a modern, type-safe language.
  
  source
asdfasdfasdf@lemmy.world ⁨1⁩ ⁨year⁩ ago
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.
source
- solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
  Interesting point about Wasm if that is important. You can also compile C++ to wasm but then its C++ ;). I don’t know about Ada to Wasm.
  
  I don’t think Rust is quite mainstream yet either. My impression is that its type system has not caught up with Haskell’s except in a few areas, but of course nobody pretends Haskell is mainstream. I haven’t yet tried Idris.
  
  Golang seems to have a decent runtime model (lightweight threads, GC) though the language itself is underpowered. There is a Golang backend for Purescript that sounded interesting to me. The thing that turned me off the most about Purescript was the JS tooling. Purescript (purescript.org) is/was a Haskell-like language that transpiles to JS, intended for use in browsers, but Typescript filled this space before Purescript got much traction. That felt unfortunate to me.
  
  I don’t think HLL (high level language) has an official definition, but informally to me it has generally meant that the language is GC’d and that the native integer type is unbounded (bignum). By that standard, Rust and Ada are low level. I’ve so far thought of Rust as a modernized Ada with curly braces and more control of dynamic memory reclamation. Maybe there is more going on than that. Ada is still ahead of Rust in some ways, like generic packages, but Rust is working on that.
  
  If you have a suggestion of a no-nonsense Rust book, I’d be interested in looking at it. doc.rust-lang.org/book/ beat around the bush way too long before discussing the language, but I guess I should spend more time with it.
  
  source
  - asdfasdfasdf@lemmy.world ⁨1⁩ ⁨year⁩ ago
    I’d say Rust is definitely mainstream. Obviously not the level of JS or Python, but it’s being used all over the place. All major FAANG companies, the Linux kernel, JS runtimes, web browsers, Signal…
    
    IMO GC has nothing to do with high or low level. It’s just incidental that there’s a correlation. In GC you usually don’t need to think about manually allocating or deallocating memory or truly understand what pointers are (in some ways anyway). In C / C++ you do.
    
    In Rust you almost never manually allocate or deallocate, and you have both very high and low level APIs.
    
    I’d say Rust is both high and low level. It just depends what you use it for.
    
    As for books, maybe you’d like trying Rustlings instead.
    
    source
    Hexarei@programming.dev ⁨1⁩ ⁨year⁩ ago
    
    rust is both high and low level
    
    I like to describe this as “low level language with high level ergonomics”
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Thanks, Rustlings doesn’t sound like what I want either. I was hoping for a counterpart of Stroustrup’s C++ Reference Manual, or Riehle’s “Ada Distilled” or even K&R’s book on C. Something that systematically describes the language rather than distractions like the toolchain, mini projects, cutesey analogies, etc. I’m being too persnickity though, mostly because it hasn’t been important to me so far.
    
    source
    -> View More Comments
artificialfish@programming.dev ⁨1⁩ ⁨year⁩ ago
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.

source
- solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
  I had the impression Rust doesn’t handle concurrency particularly well, at least no better than Python, which does it badly (i.e. with colored functions). Golang, Erlang/Elixir, and GHC (Haskell) are way better in that regard, though they each have their own issues. I had believed for a while that Purescript targeting the Erlang VM and with all the JS tooling extirpated might be the answer, but that was just a pipe dream and I don’t know if it was really workable.
  
  source
  - artificialfish@programming.dev ⁨1⁩ ⁨year⁩ ago
    I don’t know but I don’t think rust has that problem. In fact I’ve always thought its data ownership paradigm is literally the most optimal approach to concurrency and parallelism. I really love using rayon in rust for instance.
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    True, but of course it’s always a trade-off. At a certain point I have to defer to your judgment, at least until I’ve written some Rust code. But I’ve written a fair amount of C++ and a little bit of Ada and don’t find them all that convenient compared to Python or Haskell or whatever. We’ll see. ;)
    
    source
    -> View More Comments
  - jimmux@programming.dev ⁨1⁩ ⁨year⁩ ago
    
    Purescript targeting the Erlang VM
    
    Have you tried Gleam?
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    No I haven’t, I’ll take a look at it, though I felt suspicious of “task.async” as shown on the front page of gleam.run.
    
    source
  - Solemarc@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Rust makes multi threading very easy you can just use
    
    thread::spawn();
    
    But rust makes Async difficult because it’s naturally stackless so you need to create your own scheduler or use someone else’s like Tokio. Also, people have a bad habit of conflating async with concurrency which makes it more confusing.
    
    source
    solrize@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Sure you can spawn threads but now you have all the hazards of shared memory and locks, giving the 2.0 version of aliasing errors and use-after-free bugs. Also, those are POSIX threads, which are quite heavyweight compared to the in-process multitasking of Golang etc. So I would say that’s not really an answer.
    
    source
    -> View More Comments