142
'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman (www.zdnet.com)
submitted 3 months ago by to c/rust@programming.dev
63 comments fedilink hide all child comments

all 63 comments

sorted by: hot top controversial new old
[–] 55 points 3 months ago (2 children)

This is what most people who complain about Rust rewrites don't get. It's not just about memory safety and some new language features. Rust simply did a lot of things right and is nice to work with. New developers actually join Rust projects while old tools written in C struggle to survive.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 13 points 3 months ago* (last edited 1 month ago)

    Yeah, I enjoyed when fish shell did their rewrite and people were arguing whether it makes sense technologically, like it's a mature codebase, so it's not likely to reduce the number of bugs and yadda yadda yadda.

    None of this mattered, because fish is developed by a group of hobbyists. They didn't want to continue developing in C++, because it was a pain in the ass. And for sure, one of the reasons they wanted to switch to Rust is because it's new and exciting.
    These reasons are perfectly valid, because they're volunteers. If they're not having fun, then they will just stop developing.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 14 points 3 months ago* (26 children)

    I'm actually looking into learning zig. The deal is that I don't really have an use case for it. My work vastly prioritizes development speed over actually fast programs

  • permalink
  • fedilink
  • source
  • hideshow 26 child comments
    •
  • [–] [S] 7 points 3 months ago (24 children)

    Why are you considering Zig instead of Rust? Or is it in addition?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 24 child comments
    •
  • [–] 5 points 3 months ago (8 children)

    Arguably Zig has a simpler approach to memory management (which can also lead to more errors, arguably) which makes the transition from C somewhat easier. Downside is that the language is still under heavy development and you definitely have to be up for the ride.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] [S] 5 points 3 months ago (7 children)

    Agreed that it makes the transition from C easier, but I'd also say it makes the transition from C more pointless. I don't really know that much about Zig but from what I've heard, I don't really get the benefits - if you want a fast systems-level language without guard rails, why aren't you just writing C (or C++, if that's your thing)?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 4 points 3 months ago (2 children)

    Zig is way better than C in many other respects, so if you want a modern sane language and you're either a Rust luddite or working on a project where memory safety isn't that important, it might be attractive.

    Like, if the choice is C or Zig, then Zig is pretty much a no-brainer (or it will be when it hits 1.0). It just fixes so many insane things about C that have been broken for literal decades.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 2 points 3 months ago (1 child)

    working on a project where memory safety isn’t that important

    I can't really imagine anything where this is not the case, unless you're doing like... I dunno, small scripts for personal use or something? But why would you use Zig or C or even Rust for that, just do Python or even bash at that point? Python is memory safe and perfectly suitable for very small programs where static analysis gives little benefit.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 3 months ago

    There are definitely some cases where memory safety isn't especially important:

    • Single player games
    • Apps that don't process external data (e.g. a simple calculator).
    • Lots of things running on microcontrollers, where the form of input could never possibly cause any security issues. E.g. a motor controller or a basic syringe pump or a (non-smart) washing machine or something.
    • Tests, e.g. I've considered writing RISC-V tests in Zig. They're traditionally written in C or assembly.

    In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn't say it's as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.

    I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it's at least a defensible choice.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 months ago (3 children)

    zig does have guard rails, they're just different approaches. zig defaults to optional types where null must be handled. and memory safety is checked through unit testing and exposing debugger memory allocators that check for different memory corruption bugs.

    rust takes a shift left approach where all declarations drive safety whereas zig takes a more laid back shift right where it's expected you'll have written tests. rust will force all developers to conform to produce good code where zig requires a bit more though, i mean every dev writes test cases right?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 3 months ago (1 child)

    Saying that "memory safety is checked by tests" is basically saying "memory safety is not checked". Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren't buggy?

    Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?

    I also don't understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it's never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any unsafe usage, obviously).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 3 months ago

    in c code you will see malloc, alloc, free w/e scattered through the code base, most static tools lack because they don't control the memory and just analyze address spaces or do static code analysis. they look top down and try to catch errors.

    zig's design forces you to create a memory allocator before any object initializations (alloc/free) and is typically constructed at the top level and passed through to functions. this allows you to swap implementation easily and use the allocator to claim memory or return an error to the caller if it can't.

    you can do some simple static allocator, general purpose allocator (can grow memory space as you allocate more objects) or in this case to test memory safety a debug allocator which you use in your tests. This moves the memory inspection inside of where your program allocates memory. this is more of an inside out approach where the analysis is produced by controlling the memory allocations and frees through a standard interface.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 months ago (11 children)

    i like the way zig interfaces with c. even though it's a "newer" (not 1.0) language you can import native c which means you have access to already really fast libraries. the build script and macros are the same language you write your code. the best part is you can interface with normal code (not unsafe) and can create boundaries where sure in the c side you can't enforce memory safety, but where you interface you can convert into memory safe types.

    to talk more about memory safety i think rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app whereas zig you could gracefully handle it. this is probably more important for lower level things like kernel than an app where not recovering means everything goes down.

    honestly i wish there was an opt in borrow checker as some patterns are easily expressed, but honestly i would opt out for async code as it just gets verbosely over-declarative imo. also the new async in zig is really really cool.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 2 points 3 months ago (9 children)

    You can trivially use C libraries in Rust, or any system language that supports the C ABI for that matter, and this includes many hobbyist languages. Zig is not special.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 3 points 3 months ago (2 children)

    No Zig definitely is special. You don't have to do any extra busy work to call C code - you can pretty much just #include the header and that's that. It's similar to calling C from C++.

    In any other languages - including Rust - you have to do some work declaring functions, wrapping them and so on. It's not hard but it definitely is a non-zero amount of tedious work (especially before AI). There's absolutely no way you could describe it as "trivial", unless someone else has already done that work for you.

    But I don't think it is a significant Zig advantage really. When I'm writing Rust, it's extremely rare that I want to call any C code that someone else hasn't already done the tedious wrapping for.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago (5 children)

    zig is a bit special in this regard though as it is a c compiler not just using ffi. this means you could swap out gcc, make autotools etc and drop in zig with a build.zig. mostly useful if you want to migrate large code bases as you can incrementally port the parts you want.

    if you're picking it up for a new project then yeah this probably doesn't impact you much.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 3 months ago (4 children)

    a c compiler not just using ffi.

    Beyond what amounts to a packaging difference, what does that even mean?

    How do you think zero-cost C ABI support (including fully working cross-lang LTO) works in lang implementations that have that? And how do you think that's different from what Zig gives you?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 months ago (3 children)

    from rust docs:

    Note: “Zero-cost” means zero runtime cost, not zero compile cost. The compiler does real work — monomorphization and inlining — to make abstractions disappear, and that work shows up as longer build times. See Reducing Compile Time for the trade-off.

    most of the benefits come from a shared code base, one compiler (which is insanely fast with incremental rebuilds and can watch files for changes) means changes in the c code reflect in a single build step within seconds. the benefit is primarily for the developer as the compiler output should be relatively similar.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] -1 points 3 months ago (2 children)

    That has nothing to do with what we were talking about. And in any case:

    insanely fast

    Needs qualification vs. other languages for binaries with comparable runtime performance.

    (Hint: you will be surprised.)

    with incremental rebuilds

    Not special or unique.

    and can watch files for changes

    Not only not special, but literally exists in all workable build tools. bindgen+build.rs is the Rust version of this.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago (1 child)

    I'm not sure what you're talking about then, in zigs case you don't need an exposed ABI to use existing c code?

    in terms of performance it will always be ambiguous as implementations are hard to compare across languages, however they use llvm as an alternative to support architectures as they build out their native compiler. in the transition for x86_64 they were seeing up to 70% increase in compile speeds. its still ambiguous as its dependent on their implementation of llvm, though its such a large increase it is still meaningful.

    but i say all this as a rust and zig advocate where i would happily choose either over the the majority of alternatives.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 months ago

    exposed ABI

    ABI is not something that gets "exposed" or not.

    it will always be ambiguous as implementations are hard to compare across languages

    Correct.

    in the transition for x86_64 they were seeing up to 70% increase in compile speeds

    And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 1 point 3 months ago*

    rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app

    That is not an "inconsistency". Crashing the application when you run out of memory is honestly in almost all cases the correct call and crashing is memory safe. Most applications can do absolutely nothing when running out of memory. "Handling" OOM is extremely complicated and most applications simply cannot handle it in any way.

    Of course low level stuff needs to sometimes actually handle this, but it's mostly an operating system thing. And Rust still allows you that control, it's just not the default behavior of the collections and such in the standard library, because again, it almost never makes sense to try to handle OOM. But if you really need that behavior, you can have it.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 12 points 3 months ago

    Memory safety is hard to ignore.

  • permalink
  • fedilink
  • source
    •
    [–] 16 points 3 months ago

    GKH is to me the second most important guy in the Linux world today next to LT, and he definitely deserves more credit for his efforts maintaining the kernel. Maybe Greg doesn't get as much press attention because he doesn't make as profound statments as Linus tends to.

  • permalink
  • fedilink
  • source
    •
    [–] 27 points 3 months ago (15 children)

    Look, undeniably some coding languages are miles better than others, but I don't think any of them would fall under my personal classification of what the word "fun" means...

  • permalink
  • fedilink
  • source
  • hideshow 15 child comments
    •
  • [–] 52 points 3 months ago (4 children)

    Different strokes I guess. Personally, I do have a good time writing Rust and fun feels like the right word

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 24 points 3 months ago*

    Yeah, same. The fact I can chill the fuck out and basically not have to worry about an enormous class of serious, hard-to-spot bugs makes it a lot more fun for lower-level programming.

    Like, yeah, I still need to worry about obstacles like other drivers, animals, etc., but it's a lot more fun driving on a road that isn't completely teeming with potholes and black ice.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 12 points 3 months ago (2 children)

    Yup. I come from a mostly embedded C or C++ background with a constant 10% Python for assorted scripts. Rust feels pretty great, basically all the things I like about all of those languages with fewer of the annoyances. And cargo and clippy are fantastic. My biggest annoyance is remembering which of the approximately 213 Result/Option chain handlers I should use in a given situation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 3 months ago (1 child)

    Thanks for naming my biggest problem with writing rust code. Every crate has it's own particular Result chain, doesn't it. To the point we have anyhow and eyre to help with this mess.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 3 months ago* (last edited 3 months ago)

    My current solution is usually to just make a bunch of stupid match statements and fix whatever clippy complains about. Then if any remain be sure to “accidentally“ tag the friendliest rust expert I know on the PR and see if they say anything.

    edit: They usually say something like, “you could replace those matches with a and_else, map_err, unwrap_or, and_then? and a filter_map.”

  • permalink
  • fedilink
  • source
  • parent
  • [–] 14 points 3 months ago

    Fun is when you're allowed to achieve what you want to achieve with less bullshit to worry about.

    Or in more respectable technical terms, when you're allowed to focus on core logic above everything else.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 3 months ago*

    It was fun when knowing programming was almost a superpower that you had to learn by reading lots of books, etc. Now a computer can do much of the job. The computers are even solving long-open Erdos problems. We're all just mediocre meatbags.

  • permalink
  • fedilink
  • source
  • parent
  • [–] -2 points 3 months ago (7 children)

    Except for C

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 0 points 3 months ago (6 children)

    C is firmly in the "not fun" camp with PHP, JavaScript and Bash. I'd say even assembly is more fun, in a puzzle challenge sort of way.

    The most fun language I've used is QuakeC, because the only thing you can do with it is write Quake mods. It was a pretty neat language too from what I remember. It even automatically detected infinite loops!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 3 months ago* (5 children)

    We all have different definitions of "fun." C won't surprise you when you try to add a string and an array; it'll do exactly what you told it to do, which then translates to assembly code with a very predictable pattern.

    On a different note, bash scripting is well-defined and mostly consists of understanding that common tools can be chained together to provide useful output; combined with the very well-defined string operations, I've found that bash scripts can address over 99% of cases people try to throw sed and awk at. It's almost surprisingly powerful.

    JavaScript is just a hot fucking mess.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 3 months ago (3 children)

    C won’t surprise you...

    Lol... I'm sure there's a meme or graph for where you are in learning C to believe this.

    then translates to assembly code with a very predictable pattern.

    Even this is a stretch. Modern C compilers can do some wild transformations. I assume you've seen the classic one where UB makes it jump to a function that you never actually call.

    bash scripting is well-defined

    Yeah I mean Bash's problem isn't that it's poorly defined - it's that the definition is awful!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 0 points 3 months ago (2 children)

    I've been programming for 35 years, and professionally for over 20, so I'm pretty far along the curve, thanks.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • [+] -30 points 3 months ago (14 children)

    Isn't also half the point behind Rust the ability to evade the GPL and make Linux more vulnerable to takeover by corporate? Last I checked Ubuntu is replacing some GNU stuff like coreutils with Rust.

  • permalink
  • fedilink
  • source
  • hideshow 14 child comments
    •
  • [–] 42 points 3 months ago (5 children)

    are you claiming that a program written in rust evades thr gpl? thats not a thing.

    or...

    are you saying , things are being rewritten (regardless of language) with a different license. scary but not a rust thing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 8 points 3 months ago (4 children)

    The second.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 3 months ago (3 children)

    Do you seriously think that's how IP law works? If you weren't able to write GPL Rust code, Rust would not be free software. That would require the Rust project to issue software licences to programmers that stipulate that you must not create GPL-licensed software using Rust.

    Rust is free and open-source, like most programming languages. That means you are allowed to make whatever software you want with it, including GPL software. There's nothing stipulating that you can't...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 months ago (2 children)

    You can write GPL rust code, you can also write non-gpl rust code. Gnu coreutils are gpl, if I choose to write functionality compatible with coreutils from scratch in rust I can relicense that as I please (ie not GPL) OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago

    OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

    And that postulation is extra laughable because non-GPL coreutils implementations always existed. And by always, I mean they actually predate the GNU implementation itself (which was a originally a "rewrite" btw 😉).

    And yes, they don't target GNU compatibility, but some of them are perfectly serviceable as is (e.g. the freebsd ones), and adding GNU compat to them would have been infinitely easier than starting a Rust implementation from scratch anyway.

    Another laughable aspect regarding the coreutils/uutils case in particular is that uutils didn't even start as a corpo-driven or corpo-backed project. It was literally a Mozilla employee having fun in his free time, especially during Covid, and community contributions in the same vein. Rewrites of non-GPL projects (e.g. sudo) were ironically much better backed.

    From my experience here and elsewhere, the people who make such stipulations don't even know which licenses the core packages in their own systems adopt. Many of them don't even know what these licenses' provisions precisely entail. They just perpetuate some retarded circlejerk probably started by some clueless+malicious e-celeb that goes like:

    linux distro -> C -> gpl -> not corpo -> good
    rust -> not gpl -> corpo -> bad

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 months ago

    I mean, you can create a GPL fork of the Rust coreutils if you so please. Or you could do a rewrite in any programming language of your choice and license permissively.

    In any case, I profoundly cannot bring myself to care about the fact that you can legally create a proprietary fork of permissively licensed FOSS. I don't think it's right to impose any restrictions on what people can do with software/code, which of course conflicts with the fact that other people can take your code and restrict what other people can do with it. So choosing between copyleft and permissive licensing is a balancing act of that contradiction. I don't think it's wrong to end up on the side of permissive licensing.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 22 points 3 months ago (5 children)

    Yes, that's correct. Whenever you write something in Rust, the license is automatically permissive. In fact, both US and EU copyright law automatically grant an irrevocable, perpetual license to use any and all Rust code that has ever been written for any purpose at all, including for commercial purpose, unless the code was written by a corporation.

    Or, you know, you could just:

    [package]
license = "GPL-3.0-only"
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 20 points 3 months ago

    To be fair, projects implemented in Rust and adopting the GPL/AGPL are just not that notable.

    I mean, you can't expect people here to have heard of, let's say, that thing called Lemmy.

  • permalink
  • fedilink
  • source
  • parent
  • [–] -4 points 3 months ago (3 children)

    Now that would be a horror story. Then again, it's one of the reasons why I'm asking. Rust fame is just too coincidental with a number of things to not be suspicious. There was a whole thing in C++ (dunno if it's still ongoing) about the "memory safety" meme, as well.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 7 points 3 months ago (1 child)

    I feel ya. To me, it's really sad that some new projects now use licenses that are really good for businesses but do not even protect the projects themselves. I'd rather live in a world where GPL share would increase. (Instead, GPL grows, but its share is diminishing.) All my projects so far are GPL/AGPL.

    At the same time, Rust being picked for Linux has really nothing to do with the license. It's just what you said - a coincidence. The actual choice is made because of the language itself. It's a great language BTW.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 3 months ago

    Since you seem to be in good faith: no, you’re wrong. Using a language cannot force you into adopting a licence, because automatically everything you produce will be all rights reserved unless otherwise specified. It’s then up to the developer to choose a license.

    Rust doesn’t even populate the license metadata in your manifest, it’s up to you.

    I think MIT dominance came about thanks to GitHub’s choose a license.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 34 points 3 months ago
    • Linux kernel code is GPLv2 licensed irrespective of language.
    • There are thousands of (A)GPL rust crates/libraries out there.
    • The majority of crates are indeed still liberally licensed, but so are most new projects from the last decade, irrespective of the choice of implementation language.
    • Rust project rewrites don't exclusively replace GPL projects, because there aren't actually that many core GPL software packages to replace. Neither sudo nor zlib are GPL software, just to give two examples. A lot of implemented-in-C core packages in your system right now are actually liberally licensed.
    • And just for the sake of accuracy, the supposed threat of liberal vs. copyleft is not about the so called corporate take over or control. It's about the ability to have proprietary forks/spin-offs. Plenty of GPL projects are corporate-controlled and always have been (see what projects Red Hat maintains).

    You should try properly educating yourself on matters, instead of just taking whatever bullshit random often-clueless if not also malicious e-celebs spout at face value, or wherever you're getting these retarded theories from.

  • permalink
  • fedilink
  • source
  • parent
    • 20 comments in c/linux@programming.dev view that post
    [–] 18 points 3 months ago

    C was "fun" once. Hell, C is becoming so obscure, it's fun again!

  • permalink
  • fedilink
  • source
    •
    [–] 33 points 3 months ago

    "Programming is fun again"

  • permalink
  • fedilink
  • source
    •
    [–] 8 points 3 months ago (9 children)

    If anyone has some insight: is Rust more or less verbose than C, generally? Like if Linux would be rewritten in Rust, would the LOC increase or decrease, e.g.?

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 12 points 3 months ago (1 child)

    Rust has a lot more 'batteries included' than C, and the memory ownership model works a lot better than garbage collection or C's YOLO model. It also has built-in async/await. But you're pretty much in the same boat as C when it comes to multiprocessing or thread-safety.

    Anyone building a long-running backend service would be wise to take a serious look at Rust. Personally, I'm glad Linus is open to change and isn't digging his heels in on this one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 21 points 3 months ago (6 children)

    It's easier than C, it's safer than C, the compiler is more helpful than GCC

    I think it's fun

    Less verbose? I don't think so

    Lines of code about the same

    For someone starting out as a programmer for low level programming I would recommend rust

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 3 points 3 months ago (5 children)

    For the same purpose, would you recommend Rust over Zig?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 13 points 3 months ago (2 children)

    As someone who has used both (but not for any serious, large projects), I'd say they target different audiences. First and foremost, Zig is not memory-safe in the way Rust is. On the other hand, Zig is way easier to write than unsafe Rust. Rust comes with a lot of features and libraries, while Zig is an intentionally small language, almost minimalistic (kind of like C, but modern).

    There are lots of different tradeoffs being made, so yes, I'll give the boring answer and say they are good for different kinds of projects :)

    If it's specifically low level programming (I'm envisioning programs where you need fairly direct control over memory, IO, etc.), you'd probably quickly need a lot of unsafe in Rust, which can quickly get very complicated to use safely. So I'd probably recommend Zig for that purpose.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • [–] 3 points 3 months ago

    Rust indeed has good features I enjoy having them. But the joy I can have in Lisp, I cannot have in other traditional(or ordinary?) languages. I've developed an ML backend with Rust over 3 years to learn that for algorithm research and testing, Lisp ecosystem is much better than Rust. But I haven't done the research yet to see if there is a Lisp other than CL which is performant enough. Because CL is quite obscure and has self contradicting features, thus not mature.

  • permalink
  • fedilink
  • source
    •
    [+] -12 points 3 months ago (4 children)

    Fun because you like rewriting existing code?

    Fun because you already have test suites you don't have to rewrite?

    Fun because you feel morally superior by writing fresh code, even though the old code is running critical applications in production?

    Fun because you think your smarter than the engineers that lay the ground work before you?

    Fun because you like hunting bugs you created thinking you know better, while calling your rewrite superior.

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 5 points 3 months ago (1 child)

    Imagine taking someone else's joy THIS personally...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 3 months ago*

    I think it's more to do with, are you really examining your feelings and understanding where they are coming from? Working with something new, that puts you back in the place of having to learn stuff again, is often enjoyable, not because of the thing you are using, but because it's new and your brain, despite what people think, likes learning new things.

    I'm glad people feel like they are having fun with rust. But the Rewrite it in Rust crowd are just creating more work for the sake of it.

    And I'm a fan of rust.

    But hey ho, if they want to spend their time recreating stuff we have excellent options for, who am I to stop them. I just think there are better things they could spend their time on.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 months ago* (last edited 3 months ago)

    Fun because you like rewriting existing code?

    Rust4Linux is not a "rewriting" endeavor.

    Fun because you already have test suites you don’t have to rewrite?

    See previous point.

    Fun because you feel morally superior by writing fresh code, even though the old code is running critical applications in production?

    Can you point to where "moral superiority" was used as a reason for using Rust in the Linux kernel?

    Can you point to an example where Rust code in the kernel caused breakage in "critical applications in production"?

    Bonus: Do you think "critical applications" closely follow mainline?

    Fun because you think your smarter than the engineers that lay the ground work before you?

    Who were the engineers that came before Greg Kroah-Hartman?

    What ground work exactly are you referring to?

    How does Rust code in the kernel relates to this?

    Fun because you like hunting bugs you created thinking you know better, while calling your rewrite superior.

    Better than whom?

    What rewrite?

    Where was it stated that the fun was in hunting more bugs?

    Bonus: Do I actually prefer it if someone other than the original coder is hunting bugs?

    And to finish with a meta question:
    Why the likes of you feel the need to share opinions based on fictional events regarding matters your clearly completely clueless about?

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 3 months ago*

    yes all of those things are true

    you catch on quick. also we extend test suites and our coding style is adopted by C coders because of its god-like superiority

    it's fun watching rust succeed over bad old C everywhere it is used isn't it?

    HIGH FIVE

  • permalink
  • fedilink
  • source
  • parent