Looking at the example

Why does the generated bash look like that? Is this more safe somehow than a more straighforward bash if or does it just generate needlessly complicated bash?

It’s weird to have something that verbose for using in the shell. I don’t want to use verbose commands when just doing stuff interactively, so I never learn how to really use its features as a concequence. Bash, while it has more footguns, is more readable to me because I’m more familiar with the individual commands. For most programing you spend more time reading it than writing it, but that’s not the case for the shell so there it’s the wrong tradeoff imo.

Since the diffs are tree-sitter based, it’s interesting to think about what a tree-sitter based patch would look like. Probably wouldn’t double as a human and computer friendly format like normals diffs. I suppose that you could create patches that are more robust to the source code changing since it wouldn’t care about linebreaks and maybe you could have it so it doesn’t care if you move code around since you could have it so its going by e.g. what the parent function is and not the line number. I gotta wonder how useful that actually is though.

There is a lot of fanboying in discussions like these, so I understand if you’re weary of that. That said I don’t think static analysis tools are a very good point of comparison for (what I’m assuming that you’re referring to) Rusts ownership system.

While static analysis tools certainly can be useful for some classes of errors, there are types of errors that they can’t catch that the borrowchecker can. This is because the language are built around them in Rust. Rusts lifetime analysis is dependent on the user adding lifetime annotations in certain situations, so since c++ doesn’t have these annotations static analysis tools for c++ can’t benefit from the information these annotations provide.

Furthermore, c++ suffers from being an old language with a lot of features. Legacy features can allow for various loopholes that are hard for a static analysis tool to reason about.

C++ static analysis tools can find errors, but Rusts borrowchecker can prove the absence of errors modulo unsafe code.

That said, I don’t have any good data on how much of a problem this is in practice. Modern c++ with a CI-pipeline doing static analysis and forbidding certain footguns is safe enough for most contexts. Personally, I’m exited about Rust more because I think that it’s a nicely designed language than because of its safety guarantees, but it doesn’t really have the ecosystem support for a lot of things, like gamedev or ui at the moment.

There will be plenty of jobs in c++ in the foreseeable future, so it’s not a bad language to know from that perspective. I don’t know if it’s the most pedagogical language to learn otoh, python is a better language for getting comfortable with the basics, c is better when it comes to learning a (slightly wrong but close enough) mental model of how a computer works under the hood, and there are many better languages to learn if you want to learn good approaches to thinking about problems.

Maybe you are leaning c++ because you want to work on something specific that c++ is primarily used in, and in that case go ahead with that project. I think having something tangible that you want to work on is great when it comes to learning programing and that’s worth more than picking the “best” language. Besides, you can always learn different languages later in your career if you want/have to.

deleted by creator

Sometimes I’ll solve a computer problem for someone in an area that I know nothing about by just googling it. After telling them that all I had to do was google the problem and follow the instructions they’ll respond by saying that they wouldn’t know what to google.

Just being experienced at searching the web and having the basic vocabulary to express your problems can get you far in many situations, and a fair bit of people don’t have that.

Multiple cursors are a lot better than :s for you standard search and replace, unless you have a really big file at which point helix gets to slow (which isn’t that common) but there are a lot of other stuff you can do with ex commands.

I use :make pretty often, vim ships with the ability to parse a lot of compiler/linter outputs out of the box so if you tell it which one with :compiler you get build errors in the quickfix list. I also use :grep a lot. You can do <space>/ to grep in helix but I often find that I want to add command line options to only search in specific directories or for specific file types (we have a large codebase at work). Being able to filter results with :Cfilter, and being able to go back to old quickfix results with :colder is also really nice. Finally, you can use :cdo to apply ex commands to stuff you’ve matched in the quickfix list.

As an example, if you get a build error because you’ve renamed a variable in one file but not the places it gets referenced in other files, you can :make to get the build errors in you quickfix list, :Cfilter to narrow it down to only that specific class of error if needed and then do :cdo s/oldName/newName/g to rename the variable in all places that cause errors. You can then go back to the list of all errors with :colder and handle other errors in another way if needed.

I’ll have to admit that I don’t do this that often so honestly I wouldn’t lose out on that much switching to helix (after it gets proper plugin support and someone makes a decent replacement for the fugitive git plugin) but I would feel less powerful not knowing that I have those tools up my sleave lol.

I don’t think helix will ever catch up to a lot of vims lesser know features of which there are a lot. I think that’s by design as well, I think that helix wants to have a smaller surface area than vim and for a lot of people that will be the right choice. I personaly use ex-commands for example, or the quickfixlist fairly often so for me I have a hard time imagining helix not feeling like a step down power-wise (as nice as multiple cursors are).

I might be suffering from stockholms syndrome here, but my prefered ways of working with git are the cli and the fugitive vim plugin which is a fairly thin wrapper around the cli. It does take a middle ground approach on hiding the magic and forcing you to learn the magic which I suppose can be confusing for beginners when you work collaboratory and something happens that forces you to go beyond pull/add/commit/push

I think you know what I mean when I contrast Rust with GC’d languages, we can call it opt-in garbage collection if we’re being pedantic.

If you just Rc everything (which I’d count as “abusing Rc”) Rust is significantly worse than a language with a good GC. The good thing about Rust is that it forces you to aknowledge and consider the lifetimes of objects. By default things are allocated on the stack, but if you make something global or dynamically handled (e.g. through Rc) you have to do so explicitly. In Rust the compiler has greater compile time information about when things can be freed which means that you need less runtime overhead to check things and if you want to minimize the amount of potentially long-lived objects you can more easily see how long objects might live by reading the code as well as get help by the compiler to determine if a lifetime-based refactoring is sound or not.

Haskell. I think that more people being familliar with Haskell concepts would be good for programing culture and it would increase the odds of me being able to write Haskell professionally, which is something I enjoy a lot when writing hobby code at least. Having more access to tooling and a bigger eco system would be nice as well.

I’m not a 100% sure about my answer though. For one, I might grow to resent Haskell if I had to use it at work, and there’s also a risk that it would be harder to do cool innovative stuff with the language when more big companies depend on it.

You are absolutely correct that rusts safety features don’t extend to memory leaks, but it’s still better than most garbage collected languages unless you abuse Rc or something, and it does give you quite fine-grained controll over lifetimes, copying and allocations on the heap which in practice means that rust is fairly good about memory leakages compared to most languages.

What’s esoteric about Rusts syntax? I can’t relate at all, but maybe I had just the right background of languages commin into Rust.

runtime, the point is so that you can see if the types align and then come back and fill in the function bodies later

Scala has one, which throws a NotImplemented error

One downside with the code on the right is that it’s not obvious where the different functions might be called from. In the example on the left, we know that we’re not, say, adding toppings to a pizza that we haven’t baked. If we notice a bug in the topping adding function on the right, we might get tempted to reason about adding toppings as a general process that needs to handle all kinds of situations when in practice is doesn’t.

When you have single use functions like this it’s good to limit the scope of the function using whatever language features are available so that you can more easily reason about where it’s being called from

I’m not in charge of many open source projects but the last one I actually put up on gitlab instead. We use gitlab at internally at work and it’s completely fine. I mostly use my github account to interact with repos that other people host on github.

I think that there might be a fundamental missunderstanding here: I’m not saying that we shouldn’t use tabs to accomodate people with disabilities, I’m saying that better editor features seems like a better “solution” to the problem.

In the abscence of editor improvements I agree that it makes sense to use tabs to accomodate disabilities, I just don’t think that it will catch on that mutch. I don’t think that spaces (imo) being slightly better is a good reason to not accomodate dissabilities by using tabs right now, but I do hope there is a more editor oriented solution some day because I think it would propably be better both for people with visual disabilities and without.

Being in a slightly argumentative mood might have led me down towards validating this false dicotomy between editors and tabs, and I apologize for wasting both our time because of this.

You do have a point that I personally might have more influence over if a given project has spaces or tabs than if better editor features are made, but I think that there can be a point to having the poor support for programming that is apparently offered by screen readers to take some place in the discussion as well since that is a potentially more important piece of the puzzle.

I can’t imagine that there is much of a point to keep replying after this so I think I’ll leave it here.