• 1 Post
  • 63 Comments
Joined 1 year ago
cake
Cake day: June 28th, 2023

help-circle








  • AI’s not bad, it just doesn’t save me time. For quick, simple things, I can do it myself faster than the AI. For more big, complex tasks, I find myself rigorously checking the AI’s code to make sure no new bugs or vulnerabilities are introduced. Instead of reviewing that code, I’d rather just write it myself and have the confidence that there are no glaring issues. Beyond more intelligent autocomplete, I don’t really have much of a need for AI when I program.


  • They’re both pretty on par for the most part. If it’s too much of a hassle, there’s no real need to switch.

    Now that Gitea is owned by a for-profit company, people are afraid that they’ll be making anti-user changes. This, Forgejo was born. It pulls from Gitea weekly, so it’s not missing anything. It’s also got some of its own features on top, but they’re currently pretty minor. Also, most of the features end up getting backported back to Gitea, so they’re mostly on par with each other. However, many features find themselves in Forgejo first, as they don’t have the copyright assignment for code that Gitea does. Additionally, security vulnerabilities tend to get fixed faster on Forgejo. They are working on federation plans, however, so we’ll see how that pans out.

    Overall, there’s no downside of switching to Forgejo, and you’ll probably be protected if Gitea Ltd. makes some stupid decisions in the future. However, at the moment, there’s no immediate advantage to switching, so you can stick with Gitea if you’d like.




  • That’s fair. I started with what everyone was using at the time, which just so happened to be Neovim. I’m also too lazy to switch/try anything else.

    Plus, I’m not sure if Neovim simply extends Vim functionality. I know it’s a fork, but the codebase has changed so much I’m pretty sure many newer features of Vim need to be manually added to Neovim. Inlay hints in the middle of lines is already implemented in Vim: as for Neovim, it’s not here yet (well, it’s coming in 0.10, but I don’t use nightly so I don’t have it)







  • I’ll point to how many functional languages handle it. You create a type Maybe a, where a can be whatever type you wish. The maybe type can either be Just x or Nothing, where x is a value of type a (usually the result). You can’t access the x value through Maybe: if you want to get the value inside the Maybe, you’ll have to handle both a case where we have a value(Just x) and don’t(Nothing). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in another Maybe, where you’ll either return the result through a Just or a Nothing. These are just some ways we can use Maybe types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe is Nothing: with null, it’s easy to forget. Even in languages like Zig, the Maybe type is present, just hiding under a different guise.

    If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.

    TLDR: The Maybe monad is a much better alternative to nulls.