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?

This comment is probably the most interesting (from the PR that was already linked): https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102

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.

I do think the unnumbered variant of such anonymous parameters is useful, if you’ve got a team of devs that knows not to misuse them.

In particular, folks who are unexperienced will gladly make massive multi-line transformations, all in one step, and then continue blathering on about it or similar, as if everyone knew what they were talking about and there was no potential for ambiguity.

This is also particularly annoying, because you rarely read code top-to-bottom. Ideally, you should be able to jump into the middle of any code and start reading, without having to figure out what the regional abbreviations or it mean.

You mean vscodium? VS Code is not OSS…

I think, the point is that in Python (like Rust) that construct is a module. In Java, a module does not exist in that sense. You put everything into classes in Java and static classes, i.e. singleton objects, are what you use instead of modules…

Wow, man, I forgot just how object-oriented Java is. You’ve got all these services pretending to run independently, except they’re not actually running asynchronously, and every service has a pointer to all the other services they need to talk to, leading to a huge tangled net of cross-dependencies. That’s why everything needs to be an interface, so you can mock it in tests.

Rust is a lot more …tree-shaped, with the main passing data into functions which call other functions and those return data, which can be passed into the next function.
Obviously, you can also build services running independently, but it’s usually done a lot more intentionally, by spawning own threads, passing around an (explicit) Arc, and then because you’re actually running asynchronously, you do need mutexes and such…

We built a whole quality assistance software to prevent human error in manufacturing. After political non-sense, the project got essentially cancelled when it just started to become useful.

We did ship it for one use-case, though. That use-case doesn’t monitor human labor. Nope, they have robots that were supposed to be more reliable than humans and now we’re quality-checking those robots.

How is that the use-case where we’re most needed?

I enjoy it a lot. It’s the first time that I find frontend actually fun.

A lot of the memory management aspects of Rust are bypassed by Leptos, so that doesn’t come up as much as one might think.

And I do find Rust’s type system really helpful for actually portraying the UI state. For example, if you execute a function that can fail, you don’t have to catch some exception and then pass the error message separately into the UI or whatever.
Instead, you get a Result-type from that function, which contains either the data you want to render in the UI or the error information you want to render instead.

So, you can just pass that right through to your rendering code. And then there’s pseudo-HTML inline in the code, where you can do full-blown Rust-pattern-matching to properly handle such a Result-type and simply render the appropriate UI element.
No horrid multi-line ternaries, no uninitialized variables, no separate boolean checks before accessing a variable. You simply know at all times what information is actually available.

What’s also really nice with backend and frontend in the same language, is that you get compile-time-guaranteed compatibility between them, because you can simply use the exact same model types and API route constants.

It is still a relatively young ecosystem, so there are still breaking changes every so often. And well, obviously you won’t find anywhere close to the number of UI component libraries as you can find for JS. So, for an experienced JS dev, it is likely a step back in productivity.

But if you’ve got Rust expertise instead or only backend folks on your team, then I heartily recommend it.

Rust in the backend and frontend, via WebAssembly. I’m using the Leptos framework for the frontend.

Wow, I’m so happy about those panic message improvements. With the formatting before, most users’ brain probably already melted while reading thread 'main' panicked and the custom message looked like it was just more tech lingo in the middle there.

In reality, that custom message is often the only info relevant for users, and really the most useful info for me, too.