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/)F
Posts
3
Comments
1684
Joined
2 yr. ago

  • Yeah he's dead wrong here. Even clang-format - easily the worst autoformatter I've used - is an order of magnitude more tolerable than no auto-formatting.

    Sure it might not always be as good as what a perfectionist human would produce, but it's sure as hell better than what the average human produces, and it means you don't have to waste time ranting like this.

  • I use Google Slides - you get better control over the layout.

  • Not on RISC-V. The registers don't really have an endianness. They're just bit vectors - you can't address within them.

    When you access memory the current endianness setting determines the mapping between the register value and the bytes in memory. It's the access that has endianness; not the register.

  • All three of those languages have library ecosystems at least as good as Python's. Typescript is just as easy to learn and as fast to write as Python. I don't see why you'd think Python is faster. If I add up all the time I've lost to Python's terrible tooling it's quite a lot slower!

    Rust is definitely harder to learn - I'll give you that. But once you have learnt it it's just as fast as Typescript and Python. Especially if your "fast to write" metric measures to when you program is correct.

  • I think Python is superficially easier since you don't have to declare variables, printing is a little easier, etc. And in some ways it is actually easier, e.g. arbitrary precision integers, no undefined, less implicit type coercion.

    But I agree JavaScript is generally a better choice. And it is actually more popular than Python so...

  • I think it's just because it is always recommended as an "easy" language that's good for beginners.

    The only other thing it has going for it is that it has a REPL (and even that was shit until very recently), which I think is why it became popular for research.

    It doesn't have anything else going for it really.

    • It's extraordinarily slow
    • The static type hints are pretty decent if you use Pyright but good luck convincing the average Python dev to do that.
    • The tooling is awful. uv is a lifesaver there but even with uv it's a bit of a mess.
    • The package system is a mess. Most people just want to import files using a relative path, but that's pretty much impossible without horrible hacks.
    • The official documentation is surprisingly awful.
    • Implicit variable declaration is a stupid footguns.

    The actual syntax is not too bad really, but everything around it is.

  • I mean... C is a low bar. You can write Typescript, Rust and Go code 5x faster than C too.

  • pip is easily the worst thing about Python. But now that we have uv I would say the worst thing is the package/import system. I'm pretty sure only 1% of developers understand it, and it only really works properly if your Python code is a Python package.

    If you treat Python as a scripting language and just scatter loose files around your project and run them directly, it doesn't work at all. Pain everywhere. Which is dumb as fuck because that's like 80% of how people use Python.

  • Very easy to install

    This has to be a joke.

  • Unlikely, you'd do packet processing in hardware, either through some kind of peripheral or if you're using RISC-V you could add custom instructions.

  • He's right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.

    This is the kind of silly stuff that just makes RISC-V look bad.

    Couldn't agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don't forget that instruction fetch ignores this and is always little endian.

    Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:

    We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and certain legacy code bases have been built assuming big-endian processors, so we have defined big-endian and bi-endian variants of RISC-V.

    This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven't). It's extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.

    Linux should absolutely not implement this.

  • Not reliably though. I installed Kubuntu on a recent desktop just last week and had to revert it from Wayland back to X11 because every time it woke from sleep Plasmashell would crash and VSCode windows would be blank.

    Also it's 4% (of desktop, 1.5% overall) according to statcounter. Which is admittedly not bad, but I wouldn't say it's enough to say it has "happened".

  • Well that just seems silly. You're ok with an inconvenient ad-hoc collection of mandatory IDs, but not a unified one.

  • Yeah you'd think, but that was always the reason that was given.

  • Desktop Linux still hasn't happened...

  • They certainly tried (see Poetry, Pyenv, Conda, etc.). But that was mostly done by Python developers in Python, which is frankly the entire problem.

  • You already need some kind of proof of identity to work and housing. This just designates one identifier as the one you have to use. Hardly different.

  • Probably not, because you can still publish on alternative app stores. Just not in the way that F-Droid wants it to work - where they build the app from source for you.

  • This is really naive. Mobile Linux is never going to happen for many reasons.

    It would be better to spend effort on lobbying regulators to prevent this move.