Yes exactly - those URLs contain the domain name, so you can’t change servers for a user as their ID is tied to the domain.
Yes exactly - those URLs contain the domain name, so you can’t change servers for a user as their ID is tied to the domain.
The borrow checker
This is indeed pretty unique.
the way it handles exceptions and nulls
This is really just the fact that Rust has sum types - but those kinds of types have been used in many functional languages (Haskell for example) for a long time.
the way it handles stack/heap
This is just the same as C and C++ and any other low-level language that requires you to distinguish between the stack and heap.
composition pattern instead of oop
I mean if you’re only looking at OOP languages then this will be new, but functional languages have done this for a long time.
So yea, I think a big part of what makes Rust great is that it has managed to take these really, really good ideas from functional programming languages and made them work in a language that is not entirely functional. This leads to a perfect blend/best of both worlds with regards to OOP and functional programming :)
I honestly think they’d understand it about as much as they’d currently understand it - that is, not understanding it very much at all. So I think it would be about the same level of understanding but it would make a lot more sense and would be easier to calculate with.
It’d also remove a lot of incentives for squeezing your income/pension contribution to align with certain thresholds (i.e. tax bracket thresholds).
For example, a sigmoid function (click link for equation). You’d need to mess with the constants to align the function with a range of incomes but the general shape will be the same - a low, almost-zero taxation rate for those who earn the least, rising to a threshold (perhaps even 100%, but a lower value like 75% would probably work as well), giving a high taxation to those who earn the most.
Honestly I don’t trust these old, slow standards organizations to do well at designing programming languages.
Rust has strong backwards compatibility guarantees so it definitely should.
If there is anything I’ve learned in my 10+ years as an engineer, it’s that there are no good or bad languages, just pros and cons of each in different applications.
I dunno if I agree really - the more languages I’ve learned, the more I see an evolution from less sophisticated, less usable languages to more sophisticated, more usable, modern and just generally better languages.
C and C++ are old, and you can tell. There’s so much complexity and legacy in those languages that it’s crazy. But it’s not just legacy - it’s also bad design choices. There’s a lot of really bad APIs and bad usability and footguns everywhere. You see the same thing in languages like JavaScript (whose design journey has been fraught with peril). Even Java has some bad stuff I would say, mostly from the overzealous insistence on OOP.
However, if you look at some modern languages that were more deliberately designed, you really start to see how they are just intrinsically better. Python, while still being a dynamically typed scripting language which I would never use for large systems, is still leagues better than JavaScript in terms of design and usability I would say. Haskell was born from research and you can really tell - the language just makes sense in a very scientific way - although that does mean ease of use and developer experience has not always been the priority.
Rust was developed for a very particular purpose, basically to provide the same speed as C++ but without any undefined behavior. From that design principle, a lot of good has resulted and Rust is basically an objectively better language than C++. The only thing still keeping C++ in the game is the historical reasons, just due to the sheer amount of code that exists out there in C++. C++ has more support in all kinds of places, but that’s just due to history and Rust will likely gain ground soon enough. For instance, C++ still rules for game development, but this could change within the next 5 or 10 years.
It’s not that surprising when you think about - languages like Python, Haskell and Rust were built on the giant pile of experience the whole industry has amassed from using previous languages. It also helps that we just have more computing power today to make languages like Rust feasible. Rust compile times probably wouldn’t have been realistic 30 years ago.
Which foreign concepts do Rust use? The borrow checker/ownership is new but that’s really the only thing that doesn’t already exist in some other language.
Okay, but that is not how the fediverse/Lemmy works at all and I don’t think Nostr works that way either. You can easily see content that you did not explicity ask for (i.e. comments/posts from any user) and I don’t think Nostr is different in this aspect (though I could be wrong).
When I make the analogy, I just mean the fact that a Gmail account can send emails to a Yahoo account or any other email provider. In the same way, a Feddit.dk account can talk to a yiffit.net account. There is not a single company controlling email and there is not a single company controlling the fediverse. That’s really all there is to the analogy.
I mean I don’t disagree, but that’s clearly not what Nostr means when they say censorship resistent, cause by that logic, Gmail and Facebook are as censorship resistent as Nostr is.
I don’t think there really is a great difference either. Censorship and moderation are just two perspectives on the same thing. One has bad connotations, the other generally good connotations.
I honestly think it stills explains it pretty well. Most casual users will not download a specific client and will be fine with the whole idea of an instance being tied to its user interface. It still explains pretty well that it doesn’t largely matter what instance you sign up for and that any instance can talk to (mostly) any other instance, just like with email.
So yea, I still think it’s a good analogy. It’s not perfect but yea, that’s to be expected from an analogy.
The problem as I understand it is basically that user IDs in ActivityPub are intrinsically tied to the domain on which the user registered, so you can’t really move a user from one domain to another.
Censorship-free implies that moderation is impossible. If you don’t have moderation, your social media will turn into a Nazi bar.
you can just hide messages from selected users in client
That’s not good enough. First of all, users don’t want to have to block people before having a good experience. Users don’t want to deal with moderation themselves, but they also don’t want mean people, harassment and nazis. It’s not easy to recruit moderators for online forums, not a lot of people want to deal with that stuff.
But secondly, client-level blocking is not effective. It does not stop those bad users from continuing their bad behavior. In the case of Lemmy, it also doesn’t stop their votes from still affecting your feed.
So yes, censorship-free platforms are not good because censorship-free means moderation-free, and users don’t want that.
Yea moderation becomes a big problem once you can’t actually block people. I don’t like that Nostr describes itself as censorship resistent or even censorship free, that’s not a good quality.
This isn’t really Lemmy’s idea of federation, it’s just ActivityPub, the underlying protocol. Having a mechanism for jumping servers is unfortunately quite complicated and it isn’t clear how it should be done or if it is even possible.
Lemmy does allow you to export and import your settings though, so you can kinda do it but you lose your history.
I’m not speaking against progressive taxation, I’m saying the brackets should be continuous so there aren’t any sharp turns in taxation. Right now the brackets make the taxation discrete, but I feel it should be continuous.
A continuous bracket could be defined by a single equation. You’d plug in your income and you’d get out your taxation. No need to look up what bracket you are in.
Why? To me it’d be much more intuitive. I find brackets quite confusing
Well no they can’t, because that’s not part of ActivityPub. In fact ActivityPub mandates HTTP URLs. Of course, any extension can choose to change that, but since nobody is actually supporting magnet links, it’s not relevant.