BatmanAoD

joined 2 years ago
[–] BatmanAoD@programming.dev 1 points 1 hour ago

Fair, but it's one that the typical tools for finding bugs, tests and static analysis, cannot actually help with.

[–] BatmanAoD@programming.dev 1 points 4 days ago

Desktop Linux is still an extremely niche userbase, even with SteamOS and Microsoft doing its absolute best to aggravate users.

[–] BatmanAoD@programming.dev 2 points 1 week ago

Believe me, whitespace-correct scripting is absolutely an issue.

You're right that it's annoying when filenames diverge right at a character that must be escaped.

[–] BatmanAoD@programming.dev 7 points 1 week ago (2 children)

For interactive use, tab-completion essentially makes this a non-issue, because shells add escaping in the appropriate places.

For scripting, where spaces are harder to deal with, unfortunately there's just not much you can do; your two options are basically to learn all of your particular shell's patterns for dealing with whitespace in filenames, or only write scripts in something other than a POSIX shell.

[–] BatmanAoD@programming.dev 2 points 1 week ago

Here it is:

Presumably, it already used SIMD, and that's how the existing GNU utility beat Rust by a factor of 17x.

[–] BatmanAoD@programming.dev 2 points 1 week ago (1 children)

Presumably, it already used SIMD, and that's how the existing GNU utility beat Rust by a factor of 17x.

[–] BatmanAoD@programming.dev 4 points 2 weeks ago (1 children)

That's fair; Python, Swift, and most Lisps all use or have previously used reference-counting. But the quoted sentence isn't wrong, since it said no "garbage collection pauses" rather than "garbage collection."

[–] BatmanAoD@programming.dev 6 points 2 weeks ago

"Garbage collection" is ambiguous, actually; reference counting is traditionally considered a kind of "garbage collection". The type you're thinking of is called "tracing garbage collection," but the term "garbage collection" is often used to specifically mean "tracing garbage collection."

[–] BatmanAoD@programming.dev 3 points 2 weeks ago

What's wrong with the explanation given?

[–] BatmanAoD@programming.dev 5 points 2 weeks ago

...the rest of it explains the context, and then briefly says that some people will disagree with the decision, but those people should just use a different distro. What are you complaining about?

[–] BatmanAoD@programming.dev 8 points 2 weeks ago (3 children)

To be fair, the drop/dealloc "pause" is very different from what people usually mean when they say "garbage collection pause", i.e. stop-the-world (...or at least a slice of the world).

[–] BatmanAoD@programming.dev 2 points 2 weeks ago

You could also just alias find back to ^find. I don't use nushell as my daily driver for other reasons, and I agree with the comment above that it's a bit questionable for them to have a built-in with that name, but I don't understand why you'd even try out a new shell, let alone one that's radically different from POSIX-style shells, much less complain online about the shell you just tried, when you're already happy with the shell you're using and are not willing to adapt any habits or explore the configuration options to match your needs.

30
submitted 2 years ago* (last edited 2 years ago) by BatmanAoD@programming.dev to c/rust@programming.dev
 

Almost five years ago, Saoirse "boats" wrote "Notes on a smaller Rust", and a year after that, revisited the idea.

The basic idea is a language that is highly inspired by Rust but doesn't have the strict constraint of being a "systems" language in the vein of C and C++; in particular, it can have a nontrivial (or "thick") runtime and doesn't need to limit itself to "zero-cost" abstractions.

What languages are being designed that fit this description? I've seen a few scripting languages written in Rust on GitHub, but none of them have been very active. I also recently learned about Hylo, which does have some ideas that I think are promising, but it seems too syntactically alien to really be a "smaller Rust."

Edit to add: I think Graydon Hoare's post about language design choices he would have preferred for Rust also sheds some light on the kind of things a hypothetical "Rust-like but not Rust" language could do differently: https://graydon2.dreamwidth.org/307291.html

view more: next ›