It’s fine to want a gui debugger and I want to clarify that I’m not actually trying to persuade you to use gdb! My actual advice would be vscode (or other ide) with it’s gdb/lldb integration which allows you to debug from your ide in a gui-oriented way.

I do however think that you’re wrong about how hard it is to learn gdb. I learned to use it not that long ago and it doesn’t take “1 month”. Using gdb on a basic level is actually not particularly hard, and I can recommend this talk for anyone actually curious about learning gdb. It’s just 15 minutes, but the same speaker has done a couple of other talks on the same theme that are longer if you want to learn even more, you can probably find them in the recommended videos sidebar.

What I actually think is the case is that learning gdb takes a bit more mental effort because it’s a different paradigm than normal gui editors, and a lot of things aren’t intuitive. If you’re prepared to be a bit uncomfortable and lost for an afternoon, and maybe even flip through the official document for a bit you can be “good enough” at gdb in less than a day.

Gdb is also more powerful than most gui-only editors, because you can do scripting in gdb. For example you can execute an arbitrary series of gdb commands when you hit a certain breakpoint which can be really useful in some circumstances. My preferred way of debugging in linux is actually to both have a gdb window that I can enter commands in so I can do more scripting stuff if I want to, and also some extra bells and whistles for viewing source code and setting breakpoints etc. I edit in vim so I use the termdebug plugin that comes bundled with vim, but use whatever exists for your editor if you don’t use vim yourself.

I like this quote

and just the other day I caught myself wondering who will clean out my Inbox after I’m dead

I think that it’s bad to become too dependent on a certain tool, especially if that tool is owned by microsoft, although in this case your dependent on various microsoft api:s anyway so that’s probably a bigger problem in that regard. Experimenting with programing without Visual Studio is a good idea and will probably teach you lots of things about yourself and microsoft api documentation in this case. If microsoft has built a system that is so impractical that you need visual studio to navigate it, that’s a pretty bad sign for the health of the microsoft ecosystem, but that’s not exactly surprising anyone

One of my acquaintances has actually made a small game in Odin (Cat and Onion) and after that written a book about the language (Understanding the Odin Programming Language). I don’t know much about Odin myself but from what I’ve gathered there isn’t that much quality documentation or that many good tutorials etc. so it can be a bit hard to get in to the language, which is why he decided to write the book.

Most of the music I listen to fits under the alternative umbrella. While I never actually spent a lot of time directly on /mu/ that type of online music culture circa ten years ago has been very influential on my music taste. A couple of years ago I also had a big emo phase, in particular 90’s emo and 10’s emo revival. I also listen to a lot of punk and post hardcore.

One thing that I don’t think anyone else has mentioned is data structures. Bash does have arrays and hashmaps at least but I’ve found that working with them is significantly more awkward than in e.g. python. This is one of several reasons for why bash doesn’t scale up well, but sure for small enough scripts it can be fine (if you don’t care about windows)

Sure, what I’m saying is that they’re both editors that you need to invest time in. A bit less so with helix since it has better defaults so you don’t need to spend as much time configuring it, but I don’t think that makes a huge difference.

Helix has better defaults for sure and I get why people might prefer it but I have a very hard time imagining it being a better choice than vim in every situation even with a lot more development.

Also, if you work with programming for example your editor is going to be one of your main tools and I think that “reading guides” is an acceptable amount of effort to put in to learning such a tool. Vim has a higher barrier of entry than it needs to (this can to some extent be explained with backwards compatability) but with Helix you still have to put some time in to understanding the editing model anyway.

The biggest thing missing from helix right now imo is plugin support, so a lot of plugins that I really like wouldn’t be available. I use fugitive a lot for working with git for example.

Another one is the quickfix list in combination with ex commands. One thing you can do for example is setup :make to run your compiler and then when you get compilation errors they’ll show up in your quickfix list. You can then use :Cfilter to focus on one type of error and then :cdo to for example do a find and replace on the remaining lines.

In general, if I don’t have an lsp available for whatever reason (I work in cmake a fair amount at my $DAYJOB for example) I would much rather use vim, in particular because of the stuff that you can do with ex commands that I mentioned above (also works great with grep) but also because of the ctags support.

Helix can do a lot of nice things out of the box for a lot of cases of software editing, but it’s not nearly as broad or as customizable of a tool as vim

I don’t really see the point in a “facebook competitior” since the only appeal of facebook is that it’s “normal” and “evryone” is on it, something that just isn’t going to be true for e.g. some fediverse product. Everyone should stop using facebook if possible though, I’m trying to persuade different messenger groupchats that I’m part of to switch to something else left and right personally

Vim still has a lot of advantages over helix. Being modern doesn’t automatically make a tool better

I’ve been wanting a phone with a keyboard for a long time, I don’t think I’ll get this one (I specifically got a fairphone in part so I wouldn’t have to think about buying a new phone for a couple of years) but I think that this could be really nice for some specific usecases that are underserved today.

With arch, I’d recommend just jumping in the deep and and installing it, looking things up on the wiki when something goes wrong. Just do it in a virtual machine or on an old laptop or something to start with. I broke my previous distro (mint) by doing some really stupid stuff, and I decided to just go fuck it and install arch. I don’t think I’ve ever learned as much about linux as that weekend.

I suppose that I was already pretty comfortable with the terminal since I was studying computer science at the time so I had a lot of reason to use it. I think the best way to use the terminal is to force yourself to use it, programming is great for this but you can try e.g. sorting your photos or mp3 files or something as practice too.

It’s kind of an apples to oranges. i2p is better at protecting your privacy in my estimation, but private trackers can be better at curating high quality torrents for example.

As long as you have your windows license key you can change your mind later so really you can do whatever. I’d recommend giving 100% linux a try if that seems fun. Obviously you’re gonna want to back up any interesting files that you have on windows either way.

Ah ok just read the article and not the proposal. I’m surprised that they went that far but as I wrote I think that lifetime annotations are a good idea, hope the C++ people find a way to add them to the language that actually works well, which sounds like an incredibly difficult task.

I’m a bit skeptical that a borrow checker in C++ can be as powerful as in rust, since C++ doesn’t have lifetime annotations. Without lifetime annotations, you have to do a whole program analysis to get the equivalent checks which isn’t even possible if you’re e.g. loading dynamic libraries, and prohibitively slow otherwise. Without that you can only really do local analysis which is of course good but not that powerful.

Lifetime annotations in the type system is the right call, since it allows library authors to impose invariants related to ownership on their consumers. I doubt C++ will add it to their typesystem though.

Vim sort of already has this feature via set foldmethod=syntax. This doesn’t work exactly like the author suggests but you can also use set foldmethod=expr and then set foldexpr to a more complicated expression to only get nested function/method bodies, via tree sitter for example if you’re on neovim.

To add on this, this doesn’t necessarily mean that there are fewer programing jobs in total. If people work 10% more efficently, that means that the cost of labor is only 91% of what it was before meaning that people might be able to afford to finance more programing projects. One thing that does matter is for example things like entry level jobs disappearing or the nature of the work changing. Doing less boring gruntwork can make the job more fun, but otoh digitization sometimes results in the worker having less agency in what they do since they have to fit everything into a possibly inflexible digital system.

I’m using “OOP” more in the sense that is described in the article, but that is a fair perspective on rust and OOP. It is a term with a lot of different interpretations after all.

Curious to hear what in Rust could be more easily solved with OOP! I think one reason for rust not using OOP is because they want to minimize dynamic dispatch and keep it explicit where it happens, because it’s a language that gives you very fine grained control of resource usage, kinda similar to how you have to be explicit about copying for most types. Most trait calls are static dispatch unless you have a Box::<dyn SomeTrait>