@FizzyOrange - eviltoast
  • 2 Posts
  • 543 Comments
Joined 1 year ago
cake
Cake day: September 24th, 2023

help-circle
  • A sane language, you say.

    Yes:

    Operator '+' cannot be applied to types 'number[]' and 'number[]'.
    

    We’re talking about Typescript here. Also I did say that it has some big warts, but you can mostly avoid them with ESLint (and Typescript of course).

    Let’s not pretend Python doesn’t have similar warts:

    >>> x = -5
    >>> y = -5
    >>> x is y
    True
    >>> x = -6
    >>> y = -6
    >>> x is y
    False
    >>> x = -6; y = -6; x is y
    True
    
    >>> isinstance(False, int)
    True
    
    >>> [f() for f in [lambda: i for i in range(10)]]
    [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
    

    There’s a whole very long list here. Don’t get be wrong, Python does a decent job of not being crazy. But so does Typescript+ESLint.

    I’ve worked professionally in python for several years and I don’t think it’s ever caused a serious problem. Everything’s in docker so you don’t even use venv.

    “It’s so bad I have resorted to using Docker whenever I use Python.”




  • Typescript is far nicer than Python though. Well I will give Python one point: arbitrary precision integers was absolutely the right decision. Dealing with u64s in Typescript is a right pain.

    But apart from that it’s difficult to see a single point on which Python is clearly better than Typescript:

    • Static typing. Pyright is great but it’s entirely optional and rarely used. Typescript obviously wins here.
    • Tooling. Deno is fantastic but even if we regress to Node/NPM it’s still a million miles better than the absolute dog shit pile of vomit that is Pip & venv. Sorry Python but admit your flaws. uv is a shining beacon of light here but I have little hope that the upstream Python devs will recognise that they need to immediately ditch pip in favour of officially endorsing uv. No. They’ll keep it on the sidelines until the uv devs run out of hope and money and give up.
    • Performance. Well I don’t need to say more.
    • Language sanity. They’re pretty on par here I think - both so-so. JavaScript has big warts (the whole prototype system was clearly a dumb idea) but you can easily avoid them, especially with ESLint. But Python has equally but warts that Pylint will tell you about, e.g. having to tediously specify the encoding for every file access.
    • Libraries & ecosystem. Again I would say there’s no much in it. You’d obviously be insane to use Python for anything web related (unless it’s for Django which is admittedly decent). On the other hand Python clearly dominates in AI, at least if you don’t care about actually deploying anything.

  • They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.

    Yeah it’s confusing because in maths they are the same and use the same symbol but they are 100% not the same in programming, yet they confusingly used the same symbol. In fact they even used the mathematical equality symbol (=) for the thing that is least like equality (i.e. assignment).

    To be fair not all languages made that mistake. There are a fair few where assignment is like

    x := 20
    

    Or

    x <- 20
    

    which is probably the most logical option because it really conveys the “store 20 in x” meaning.

    Anyway on to your actual question… They definitely aren’t the same in programming. Probably the simplest way to think of it is that assignment is a command: make these things equal! and equality is a question: are these things equal?

    So for example equality will never mutate it’s arguments. x == y will never change x or y because you’re just asking “are they equal?”. The value of that equality expression is a bool (true or false) so you can do something like:

    a = (x == y)
    

    x == y asks if they are equal and becomes a bool with the answer, and then the = stores that answer inside a.

    In contrast = always mutates something. You can do this:

    a = 3
    a = 4
    print(a)
    

    And it will print 4. If you do this:

    a = 3
    a == 4
    print(a)
    

    It will (if the language doesn’t complain at you for this mistake) print 3 because the == doesn’t actually change a.


  • Interesting how they build a community starting with rebasing on top of Gitea, and then hard-forked later. Probably a good blueprint for forking.

    GPL move also seems like a good idea - it reduces the chance of needing yet another fork.

    Can they get whoever came up with the excellent name “Codeberg” to fix the terrible name “Forgejo” though? It’s not quite as bad a name as GIMP or Got, but still…

    Also i absolutely hate how they talk about moderation. You can’t just say “someone was banned for some actions”. That doesn’t inspire confidence at all! Imagine if the police were always saying “one of your peers was sent to prison for a crime” and refused to say who or what they did. That’s communist Russia territory…

    They claim they can’t say because of the right to be forgotten but that’s not what the right to be forgotten means.






  • They’ve been doing that for about the last 6 releases. I wish they’d fix some of the long-standing annoying bugs like the fact that you can’t respect .gitignore and search in a subdirectory at the same time. Or the fact that you can’t stage a submodule unless you also have that submodule open.

    Or how about a less annoying way to configure Run/Debug than launch.json?

    Still, can’t complain. It’s mostly free and still very good overall. I’ll definitely be watching Zed… but maybe not too closely until it supports opening large files.


  • where before we ran into compatibility problems with glibc

    I wonder if GNU will ever fix that. Surely at some point they have to say “ok we still think things should be open source but we are going to make it suck a little bit less for people that don’t build literally everything from source on their local machine”… right? Ok maybe not.