Maybe this is a reductionist simplification of it, but his point is basically that, at least in the context of rust, async code is explicit and easy to introduce in a blocking context by simply blocking on it, while blocking code is not explicit about how blocky it is (and it's not a binary), and thus, it's not trivial to know where explicit unblocks are needed in an async context.

Blocking on async code is usually done with some_executor::block_on(), of which some very lightweight implementations exist, combined with the possibility of not requiring that the data's ownership be moved to the executor, nor is the data required to be Sendable to other threads (an executor doesn't have to be a multi-threaded work-stealing one).

Meanwhile, unblocking is done usually via blocking::unblock() or some_executor::spawn_blocking(), and doesn't offer such flexibility.

Someone should write "Leaky Abstraction" arguments considered harmful to finish the circle. Feel free to contact me for advice.

It's more pointless that harmful, but going with the latter is better branding.

systemd

Interesting. So they did it two years ago for the lols.. i mean for the u8"😀"s*...which wasn't even really needed as one of the PR comments pointed out.

* Yes, the mission creep is so bad the shit show that is systemd has emoticons.

I do think it would’ve been worth it to introduce ++ for general appending.

I already mentioned (val..).next() which is both safe* and explicit about it being a generic stepping operation instead of possibly being sugar for {x = x + 1; x}.

Also, calling it "appending" is weird for us folks coming from languages like C 😉

* you don't have to worry about what i32::MAX++ would/should return.

Submit an issue asking for preemptive GNS (Gnu Name System) domain name support, and leave a link to it here.

Multi-threading support

Who stopped using pthreads/windows threads for this?

Unicode support

Those who care use icu anyway.

memccpy()

First of all, 😄.
Secondly, it's a library feature, not a language one.
Thirdly, it existed forever in POSIX.
And lastly, good bait 😄.

whats so bad about Various syntax changes improve compatibility with C++

It's bad because compiler implementations keep adding warnings and enabling them by default about completely valid usage that got "deprecated" or "removed" in "future versions of C" I will never use or give a fuck about. So my CI runs which all minimally have -Wall -Werror can fail with a compiler upgrade for absolutely irrelevant stuff to me. If it wasn't for that, I wouldn't even know about these changes' existence, because I have zero interest in them.

Those who like C++ should use C++ anyway. They can use the C+classes style if they like (spoiler alert: they already do).

I can understand. But why would you not use newer C versions, if there is no compatibility with older version “required”?

Because C doesn’t exist in a vacuum, and Rust exists. Other choices exist too for those who don't like Rust.

My C projects are mature and have been in production for a long time. They are mostly maintenance only, with new minor features added not so often, and only after careful consideration.

^Still^ ^interested^ ^in^ ^knowing^ ^what^ ^relevant^ ^projects^ ^will^ ^be^ ^using^ ^C23.^

That's good and all, but we all explicitly pass -std=gnu99 (or -std=c99 if you don't care about MSYS2 compat) in our build scripts buddy 😉

Okay, maybe not all all. But you get the idea.

Are there any relevant projects who use the increasingly C++-infested newer versions of the language?

The general theme of your comment is good, but the example is...

The string “AAAAA” cannot be said to be greater or less than “AAAAB”

But in general the name “John” is not considered to be higher/lower than “Mark”

// rust
  eprintln!("{}", "AAAAB" > "AAAAA") // true
  eprintln!("{}", "Mark" > "John") // true

// C
  printf("%d\n", strcmp("AAAAB", "AAAAA")); // 1
  printf("%d\n", strcmp("Mark", "John")); // 1

strcmp() docs:

strcmp() returns an integer indicating the result of the comparison, as follows:

• 0, if the s1 and s2 are equal;

• a negative value if s1 is less than s2;

• a positive value if s1 is greater than s2.

So basically, if C had higher level constructs, it would be identical to Rust here.

So, even if it is cool to manipulate strings by using addition/subtraction, it is still bad language design and very unintuitive.

Rust has impl Add<&str> for String and impl AddAssign<&str> for String. Both append as expected.

But maybe you meant numeric addition specifically.

In that case, yes, Rust doesn't have that, although it's an impl<'a> Step for &'a str away from having something similar (it would be ("AAAAA"..).next()).

impl Step for char already exists of course, but shouldn't if we take your argument to its logical conclusion.

Oh, and C would most definitely have this feature if it could. Numerical manipulation of chars is commonplace there.

Can't think of anything.
The novelty must have worn off over time.
Or maybe my mind doesn't get blown easily.

Correct link without /edit/: https://github.com/Nutomic/ibis/releases/0.1.2

Good thing there is no long list of signatories in this one. I had to double-check the open letter when it came out to make sure no one fake-included me there.

Hope the nu crowd are winning their arguments hard.. in their own echo chambers. Because no one else is going to even feel their presence outside of them.

With hyper-threading and preemption in mind, maybe it's concurrency all the way down 😎 . But we should definitely keep this on the down low. Don't want the pesky masses getting a whiff of this.

The only time I took a gander on their repo, I saw the main guy asking ChatGPT how to implement something, and pointing the main dev at the answer.

Also, the pay-per-PR approach, while commendable on the surface, has a very high potential of unwanted behavior sneaking in, intentionally or otherwise, especially when combined with such blasé approach to coding and review.

This is perhaps a case where Rust's superiority lead to questionable net gains. In the sense that if it wasn't for Rust, such an approach would probably never have produced a product that appears, for all intents and purposes, to be perfectly functional, performant, and stable (presumably, I never used it). Rust allowed here, despite the "hard language" stereotype, a Lego model of development to work. But is that at the end of the day a good thing? That's an open and nuanced question.

But hey, it's all open source. If (the collective) you don't like it, fork it and fix it, or pay for the audit, or use something else. Don't expect anyone to shed a tear for your alleged quandary, or become a soldier in your witch hunt.

Yeah. I read the linked explanation by OP.

User repositories is basically how FMS on Freenet (now Hyphanet) works. The big difference is that JSON is used at AT instead of XML 😁. Also, things on Freenet are "content addressable" (what a buzz word) and immutable, always has been.

General data scalability is a part of the Freenet network model. App bandwidth and sync is admittedly not optimal, since on FMS, you basically pull from everyone's feed to your database (bar the ones you distrust, or others you trust their distrust judgment distrust). But that can be trivially fixed by adding watchers split over the keyspace. These watchers can give users metadata about who to pull/update from. This of course was never actually needed since the user-base is small.

So reading about AT, I was left wondering. Is this really innovative? Then I read this part

Our founding engineers were core IPFS and Dat engineers

.. and everything made sense. The masters of pretending they are coming up with new stuff are at it again.

Some shallow observations without really getting into the code:

misc

• Was hosting labeler/ResNet50_nsfw_model.pth in the repository really necessary?
  (I like my --filter=tree:0 clones to be maximally fast and small.)
• Why not declare all dependencies in the workspace?
• How old is the code (for real)?

rsky-crypto

• anyhow in library code.
• Not liking that multibase dependency much either. I know that base64 at least got re-written since that crate's last update (Nov 6, 2020).

rsky-feedgen

• serde_cbor is long dead (I was a user myself).
• I'm not even sure why serde_cbor and serde_ipld_dagcbor are dependencies anyway.
• We moved from lazy_static to once_cell a long time ago. And your use is available in std on stable Rust today.

rsky-firehose

• Here, all three CBOR dependencies are actually used.
• CBOR (the format) used in $CURRENT_YEAR is meh anyway. But I guess that comes from IPLD.

rsky-identity

• anyhow in library code.

rsky-pds

• That's quite the dependency list! Too long for me to take a closer look.
• How many *base* dependencies does one need? All of them of course!

rsky-syntax

lazy_static and anyhow again.

That's all from a code organization and ecosystem PoV. Otherwise, things look normal and not fancy (which is good).

Unfortunately, I don't have the time to look beyond that at this moment.

Your LLM of choice needs better training.

I haven't used either (yet). But as someone who wants to move away from JSON as a configuration format, ron doesn't, for me, offer much of a value proposition. And it's too tied to serde IMHO.

I also like KDL's optional type annotations (yes, I'm crazy that way.).

all the equivalent functionality and how to translate existing concepts over from one language to the other.

Antithetical would be the word to describe this, I think. Although I've seen such titled content.

• Why do you think this is a debugger issue?
• May I suggest you try to learn how to use the rust toolchain directly first?
• The error message looks informative to me. What part of this line did you not get?

   either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present 
  

I think you're tying yourself too close to VSCode. Reading this Cargo guide is a minimal requirement. And you should learn how to use cargo (the command), at least for basic operations. This is not hard. If anything, it's much simpler than those bloated and opaque editor/IDE setups.

🤣

I don't know, and I don't want to get personal. But that's usually a sign of someone who doesn't even code (at non-trivial levels at least)*, and thinks programming languages are like sport clubs, developers are like players contracted to play for one and only one club, and every person in the internet gantry need to, for some reason, pick one club (and one club only) to be a fanboy of. Some people even center their whole personality around such fanboyism, and maybe even venture into fanaticism.

So each X vs Y language discussion in the mind of such a person is a pre-game or a pre-season discussion, where the game or season is an imaginary competition such people fully concoct in their minds, a competition that X or Y will eventually and decidedly "win".

* Maybe that was an exaggeration on my part. Some junior developers probably fall into these traps too, although one might expect, or maybe hope, that their view wouldn't be that detached from reality.

I'm hoping to finally finish and send out a delayed new release for one of my older and mature CLI tools this weekend. It's written in C btw 😄