• 0 Posts
  • 53 Comments
Joined 2 years ago
cake
Cake day: September 24th, 2023

help-circle

  • Well, git is for source control, not binary artefacts

    Only because it is bad at binary artefacts. There’s no fundamental reason you shouldn’t be able to put them in version control.

    It’s not much of an argument to say “VCSes shouldn’t be able to store binaries because they aren’t good at it”.

    What are your requirements? What do you need this for?

    Typically there’s a third or first party project that I want to use in my project. Sometimes I want to be able to modify it too (soft fork).

    And why do you think everyone else needs the same?

    Because I’ve worked in at least 3 companies who want to do this. Nobody had a good solution. I’ve talked to colleagues that also worked in other companies that wanted this. Often they come up with their own hacky solutions (git subtree, git subrepo, Google’s repo, etc. etc. - there are at least half a dozen of these tools).

    It’s quite possible you are doing it wrong.

    No offence, but your instinctive defence of Git and your instant leap to “you’re holding it wrong” are a pretty dead giveaway that you haven’t stopped to think about how it could be better.


  • Tbh these aren’t things that are big issues with Git. The biggest issues I have are:

    • Storing large files. LFS is a shitty hack that barely works.
    • Integrating other repos. Git submodules are a buggy hack, and Git subtree is… better… but still a hack that adds its own flaws.

    Fix those and it will take over Git in a very short time. Otherwise it’s just going to hang around as a slightly nicer but niche alternative.



  • Full of WTFs.

    My default development environment on Windows is the Linux-like MSYS2 environment

    I think this sets the tone nicely lol.

    it’s clear at this point already that Zig is a weakly-typed language

    Uhm… pretty sure it isn’t.

    You can only use the zig command, which requires a special build file written in Zig, so you have to compile Zig to compile Zig, instead of using Make, CMake, Ninja, meson, etc. as is typical.

    Yeah who wants to just type zig build and have it work? Much better to deal with shitty Makefiles 🤦🏻‍♂️

    Ignoring the obvious memory safety red herring,

    Uhhh

    we can worryingly tell that it is also a weakly-typed language by the use of type inference

    Ok this guy can be safely ignored.

    the fact that the unsafe keyword is required to cooperate with C interfaces gives even great cause for concern

    ?

    Rather than dealing with this ‘cargo’ remote repository utility and reliving traumatic memories of remote artefact repositories with NodeJS, Java, etc., we’ll just copy the .rs files of the wrapper directly into the source folder of the project. It’s generally preferred to have dependencies in the source tree for security reasons unless you have some level of guarantee that the remote source will be available and always trustworthy.

    Lol ok… Ignore the official tool that works extremely well (and has official support for vendoring) and just copy files around and then is surprised that it doesn’t work.

    Although you can use the rustc compiler directly, it provides an extremely limited interface compared to e.g. Clang and GCC

    That is a good thing.

    You get similar struggles with just getting the basic thing off the ground

    Uhm yeah if you ignore the tutorials and don’t use the provided tools. It’s literally cargo init; cargo run.

    What an idiot.





  • They mean measure first, then optimize.

    This is also bad advice. In fact I would bet money that nobody who says that actually always follows it.

    Really there are two things that can happen:

    1. You are trying to optimise performance. In this case you obviously measure using a profiler because that’s by far the easiest way to find places that are slow in a program. It’s not the only way though! This only really works for micro optimisations - you can’t profile your way to architectural improvements. Nicholas Nethercote’s posts about speeding up the Rust compiler are a great example of this.

    2. Writing new code. Almost nobody measures code while they’re writing it. At best you’ll have a CI benchmark (the Rust compiler has this). But while you’re actually writing the code it’s mostly find just to use your intuition. Preallocate vectors. Don’t write O(N^2) code. Use HashSet etc. There are plenty of things that good programmers can be sure enough are the right way to do it that you don’t need to constantly second guess yourself.





  • AI is good at more than just generating stubs, filling in enum fields, etc. I wouldn’t say it’s good at stuff beyond just “boilerplate” - it’s good at stuff that is not difficult but also isn’t so regular that it’s possible to automate using traditional tools like IDEs.

    Writing tests is a good example. It’s not great at writing tests, but it is definitely better than the average developer when you take the probability of them writing tests in the first place into account.

    Another example would be writing good error context messages (e.g. .with_context() in Rust). Again, I could write better ones than it does. But like most developers there’s a pretty high chance that I won’t bother at all. You also can’t automate this with an IDE.

    I’m not saying you have to use AI, but if you don’t you’re pointlessly slowing yourself down. That probably won’t matter to lots of people - I mean I still see people wasting time searching for symbols instead of just using a proper IDE with go-to-definition.


  • Assembly is very simple (at least RISC-V assembly is which I mostly work with) but also very tedious to read. It doesn’t help that the people who choose the instruction mnemonics have extremely poor taste - e.g. lb, lh, lw, ld instead of load8, load16, load32, load64. Or j instead of jump. Who needs to save characters that much?

    The over-abbreviation is some kind of weird flaw that hardware guys all have. I wondered if it comes from labelling pins on PCB silkscreens (MISO, CLK etc)… Or maybe they just have bad taste.

    I once worked on a chip that had nested acronyms.



  • The evidence is that I have tried writing Python/JavaScript with/without type hints and the difference was so stark that there’s really no doubt in my mind.

    You can say “well I don’t believe you”… in which case I’d encourage you to try it yourself (using a proper IDE and use Pyright; not Mypy)… But you can equally say “well I don’t believe you” to scientific studies so it’s not fundamentally different. There are plenty of scientific studies I don’t believe and didn’t believe (e.g. power poses).



  • then why isn’t it better to write instead everything in Haskell, which has a stronger type system than Rust?

    Because that’s very far from the only difference between Haskell and Rust. It’s other things that make Haskell a worse choice than Rust most of the time.

    You are right in that it’s a spectrum from dynamically typed to simple static types (something like Java) to fancy static types (Haskell) then dependent types (Idris) and finally full on formal verification (Lean). And I agree that at some point it can become not worth the effort. But that point is pretty clearly after and mainstream statically typed language (Rust, Go, Typescript, Dart, Swift, Python, etc).

    In those languages and time you spend adding static types is easily paid back in not writing tests, debugging, writing docs, searching code, screwing up refactoring. Static types in these languages are a time saver overall.



  • No I disagree. There are some things that it’s really infeasible to use the scientific method for. You simply can’t do an experiment for everything.

    A good example is UBI. You can’t do a proper experiment for it because that would involve finding two similar countries and making one use UBI for at least 100 years. Totally impossible.

    But that doesn’t mean you just give up and say “well then we can’t know anything at all about it”.

    Or closer to programming: are comments a good idea, or should programming languages not support comments? Pretty obvious answer right? Where’s the scientific study?

    Was default case fallthrough a mistake? Obviously yes. Did anyone ever do a study on it? No.

    You don’t always need a scientific study to know things to a reasonable certainty and often you can’t do that.

    That said I did see one really good study that shows Typescript catches about 15% of JavaScript bugs. So we don’t have nothing.