BB_C @ BB_C @programming.dev

Posts

10

Comments

364

Joined

2 yr. ago

A word of appreciation.

Typst developers are among the best Rust citizens around. Not only do they have a cool project, but they also contribute a lot to the Rust ecosystem at large.

At least use a SIMD load, and maybe someone would find it cool-adjacent.

rationale behind the design principle is the only organizing entity here it seems.

It is worth pointing out however (for "non-techies") that Rust projects have been written by people who love Rust and use it as their main language, love it but can't use it a lot in their employment, like it or are lukewarm about it and used it once or write in it on occasion, don't like it but wanted to experiment with it, hate it but learned it because it could be beneficial to them in some way, hate it but had to use it (usually as a part of their employment).

The success of the language means that not everyone who uses it necessarily even likes it. So not even a "belief" in the design principle can be assumed by all involved.

Good comment.

the framing of it being a “unified, central community” is entirely yours

The explicitness in that part of my comment was deliberate to fully dispel the "really pulled together and made sure" part from the well-meaning OP.

The Rust community really pulled together and made sure that there are Rust alternatives to as many tools out there as possible.

Deliberately or not, with good appreciative intentions or not, I'm afraid you're perpetuating a myth here (a conspiracy theory even, in some "mentally challenged" circles).

Most tools are independently created by individuals, or very small independent teams of contributors. And being an "alternative written in rust" is rarely a goal in and of itself (or shouldn't be anyway).

The notion of a unified central "

<lang>

Talking about Rust itself as a good language with good tooling that allows individuals to create good tools, and contribute to a thriving library ecosystem, is okay. Not everything has to be a "community" or a "community effort" or framed that way, however.

• Use zram devices equal to the number of threads in your system.
• Use zstd compression.
• Mount zram devices as swap with high priority.
• Mount disk swap partition(s) with low priority.
• Increase swapiness:

      
     sysctl vm.swappiness=<larger number than default>
  
    

• Use zramctlto see detailed info about your zram disks.
• Check with iotop to see if something unexpected is using a lot of IO traffic.

Okay. I thought for a moment that you and everyone else were not on the same page.

zram file

what zram file?

lightweight

😑
/me looks inside
/me finds >20 sub-crates and all kinds of dependencies including a web server
/me starting to think i'm the weird one for saving my passwords in a text file and almost getting annoyed about having to use cotp

Brother, some of us already moved from lld to mold to wild already. The project could have waited a little bit, then went with the implemented-in-rust option directly.

Thank you for the update.

Thank you (+ contributors) for doing this work and keeping us posted.

Last time I took a look, I think LTO was broken. Is that still the case?

I always felt "for embedded" was always selling this crate short, or rather pushing potential users away who aren't aware some data structures here are useful in non-embedded scenarios.

I for example use the admittedly simple Deque (with its is_full()) method in one of my projects for pushing/popping tasks to/from a fixed-size thread queue, which one could argue is a very unembedded-like use-case 😉.

Forgot to mention that I wasn't exactly young at the time. We just didn't have reliable broadband internet back then in my neck of the woods. So I had to download ISOs and save them in a USB thumb drive in a uni computer lab.

Early Mandriva with KDE 3.4 or 3.5 I think, but I can barely remember anything with clarity. It couldn't have been bad though, since I haven't used Windows on my own devices since 😉.

From my foggy memory, I think it was good for my then nocoder self, easy to use, stable, relatively lite, and had good looks.

I missed the Mandrake and pre-Fedora Red Hat era, but not by much.

Be realistic. Filling out forms to get CI runners means no serious users will be attracted. They can just go to GitLab instead. And even then, a migration wouldn't be fully seamless.

Those are immediate show-stoppers before we get to contributor pool sizes and network effects.

My purist young self picked Gitorious over GitHub. I even vaguely remember the KDE presence there, so it was a trusted host with big(ish) betters on it. But it closed shop soon after, and that was a quick learned lesson.

I will be more intrigued by the first jj-native forge when it appears. I may even help alpha test it, as it may bring a breath of fresh air to the space, unless it's going to be AI buzz-filled. In that case to the trash blocklist it will go.

Yes. Note that I'm replying to this:

messy Result type just seems like a case of something that should’ve been handled already (or properly propagated up).

My point was that without flattening, "provide context and propagate" vs. "directly propagate" is always explicit and precise, and is obviously already supported and easy to do.

Use with functional chaining, as pointed out by others, wasn't lost on me either. I've been using Option::flatten() for years already, because such considerations don't exist in that case.

(stating the obvious)

You can already :

  rust

    
res_res??;
// or
res_res?.map_err(..)?;
// or
res_res.map_err(...)??;
// or
res_res.map_err(...)?.map_err(...)?;

  

With res_res.flatten()?, you don't know where you got the error anymore, unless the error type itself is "flatten-aware", which is a bigger adjustment than the simple ergonomic library addition, and can become itself a problematic pattern with its own disadvantages.

Result::flatten() is probably my favorite addition

It's rare to a have a negative reaction to a library addition. But I don't like this one at all actually.

For me, error contexts are as important as the errors themselves. And ergonomically helping with muddying these contexts is not a good thing!