Collecting downvotes since before forums even had thank you's.
systemd
Interesting. So they did it two years ago for the
lols.. i mean for theu8"😀"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
systemdhas 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 -Werrorcan 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=c99if 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
// rust eprintln!("{}", "AAAAB" > "AAAAA") // true eprintln!("{}", "Mark" > "John") // truec
// C printf("%d\n", strcmp("AAAAB", "AAAAA")); // 1 printf("%d\n", strcmp("Mark", "John")); // 1strcmp()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 Stringandimpl 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 straway from having something similar (it would be("AAAAA"..).next()).impl Step for charalready 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.
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.pthin the repository really necessary?(I like my--filter=tree:0clones to be maximally fast and small.) - Why not declare all dependencies in the workspace?
- How old is the code (for real)?
rsky-cryptoanyhowin library code.- Not liking that
multibasedependency much either. I know thatbase64at least got re-written since that crate's last update (Nov 6, 2020).
rsky-feedgenserde_cboris long dead (I was a user myself).- I'm not even sure why
serde_cborandserde_ipld_dagcborare dependencies anyway. - We moved from
lazy_statictoonce_cella 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_YEARis meh anyway. But I guess that comes from IPLD.
rsky-identityanyhowin 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-syntaxlazy_staticandanyhowagain.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,
rondoesn'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 😄
I hope that someone in the 40 comments i don't have time to read right now has pointed out that the premise of OP is flawed for the simple reason that Rust hit v1.0 in 2015, while Zig is still nowhere near that milestone in 2024.
So we are not even talking about the same "future" period from the start.
So, no need to get to the second false premise in OP, which is limiting a "future" period to one successful dominating language only. Nor is there a need to go beyond these premises and discuss actual language details/features.
Not only that. We don't just "inject" raw strings with the
syn/quoteduality. Stringified or not, the token tree will be parse-checked into the expectedsyntype before being used in generated code.So the distinction is both wrong and irrelevant. This is what I meant by wrong on multiple levels/layers 😉
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.