• 0 Posts
  • 576 Comments
Joined 2 years ago
cake
Cake day: September 2nd, 2023

help-circle
  • The C example is the wonderful happy path scenario that only manifests in dreams.

    Most projects don’t have a dependency list you can just install in a single apt command. Some of those dependencies might not be even available on your distro. Or there is only a non-compatible version available. Or you have to cast some incantation to make that dependency available.

    Then you have to set some random environment variables. And do a bunch of things that the maintainers see as obvious since they do it every day, so it’s barely documented.

    And once you have it installed, you go to run it but discover that the fantastic CLI arguments you found online that would do what you installed this program to do, are not available in your version since it’s too new and the entire CLI was reworked. And they removed the functionality you need since it was “bad practice and a messy way to do things”.

    All of this assuming the installation process is documented at all and it’s not a “just compile it, duh, you should know how to do it”.


  • Is there anything in the LLMs code preventing it from emitting copyrighted code? Nobody outside LLM companies know, but I’m willing to bet there isn’t.

    Therefore, LLMs DO emit copyrighted code. Due to them being trained on copyrighted code and the statistical nature of LLMs.

    Does the LLM tell its users that the code it outputted has copyright? I’m not aware of any instance of that happening. In fact, LLMs are probably programmed to not put a copyright header at the start of files, even if the code it “learnt” from had them. So in the literal sense, it is stripping the code of copyright notices.

    Does the justice system prosecute LLMs for outputting copyrighted code? No it doesn’t.

    I don’t know what definition you use for “strip X of copyright” but I’d say if you can copy something openly and nobody does anything against it, you are stripping it’s copyright.




  • Generally agree. Except:

    Logs that are a “debug diary” are not useless. Their purpose is to debug. That’s why there’s log levels. If you are not interested in that, filter by log levels above debug.

    Also, the different formats for fields I see as a necessary evil. Generally, more logs (of verbose log levels) = more good. Which means that there should be as frictionless to write as possible. Forcing a specific format just means that there will be less logs being written.

    The json (or any other consistent format) logs seem to be a good idea, but I would keep it to a single debug level (maybe info+error?). So if you want to get wide events, you filter by these log levels to get the full compact picture. But if you are following a debug log chain, it seems a pain to have to search for the “message” field on a potentially order-independent format instead of just reading the log.

    TL;DR

    Log levels have different purposes, and so they should have different requirements.





  • I don’t care about 10KB or even 100KB of disk space per installed program if it saves humanity the collective millions of hours wasted on .dll/.so issues.

    If your program needs libcirnfucb to run, it should be in the same directory as your program, and you are responsible for putting it there for me. No other program in my computer needs libcirnfucb, there’s no efficiency gains and now I have to go to some random website from the 90s and find where they put the damn download link and now I have to learn all about how libcirnfucb manages their versions and if I am in the correct webpage, because the project is abandonware that was formed 10 years ago and now it is in another 90s looking website that has a name completely unrelated to libcirnfucb.


  • In my case, I don’t usually encounter cases where I can’t just ?. But when I do, just make an error enum (kinda like thiserror) that encapsulates the possible errors + possibly adds more.

    On the call site, just convert to string if I don’t care about specifics (anyhow-style).

    I don’t find this much painful.

    Concise: not much on the declaration side, since you have to create an entire enum for each function in worst-case scenario. But on code side, it’s just .map_err(MyError)?.

    Type-safe: can’t beat errors as enum values wrapped in Result.

    Composable: i don’t think you can beat rust enums in composability.

    I don’t use anyhow/thiserror, so I’m not sure. But I believe thiserror fixes the conciseness issue for this.


  • Every day I have to open a VM as I turn on the computer. I could go find and open Virtual box, then select the VM and open it. Why would I do that when I can open the terminal and run a script that does that in a single action. Then I have to SSH into that machine that always has the same IP. Why should I have to type the IP every time?

    Scripts are good when used correctly. I don’t need to know what vboxmanage to run to do whatever I want, I just needed to search it once and remove it from my brain.

    Kinda unrelated but:

    I don’t think you should know how to do everything from the git CLI. For 99% of use cases, the IDE already knows how to do what you want to do, with a simple button. For the rest, just search for the git command when you need it.




  • In my team we manage 2 software components. 1 of them (A) has 2 devs, the other (B) approximately 5.

    Every time a feature needs to be added, B complains that it’s going to take forever, while A is done in a fraction of the time.

    The difference? B is a clusterfuck of a codebase that they have no time to refactor because they run low on time to implement the features.

    I work in A, but I’m not going to steal the credit, when I entered the company, A already had a much cleaner codebase. It’s not that me and my partner are 10x better than the ones working in B, they just have uglier code to deal with.

    I can’t comprehend why management doesn’t see the reason A needs half the devs to do the job faster.


  • “installing a library” should not exist as a concept. A library is either so essential that the OS needs it (and therefore it is already installed), or is not essential enough that each program can have its own copy of the library.

    “But I want all my 3 programs that use this random library to be updated at the same time in case a security flaw is found in it!” Is no excuse for the millions of hours wasted looking for missing dependencies or dependencies not available for your system. If that library does have a security vulnerability your package manager should just find your 3 programs that use it and update their copy of the library.



  • Rust allows you to choose whatever method you want.

    • Early return propagating the error
    • Early return ignoring the error (maybe by returning a default value)
    • Explicit handling by if-else (or match) to distinguish between error and not error cases.
    • Early return and turn the error into another type that is easier to handle by the caller.
    • Assume there is no error, and just panic if there is. (.unwrap)

    There are only 2 error handling methods that you cannot do:

    • Exceptions
    • Ignore the error and continue execution

    And that is because both of them are bad because they allow you to do the second one, when .unwrap is just there and better.

    If your concept of “not ugly” is “I just want to see the happy path” then you either write bad code that is “not ugly” or write good code that is “ugly”. Because there is no language that allows you to handle errors while not having error handling code near where the errors are produced.




  • You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.

    This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.

    The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.

    And the loop doesn’t contain any codeblock. Just an opening bracket.

    Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.

    Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.