• 6 Posts
  • 930 Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle

  • I really don’t agree with saving keypresses being a useful metric, since auto-completion is a thing and code is read significantly more often than it is written. I am also a staunch opponent of abbreviations being used for variable names.

    But I will say that I don’t mind abbreviations in keywords, since well, you need to learn the meaning either way.
    And yeah, I’ve come to somewhat like them being used for keywords, since it reduces visual noise where it really isn’t useful, and it distinguishes keywords from actual code.
    Ultimately, keywords are just syntax where letters were used instead of a symbol. You do read them like a symbol, so if they don’t look like a real word, that seems to work quite well for my brain.



  • I’m not sure, what you mean by “Chekhov’s footgun”, but well, it isn’t a footgun, so you won’t accidentally return a wrong value from the function, if that’s what you’re thinking.

    It’s not a Rust invention, most functional programming languages have implicit returns, but basically think less of them as a function return and more just as the value that a scope evaluates to.

    So, here’s a simple example:

    let sum = {
        let x = 5 + 9;
        3 * x
    };
    

    Obviously, this is an extremely contrived example, but yeah, as you can see, it does not even have to involve a function. The implicit return makes it so that sum is set to the result from 3 * x.
    And the scope-braces are nice here, because you can do intermediate steps without having x in scope for the rest of your function.

    In practice, if you see scope-braces and the line at the end does not have a semicolon, then that’s the value that the whole scope evaluates to. Those scope-braces can also be the braces of a function, but then you need to annotate what the function is going to return, too, so it’s practically impossible to return a wrong value.

    Well, and I would actually argue that explicit returns are a footgun in comparison.
    Because someone might introduce clean-up code at the end of the function and not realize that an explicit return skips that clean-up code, somewhere further up in the function.
    The implicit return always has to be at the end of the scope, so it’s not possible to accidentally skip code.


  • That is, like, genuinely an advantage, though. At $ DAYJOB, we have a project that spans embedded, backend, web frontend and CLI, and for all of these, Rust is decent.

    Like, I can see why a frontend dev would want to use HTML+CSS+JS/TS (rather than HTML+CSS+Rust), mainly because the massive ecosystem of JS components makes you more productive.

    But you pretty much won’t ever develop a web frontend without an accompanying backend, and then being able to use the same language-expertise, libraries, utility functions and model types, that is also a big boost to productivity, especially if you won’t have a dedicated frontend dev anyways.

    Realizing that also made me understand why people subject themselves to NodeJS for their backend, which has the same advantage, just with the big ecosystem in the frontend and the small ecosystem in the backend.




  • I know some of my programs used to have lines with just x.unwrap().unwrap().unwrap() or whatever, which is not pretty.

    That goes away with experience, though. At least, I can’t think of a reason why you’d nest three Results or Options. Normally, you would collate them right away.

    The most you see in the wild is something like Result<Option<_>> to express that a check can fail, but even if it doesn’t, then a valid result can still be that there is nothing there.

    If you don’t care that your program crashes (like .unwrap() does), then anyhow is the error handling library of choice. With it, you can just write a ? in place of an .unwrap() for practically any error type. And well, it automatically combines the errors, so you won’t be writing ??? either.


  • To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a bool, but rather the element that you removed, so like this:

    fn getofmylawn(lawn: Lawn) -> Option<Teenager> {
        lawn.remove()
    }
    

    And then with such a more complex return-type, C-style means that you can’t see the function name right away:

    Option<Teenager> getofmylawn(Lawn lawn) {
        return lawn.remove();
    }
    

    I also really don’t think, it’s a big deal to move your eyes to the ->


  • Yeah, I was gonna say, error handling easily makes up 80+% of the code paths, and depending on whether you’re building a library or service or script etc., different strategies are most suitable for how to deal with those code paths.

    In a script, you often just want it to crash. In a library, you want to make these code paths matchable, in case the user cares why something failed. And then you have the awkward in-between, which is that 99% of your application codebase will be used by your main-function like a library, but you don’t want to spend as much effort on error handling for that as a proper library does, in particular also because you know what all consumers of your application-library need to know.

    So, it’s kind of multiple different problems, with overlap, and people are hoping for one easy solution to cover all these problems.





  • To give a quick highlight, because this case is often politicized and misrepresented:

    The plaintiff, Stella Liebeck (1912–2004), a 79-year-old woman, purchased hot coffee from a McDonald’s restaurant, accidentally spilled it in her lap, and suffered third-degree burns in her pelvic region. She was hospitalized for eight days while undergoing skin grafting, followed by two years of medical treatment. […]

    Liebeck’s attorneys argued that, at 180–190 °F (82–88 °C), McDonald’s coffee was defective, and more likely to cause serious injury than coffee served at any other establishment.

    So, the lawsuit never demanded McDonald’s to put a warning that you’re not supposed to spill hot coffee on yourself. It argued that it’s an unnecessary safety hazard, because the coffee was served at hazardous temperatures.
    No matter how many warnings you put down, it can happen that someone spills coffee on themselves and they shouldn’t need to be hospitalized from that.


  • Ephera@lemmy.mltoAsklemmy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    4
    ·
    6 days ago

    I find it annoying, because the hype means that if you’re not building a solution that involves AI in some way, you practically can’t get funding. Many vital projects are being cancelled due to a lack of funding and tons of bullshit projects get spun up, where they just slap AI onto a problem for which the current generation of AI is entirely ill-suited.

    Basically, if you don’t care for building useful stuff, if you’re an opportunistic scammer, then the hype is fucking excellent. If you do care, then prepare for pain.



  • Ephera@lemmy.mltoMemes@sopuli.xyzTwo types
    link
    fedilink
    English
    arrow-up
    2
    ·
    7 days ago

    Yeah, I tried it in my other comment, and at first it started with “I think, folks…” which was already a dead end, because any continuation I tried would eventually need a “they”. Kind of wild that something as basic as plural can fuck you up. 😅