Well, to reference Julia Evans another time:

head and HEAD are specifically the third meaning of ‘branch’, i.e. the newest commit on a branch, but can also refer to a commit not on a branch, when in that detached head state.

And while I’m not enamored with these names either, I can’t think of a word that I like better for this meaning.

In principle, I agree, but I feel like part of that is just AAA vs. indie.

AAA games need to provide lots of lukewarm content, because many more casual players will buy them and expect much bang for their buck + haven’t seen this lukewarm content a million times already.

On the other hand, indies will basically only be bought by people more enthusiastic about the hobby. As such, they have to pick out one or two aspects and excel at them, so that it’s something new for that crowd.

Hello Games was indie and unknown at the time, so likely only attracted that gaming enthusiast crowd, which would have been more easily bored by the extremely lukewarm content in Starfield.

Normally, I would reply to the guy, because, you know, he’s a human being, but there’s so many replies, I doubt, he can actually read all of them and potentially someone else has already made that point.

Anyways, I feel like something he kind of misses here is that many of us do it from a heartfelt place. Like, we’re all techies. We’ve all used commercial software to a point where we’ve grown so frustrated with it that we decided it is a waste of time.

So, it’s not us saying “Why don’t you go and just have more time/money?”.
Rather, it’s us saying “This thing is wasting your time? Here is a solution that I felt wasted less time in the long run.”.

Yes, sometimes that does miss the mark, because not every complaint is looking for a solution. Or because we may be frustrated with restrictions of commercial software, which are not a problem for less techy people. Or even because we’re embedded in this tech world and are hoping to make it a better place, which someone just quickly visiting may not care about.

But other times, I do just happen to know a lot about technology and a non-techy genuinely did not know about the solution I suggested and is actually really appreciative of me bringing it up. It does happen. And it’s not easy to discern who would appreciate a suggestion and who won’t.

I watched it on my phone in 1080p60 and the scale didn’t bother me. It’s not like I have to read a lot of text and the precise position of the player character is mostly irrelevant, too. Like, if you get hit by a train or something, the screen will flash red and you’ll react to it, too, so I’ll know what’s going on.

Well, and I don’t look at the screen at all times anyways. 🙃

Would like to see more of this journey…

Very weird example to me, with the LLM chatbot video. Like, yeah, interacting with an LLM can be interesting, but you’re not going to learn anything meaningful about it.

And when I jumped into the middle of the video, that looked pretty much exactly as I expected, too. The guy was tweaking the pre-query and then chatting with the chatbot to see how it turned out. So, they didn’t do/learn much coding either.

There is all that surrounding technology, which you are inevitably going to learn something about, but ultimately this is what I find so tiring about LLMs. I can learn something about the surrounding technology and tackle a topic which is meaningfully interesting at the same time. Unless I had a problem which a custom adaptation of an LLM could solve, why would I choose to play with it?

Yeah, I found it quite interesting, too. To some degree, I’ve been wondering why it’s so natural for programmers to be programming language polyglots, even if they’re not actively nerds/excited about them.
And yeah, this discussion made me realize that you basically can’t take a single step in programming without being confronted with multiple languages/syntaxes at once.

Ah, right, my interpretation is that as long as you don’t need to touch the source code, you’re good.

But yeah, it’s certainly not as clear cut. My pick would actually be Rust, because you can use it for pretty much everything, including web frontends via WebAssembly.
However, in that case, you still write HTML+CSS, which technically may or may not be programming languages, and the DOM API is actually only documented in JavaScript. So, I wouldn’t need to write JS, but would still want to read it…

Yeah, C libraries can be used in basically any mature language. It’s just too useful to not have.

And Rust, since it doesn’t need a runtime, can emulate the format of C libraries.
Rust libraries can also specifically target Python via https://pyo3.rs, but as I understand, this just does the C library format, plus a basic Python wrapper to make it nicer to use.

These exist in theory, but as a whole, I’ve never seen them working at even the base level of what you get in other languages.

Adding type hints to your code is fucking exhausting, because there is no type inference.
MyPy regularly calls it quits, when any library doesn’t have type hints. PyCharm regularly doesn’t properly auto-complete, because it doesn’t have type information (if it can load your project correctly to begin with).
Unit tests exist, yes, but you need 100% test coverage to make the language properly check all code paths. Without it, even just calling a library isn’t guaranteed to work. In no fully statically typed language, would I recommend 100% test coverage, unless you have special correctness requirements.

Rust:

• It covers all bases, from embedded to backend to webdev to gamedev.
• I could create libraries with it, which can be called from other languages.
• It’s good.

• Learning multiple programming languages. Each one gives you a glimpse into the problems that some very experienced devs thought were worth solving neatly.
• Switching to Linux. The whole OS wants to teach you about its innards all the time. You can actually debug problems in software you use. And you can script all kinds of things or even start contributing to basically any application. It’s just really good at teaching and motivating programming.
• Explaining things to others. It’s quite easy to have just superficial knowledge in tons of topics. And sometimes, we don’t notice, even if it’s something we do every day. Try to explain to a noob what Git is and you’ll likely struggle, both with the meta description and detail questions. If you then read up on the concepts you couldn’t explain, that will give you a much more complete image of Git and ultimately help you whenever Git becomes more complex.

As I already responded to others, my comment was meant in the context of the question, so I would not learn a scripting language in addition to Bash + a programming language.

For just running commands one-after-another, Bash is basically a minimal encoding, so no reason not to use it.

When you do start to need if-elses, loops etc., that’s where Bash starts to become somewhat difficult to read. And personally, as someone who’s not fluent in Bash control flow, I found it quite useful to do the control flow in my programming language of choice, but still just calling commands like you’d do in Bash.

Of course, this is a non-standard setup, and most target hosts will have Bash pre-installed, not rust-script, so it does obviously make a lot of sense to continue using Bash for what you’re doing.
In general, my comment was meant for programmers. An ops person might know a full-fledged programming language, but still want to learn Python, because they need to write tons of Ansible tasks or whatever.

Somewhat of a weird addendum, but I actually only realized, you could port directly over like that, while writing the above comment.

Now I actually tried it on a 22 lines long shell script that I’ve been struggling with, and holy crap, I love it.

Like, I should say that I have always been (and likely will always be) shit at shell scripting. Any time I wanted to do a basic if, I had to look up how that works.
As a result, even those 22 lines were ripe with code duplication and I always felt really unsure about what will actually happen during execution.

Well, rightfully so. While porting over, I realized I had a bug in there, which has been annoying me for a while, but I always thought, well, it is a shitty shell script. I still remember thinking, I should probably not implement it like that, but then leaving it anyways, because I felt it would become unreadable with the shell syntax.

Now it actually feels maintainable, like I can even easily expand on it.
And I have to say that rust-script is really smooth. I barely notice that it’s compiling during the first run after changing the script file, and it’s fully cached afterwards, so it executes instantly.

I’ll still have to check for libraries that basically provide such a run() function/macro for me, but yeah, basically my threshold for not using shell scripts just dropped to any kind of control flow being involved.

Oh, I didn’t mean to say, you should throw out your shell scripts. For anything less than, say, 20 lines, they’re perfectly appropriate.

I’m saying, Rust et al start to feel like a good choice from, say, 100 lines upwards, and I just don’t think, it’s worth bridging the gap between those two.

In particular, you can build a function that allows you to run commands without much boilerplate, e.g.: run("echo hello | tee out.txt");
(The implementation just appends that argument to Command::new("sh").arg("-c") and runs it.)

That way, you can do the more complex things in Rust, whether that’s control flow or something like modifying a JSON file, without giving up the utility of all the CLI tools on your system…

Personally, I don’t feel like it’s worth learning a separate scripting language when you’re comfortable with a full-fledged programming language.

Python, Lua etc. used to be on a whole different level of usability, when compared to C. But compared to modern, high-level languages, the difference is marginal. Not to mention that at least compared to Rust, they start to look rather antique, too, and lack in robust tooling.

If you don’t feel like maintaining a whole git repo, use e.g. rust-script.

It is definitely possible, yeah. Tailscale and similar don’t do magic either.

I’m not sure on the specifics, though. I think, you want a TURN server or a STUN server.

Yeah, I do agree. It’s tricky for individual PeerTube instances to build up a sufficiently large community and thanks to the magic of federation, we don’t have to build all the community features into PeerTube, like traditional/centralized services do.

In case, you’re not aware, there’s SepiaSearch as a search engine across PeerTube instances…

Gamedev is all about smokes and mirrors. A conventional software engineer will actively resent the shitfuckery you have to do, to make games run well (for good reason; it introduces complexity into already insanely complex systems).

Some performance work, you cannot defer, like fundamental design decisions (3D vs. 2D, raytracing or not) or if you've coded a tiny feature and for some reason, it completely obliterates performance.

But there's always going to be tons of features that have been implemented well, they don't obliterate performance, but if you replace them with an unintuitive/complex smoke-and-mirror solution, then you may be able to shave off 20% execution time for that feature. Or not. Often no real way to know, except to try it out.

Some of these do need to be tackled throughout development, too, but it's easy to end up with a big block at the end of development.
Especially, if you had to rush a number of features that marketing promised, so that you can make the release date that marketing promised many months before anyone has any fucking clue how long it'll take.

I feel like companies were all hoping to get in early, to get a solid chunk of the cake. Well, and then a lot more companies got in than anyone could have guessed, so the slices of the cake are a lot smaller.

We'll have to see what happens, though. It's possible that the startups have to give up and only a few big fish remain. But if those have to increase prices to become profitable, this market will still be a lot smaller than people were hoping for.