Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T
Posts
0
Comments
458
Joined
3 yr. ago

  • This doesn't represent the mutual exclusivity through the type system (which is what the article is all about).

    I love clap and I use it a lot, but the only way to represent the exclusivity through the type system in Rust is through an enum.

  • I like the concept, and it's great in TS. Unfortunately, not as doable in other languages.

    I'm a bit curious if it's possible to extend clap to do this in Rust though (specifically mutually-exclusive arg groups).

  • That's not an alternative, it's removing let-else entirely. It's equivalent to this:

     rs
        
    let i = if let Some(i) = opt_number {
        i
    } else {
        return 0;
    };
    
      

    let-else is specifically a feature that allows you to use a refutable pattern to deconstruct a value by providing a diverging else branch.

  • Their suggested replacement is closer to C#'s is keyword:

     rs
        
    if foo is Some(foo) {
        // ...
    }
    
      

    The issue here is that we still have let-else, which can't be translated as easily:

     rs
        
    let Some(foo) = foo else {
        todo!();
    };
    
      
  • Or both? Functional languages are good to be familiar with, but so is Rust's strict ownership model. Both lead to better code in all languages.

  • Next.js is a highly opinionated framework. "Our way or the highway" is what should be expected going in. Good luck if your requirements change later on, and I hope your code is transferrable to a new framework if needed.

    Unfortunately, I have never need to follow "our way" because my projects are more complex than whatever basic blog setup they document. I always end up just building my own stack around Vite. I'm also not much of a fan of fighting against my tools when what I need isn't something the tool devs already thought of.

  • I completely forgot that unit structs/variants define their own associated consts. I wonder if in patterns the type can be used instead of the associated const though? That might resolve a lot of the headache. It'd mean changing the way the ident is resolved to looking in the type namespace though.

    const <block> already works as a pattern I believe? That could be used instead for constants.

    Literals would always work in-place as constant expressions.

  • Interesting perspective. Not sure I agree with most of the suggestions though.

    Some of the earlier ones remind me of C#'s records. Were they inspired from them?

    Some of the later ones just feel like Go to me.

    I like the idea of dropping syntax for ranges. It does feel like the syntax just leads to confusion.

    Named parameters are problematic because of parameter names becoming significant to the API. See Python's * and / in parameter lists (like def foo(a, *, b) for example).

  • This. It's just like "this dude is cool" and some fun Q&A and circlejerking, which is fine, but he probably should not be used as a credible source for understanding younger stuff.

  • Nah I ignored that because responding with just a number is boring and leads to no real discussion. A poll would have been better if that's what was needed.

  • As in using consts (or variables you think are consts) as refutable patterns? Yeah this was an oversight I'm sure.

    One option is an edition change requiring a const keyword, so

     rs
        
    match foo {
        const BAR => {},
        baz => {},
    }
    
      

    Right now they use a lint to try to warn the dev though.

  • For programming languages? I don't need many features as long as what exists is enough to do everything I need. In fact, the less, the better (or you end up with C++'s regex/Python's urllibN/etc).

    I guess that means that I'd end up more on the documentation side, though my reason isn't because I want the most documented language of all time, but because I want the fewest built-in features.

    This is why I mostly write Rust when given the option. I write a lot of Python, but I hate the standard library so much. There's the urllib stuff, plus there's a bunch of deprecated stuff in the base64 module, plus I can't stand Python's implementation of async (coroutines are cool but asyncio is miserable to use imo).

    Edit: Oh, and nobody's giving integers only when nuanced answers are more interesting to discuss.

  • conda isn't much of an alternative to pip. It's more of an alternative to venv. Unless you're referring to conda's dependency management, which I've admittedly never used.

    And until pip uninstall foo uninstalls unused transitive dependencies too, you'll have to drag me back.

  • uv is love. uv is life.

    I'm still trying to get people at work to use it. It's one of the few tools out there that takes Python from intolerable spaghetti to readable and maintainable.

  • It would be convenient to be able to clone the task management repository alongside the code repository, too.

    FYI it's entirely possible to track multiple branches with unrelated histories in git. Both the task management and code can live in the same repository.

    You could theoretically even give each task an ID, then tag commits in the code that complete those tasks with those task IDs.

    This gives me some ideas for how it could be done that might be fun to explore. It comes with the benefit of not being platform-specific (GitHub/GitLab/etc). Merge conflicts might be annoying, but maybe there's a way to take advantage of Git's tree to represent relationships between tasks, and have one "HEAD" commit (or branch or other ref) per task? Not sure how this will work honestly.

  • Though in some contexts, I might prefer a name like employeeToRole for a Map<Employee, Role> over the article's employeeRoles.

    Following the article, the former describes the type (a map from employees to roles) while the latter describes the relationship (these are the employees' roles).

    At the same time, I'm not pedantic enough to care in practice. Both are fine, and I'll get the point when I read either of those.

    I agree with the author here that names don't need to be so verbose, but I also think there needs to be a balance. out or req or res are clear with context, but output, request, and response are always clear and not bad to write. http_response adds extra unnecessary info (unless there's another response variable in scope).

    It also helps when languages support local variable shadowing. For example:

     rs
        
    let response = foo();
    let response = validate_response(response);
    
      

    Both of these are responses, and fundamentally the same thing being passed around while being mutated. The types are (potentially) different. You won't use the first variable ever again (and in Rust, likely can't). Just reuse the name.

  • In this case, it seems like a feature.

    It does make me wonder why not use a bounded channel instead (assuming these tasks are shared between threads, maybe because it's multi-consumer?) but a deque is more flexible if that flexibility is needed.

    Personally, I can think of a use for this myself. I have a project where I'm queuing audio to play in the background, and using this kind of deque for the queue would work here as well (though I use a bounded channel currently).

    There are also a lot of times when i've wanted a stack-only data structure to avoid allocations where these can theoretically come in.

  • A pretty good way to get a code review is to post the code on GitHub and make a post advertising it as a tool everyone needs. People will be quick to review it.

    As far as LLMs go, they tend to be too quick to please you. It might be better to ask it to generate code that does something similar to what you're doing, then compare the two to see if you learn anything from it or if it does something in a better way than how your code does it.