BB_C

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.^

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.