• 0 Posts
  • 97 Comments
Joined 10 months ago
cake
Cake day: September 24th, 2023

help-circle

    • Pijul: patch-based like Darcs but apparently solves its performance issues. In theory this improves conflict resolution.
    • Jujutsu: kind of an alternative front-end to a git repo (but not a front-end to git). Has some different ideas, like no staging area (draft commit), and some other stuff I can’t remember.
    • Sapling: from Facebook. Unfortunately only part of it is available. The server is not public yet (I guess it’s tired up in Facebook infrastructure too much).

    And it’s definitely not a solved problem. Aside from the obvious UX disaster, Git has some big issues:

    • Monorepo support is relatively poor, especially on Mac and Linux.
    • Submodule support is extremely buggy and has particularly bad UX even for Git.
    • Support for large files via LFS is tacked on and half-arsed.
    • Conflict resolution is very very dumb. I think there are third party efforts to improve this.

    I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimisations and bare minimum partial checkout support.

    Or you go with submodules and then you have even bigger problems. Honestly I’m not sure there’s really an answer for this with Git currently.

    It’s not hard to imagine how this might work better. For instance if Git repos were relocatable, so trees were relative to some directory, then submodules could be added to a repo natively just by adding the commits and specifying the relative location. (Git subtree almost does this but again it’s a tacked on third party solution which doesn’t integrate well, like LFS.)



  • They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.

    No they aren’t. A higher version of UUID isn’t “newer and better”, like the word “version” implies. It’s just different. It’s like they called a car “vehicle version 1” and a motorbike “vehicle version 2”. The common use of “version” in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.

    The talking pumpkin is 100% right that they should have used “type” or “mode” or “scheme” or something instead.




  • formatting does depend on the type of variables. Go look at ktfmt’s codebase and come back after you’ve done so…

    I skimmed it. It appears to visit the AST of the code and format that, as any formatter does. ASTs have not been type checked.

    Can you give an example?

    it gives you an option, just like if it was an interface. Did you actually try this out before commenting?

    Precisely! It doesn’t know the answer so it has to guess, or make you guess.

    And how often are you naming functions the exact same thing across two different classes without using an interface?

    You mean how often does the same field name come up more than once? All the time obviously! Think about common names like id, size, begin, children, etc. etc.

    I’m sorry, but you clearly haven’t thought this out, or you’re really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).

    I’m sorry but you clearly haven’t thought this through, or you’re just happy to ignore the limitations of Ruby. I suspect the latter. Please don’t pretend they aren’t limitations though. It’s ok to say “yes this isn’t very good but I like Ruby anyway”.


  • I think you’re getting a bit confused. How do you know where x’s type is defined and therefore where x.bar is defined if you don’t know what type x is? It’s literally impossible. Best you can do is global type inference but that has very big limitations and is not really feasible in a language that wasn’t designed for it.

    Do you think that formatters for dynamic languages need to know the type in order to format them properly? Then why in the world would you need it to know where to jump to in a type definition!?!

    Not sure if that is a serious question, but it’s because formatting doesn’t depend on the type of variables but going to the definition of a field obviously depends on the type that the field is in.

    Maybe my example was not clear enough for you - I guess it’s possible you’ve never experienced working intellisense, so you don’t understand the feature I’m describing.

    class A:
      bar: int
    
    class B:
      bar: str
    
    def foo(x):
      return x.bar
    

    Ctrl-click on bar. Where does it jump to?



  • I’ve literally never heard anyone say that

    Well you didn’t listen then. Google the phrase.

    I can tell you’ve literally never even tried this…

    I do not need to try it to know that this is fundamental impossible. But I will try it because you can go some way towards proper type knowledge without explicit annotations (e.g. Pycharm can do this for Python) and it’s better than nothing (but still not as good as actual type annotations).

    It’s also much more readable than bash, python, javascript, etc. so writing a readable (and runnable everywhere)

    Bash definitely. Not sure I’d agree for Python though. That’s extremely readable.


  • You’re talking about rails.

    Maybe other Ruby code is better, but people always say Rails is the killer app of Ruby so…

    Use an IDE like I said and you can literally just “Find all usages” or “Jump to declaration”, etc.

    That only works if you have static type annotations, which seems to be very rare in the Ruby world.

    In any case, you shouldn’t be using any of these for large projects like gitlab, so it’s completely inconsequential.

    Well, I agree you shouldn’t use Ruby for large projects like Gitlab. But why use it for anything?






  • You can count Ruby out immediately. Terrible language.

    Also replace JavaScript with Typescript. It’s strictly superior.

    I don’t think Go has any mature GUI libraries.

    For desktop GUI your main options are:

    • Qt, via C++. Probably the best option but if you don’t know C++ that’s a huge barrier.
    • Qt, via Python. Reasonable but Python is quite a shit language. It’s very slow and the tooling/infrastructure is absolutely abysmal. Be prepared to bang your head against the wall trying to e.g. get relative imports to work.
    • Dart/Flutter. This is quite nice but not super mature for desktop apps. Also the Dart ecosystem is very small so libraries you want may not be available.
    • Electron/Typescript. This is quite a good option. Nobody here will recommend this because nerds have a slightly weird hatred of Electron because the minimum download size is like 80MB. But normally it doesn’t really matter. Especially for big apps.

    For the web frontend you basically want Typescript. For the backend you can use literally any language.

    I would recommend Electron for the GUI and Typescript for the web frontend and Electron GUI. It means you can use the same language everywhere and you won’t need to even implement the same program twice.

    If you’re worried about the download size / RAM usage you can look into Tauri which uses your OS’s browser engine. I’ve never used it though.



  • Haven’t tried Mojo yet but I have tried Julia and it kinda sucked balls. Sorry Julia fans, but it did. My main complaints:

    • It’s a research language like MATLAB, so the emphasis is on repl’s, trying things out etc. But the compilation model is like C++. When you import a package it spends like 2 minutes compiling it. I think it’s supposed to cache it but the second time it was still like 10 seconds for me just to import a package. I believe they’ve improved this since I used it but still, huge red flag.
    • 1-based indexing. Come on guys. Anyone using this is smart enough to learn 0-based indexing. It’s like putting a steering wheel in a jet fighter because you worry about pilots getting confused by a joystick. Again, red flag.
    • The plotting libraries (a core feature for this sort of language) kind of sucks. In fairness nothing comes close to MATLAB on this front. I ended up paying for MATLAB because of that.

    There’s also this article which has more reasons.

    I am leaving it a while longer before I try Mojo.