i mean, it’s a good fit for a utility like this. starts quick, runs fast, small memory footprint… all the benefits of C/C++ but with modern tooling and a sane type system.
I could understand caring a lot about the language if I were writing or maintaining something, but not usually if I’m just using a software package, unless it has performance implications. Maybe for software that has privilege escalation risk you maybe want a language that might help mitigate some security issues, but launchers shouldn’t fall into that camp.
But, hey, people have their own preferences and opinions. Maybe someone’s super into Rust and wants to try to run as pure a Rust environment as possible or something.
I mean, just to offer you the counter perspective, IMHO programs written in X tend to have problem Y:
Python: Terrible error messages, buggy, sluggish, slow, but good documentation
Java: Gurgles RAM like there’s no tomorrow (but tends to do something useful with it), sluggish
Node.js: Just gurgles RAM for the fun of it, buggy, over-engineered functionality, confusing documentation
Rust: Over-engineered functionality
Go: Bad error messages, quirky detail behavior
Haskell: Practically 0 bugs, but if you do run into a bug, good luck. Thin documentation.
C/C++: Basically no bells or whistles, and no compiled build available. Also stupidly difficult compile on anything, except the singular dev’s PC.
Obviously, these are caricatures, i.e. I’m overdrawing the details and omitting nuance. And these are also influenced by the kind of people that are drawn to these languages. And these are influenced by what I know about the languages, I didn’t conduct a double-blind study.
But yeah, there’s a reason why Python ended up first on that list. I don’t have that hard of an opinion about the others, but genuinely, when I know a non-trivial program is written in Python, I will think twice whether I want to use it. Because it always seems to cost me a non-trivial amount of nerves in the end.
I know you said those are caricatures, but with C or C++, programs usually do have a make or cmake script to be built in 1-3 commands explained in the repo.
I’d have mentioned that their more typical execution error message is “segfault”. Where? Fuck you, that’s where.
Ah yeah, segfault is a good point. And if you get more than that, it’s still often just an exit code and some generic print statement. 🫠
And well, with C/C++ programs being difficult to compile, I was referencing that installing libraries is typically left as an exercise for the user.
If you’re on a similar distro as the dev, it’s usually documented what you need to do. But if not, you get to guess what the library package might be called. Or if it’s available in a compatible version. Or at all.
You just need to hope you get lucky, which should not be a factor in whether software compiles…
Rust is cool, but not the end-all-be-all solution some people have the impression it is.
It’s not all good but the memory management and no undefined state is a huge plus for libraries to have.
I know lol I’m just shitposting based on the C++ post from yesterday
It was CEdit: it wasn’t C; it was C++.
My bad. This is what happens when your brain isn’t memory safe
Naw, it was my mistake. I misremembered it – it was C++.
It was C++.
Huh. You’re right.
i mean, it’s a good fit for a utility like this. starts quick, runs fast, small memory footprint… all the benefits of C/C++ but with modern tooling and a sane type system.
I could understand caring a lot about the language if I were writing or maintaining something, but not usually if I’m just using a software package, unless it has performance implications. Maybe for software that has privilege escalation risk you maybe want a language that might help mitigate some security issues, but launchers shouldn’t fall into that camp.
But, hey, people have their own preferences and opinions. Maybe someone’s super into Rust and wants to try to run as pure a Rust environment as possible or something.
I mean, just to offer you the counter perspective, IMHO programs written in X tend to have problem Y:
Obviously, these are caricatures, i.e. I’m overdrawing the details and omitting nuance. And these are also influenced by the kind of people that are drawn to these languages. And these are influenced by what I know about the languages, I didn’t conduct a double-blind study.
But yeah, there’s a reason why Python ended up first on that list. I don’t have that hard of an opinion about the others, but genuinely, when I know a non-trivial program is written in Python, I will think twice whether I want to use it. Because it always seems to cost me a non-trivial amount of nerves in the end.
I know you said those are caricatures, but with C or C++, programs usually do have a make or cmake script to be built in 1-3 commands explained in the repo.
I’d have mentioned that their more typical execution error message is “segfault”. Where? Fuck you, that’s where.
Ah yeah, segfault is a good point. And if you get more than that, it’s still often just an exit code and some generic print statement. 🫠
And well, with C/C++ programs being difficult to compile, I was referencing that installing libraries is typically left as an exercise for the user.
If you’re on a similar distro as the dev, it’s usually documented what you need to do. But if not, you get to guess what the library package might be called. Or if it’s available in a compatible version. Or at all.
You just need to hope you get lucky, which should not be a factor in whether software compiles…