As the other comment said, outside the browser WASI is what does IO. As for DOM access in the browser, I doubt they want to reimplement the DOM API, because:

• It’s insanely complex. This wouldn’t be done within one release, but rather take years to add a substantial amount of APIs.
• No one wants to have to maintain two versions of the DOM API documentation. You’d need to basically translate the entirety of MDN to some WASM API description. And in the end, hardly anyone would read it either way, because they’re likely using some wrapper library to interact with the API.
• If you’re using such a wrapper library anyways, it hardly matters to most people, whether this library generates JS API calls or some WASM API calls.

I try to stay as far away from JS as possible, and I do not think it’s worth developing a WASM DOM API. With a competent framework, you can develop complex web-UIs without ever touching JavaScript, which is good enough for me.

Yeah, part of the reason I like open-source. The devs don’t need to sell you anything, so they can just tell you that what they made is a steaming pile of garbage.

Jujutsu is a Git frontend, from what I understand, much like there’s tons of Git GUIs. So, you interact with it in a different way, but you still push to a Git repository and others can interact with your code by using Git.

I guess, it somewhat lessens the grip of Git, because they can hook different backend services (e.g. Subversion, Mercurial, Fossil) into this frontend, and from what I understand, they plan to develop an own backend eventually. But yeah, for now, the communication standard is still Git.

somewhat logical, but entirely in practice verb-noun command structure.

That’s supposed to be “impractical”, not “in practice”, for others reading along.

For example, the “proper” command to list a directory is: Get-ChildItem
The “proper” command to fetch a webpage is: Invoke-WebRequest https://example.com/

In these particular cases, they do have aliases defined, so you can use ls, dir and curl instead, but …yeah, that’s still generally what the command names are like.

It’s partially more verbose than C#, which is one of the most verbose programming languages out there. I genuinely feel like this kind of defeats the point of having a scripting language in the first place, when it isn’t succinct.
Like, you’re hardly going to use it interactively, because it is so verbose, so you won’t know the commands very well. Which means, if you go to write a script with Powershell, you’ll need to look up how to do everything just as much as with a full-fledged programming language. And I do typically prefer the better tooling of a full-fledged programming language…

I’ve been trying to basically build a library that helps you put together a distribution archive.
And my initial plan for the API looked something like this:

Distribution::new("my-program")
    .dir("assets")
    .file("favicon.png", |path| build_favicon(path));  // "|path| ..." is a lambda function that gets the target path passed in

So, it would allow you to define the file structure, and for the parts that actually need to be built, you’d provide a lambda function, which it would automatically run or not, depending on whether the inputs changed.

Right, inputs, what are those? I kind of need my user to tell me. So, I decided to implement the caching as a separate API, which you would call on your own when you get called by the lambda function.

Then I realized, I kind of don’t need the lambda function then. I could just construct file paths and then my user calls their build_favicon(...) function or similar on their own.

There is just one crucial problem with that. This is what the path API in the stdlib looks like:

PathBuf::new("my-program")
    .join("assets")
    .join("favicon.png");

I might not have built anything, really. 🫠

Yeah, fair enough.

Depends on the distro how that alias is defined (if it is defined)…

I just want to say that you’re probably worrying too much about it. Of course, there is lots of things one can do to improve security (which the others here are listing dutifully) and it is foolish to just assume that one’s computer is entirely secure, because as a user, you will always have the ability to bypass that.

But there’s a pretty firm consensus in the IT industry that Linux is more secure than Windows. And that the popular Linux distributions are more trustworthy organizations than Microsoft.

So, it’s good to inform yourself, but if you survived on Windows, you at least should not worry about the Linux side of things. It’s more than fine.

Fish is not the worst in this regard, because:

• The defaults are pretty good, so you don’t typically need a config file for it to be usable.
• As of version 4.0, Fish is (experimentally) available as a single executable for download from their GitHub page. So, even on hosts where you can’t install anything, you may still be able to copy that executable file onto there and use it.

But there may still be situations where it’s annoying, like if you’re working in a container, then you likely don’t want to mount your fish executable every time.

But I also have to say I don’t find it too big of a deal.
I still use Bash for scripting (just throw a #!/bin/sh or #!/bin/bash at the top of your script, like you should anyways), and then for interactive use, not that much of the shell syntax comes into play anyways.
And if I ever do need to copy a complex Bash command into an interactive shell, I can just run bash, then run the command in there and then exit back out.

Eh, as much as there’s obviously folks who use certain distros for the fun of it, the vast majority of distros get created to cover a specific use-case. If you have that use-case, then deploying the respective distro brings you so much closer to your target setup than the easy installation of a noob distro could save you time.

I also have to say, many stereotypical noob distros make extremely conservative choices, which makes them harder or scarier to use in various ways, like for example not having filesystem rollback. I cannot imagine going back to that, specifically because I have shit to do.

Ah, fair enough. Not sure how to do that then.

I was gonna say, I feel like the current method does a good enough job documenting that validation has happened, but I guess you do want it reflected in the structure of the type, so that the code that takes the information from the struct can safely make the assumption that some of the options don’t exist. And then, yeah, it would be nice to not need a separate parsing step for that.

Clap has dependent options and mutually-exclusive argument groups built-in: https://docs.rs/clap/latest/clap/_derive/_tutorial/index.html#argument-relations

For the environment-specific requirements, you can use compiler feature flags…

Yeah, a few years ago, a friend handed me their iPhone to see, if I could find an option they were looking for. And I was genuinely appalled at how slow everything felt, solely due to the animations. Like, iOS has objectively better UI performance, but then they chose beautiful over usable with the animations and that makes it feel worse in many ways.

Mint’s desktop environment, Cinnamon, is technically based on GNOME Shell (i.e. a fork of it), but we’re not just talking “pretty heavily modified”. In many ways, it’s its own thing now and you can’t really assume things to work similarly.

Probably the very same thing that the post talks about, which is extracting the first word of a line of text.

The output of md5sum looks like this:

> md5sum test.txt
a3cca2b2aa1e3b5b3b5aad99a8529074 test.txt

So, it lists the checksum and then the file name, but you wanted just the checksum.

It’s a Linux command-line program (awk). It’s pre-installed practically everywhere, it’s very powerful for string processing, but it also uses a fairly complex syntax.

As a result, not many people know how to really make use of it, but awk '{print $1}' is something you encounter fairly quickly when you need to get the first word in each line.

Just imagine working in that position. They’ll give you some massive, unrefined programming problem on day one and tell you to work on that when no users or hardware need help.

Three months later, they start asking why the massive, unrefined programming problem isn’t solved yet, when you had practically no time to work on it, because they probably should’ve hired a person each for helpdesk and IT.

My guess is that he was using cargo build rather than cargo build --release. Relatively common for folks to complain about due to that, because beginner tutorials tend to skip that info (which is fair IMHO).

Yeah, cargo build produces a debug build and cargo build --release is for actually distributing to users. (It doesn’t add the debug symbols, but also spends more time optimizing.)

The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow.

Dude what? C’s build systems like cmake are notoriously unfriendly to users. Crates make building trivial compared to the ridiculous hoops needed for C.

I wouldn’t be surprised, if the guy does not normally use a build system to begin with. Professors don’t tend to have the time to write software that would require a build system (both in terms of complexity and being used by end users).

So, I’m guessing, all he wanted was rustc, but most Rust tutorials don’t bother explaining it, because cargo isn’t much harder to use.