• 24 Posts
  • 493 Comments
Joined 3 years ago
cake
Cake day: April 27th, 2023

help-circle
  • I don’t agree with the comment there. In my mind, the LTS release would not mean anything. It would just be a label on an arbitrary release every couple of years. I feel it could help the ecosystem align on which MSRV to choose, so that you don’t have one crate choosing 1.x, another chooses 1.(x+1) and another chooses 1.(x+5). It would be nice if we just sort of agreed that if you care about your crate being used by somewhat older compilers, use the LTS version and consider the implications if your MSRV go beyond that version.

    Of course any crate author is free to completely ignore this and choose whatever MSRV they desire. But perhaps a significant amount of authors would put at least a little effort (but not much) in trying to avoid raising the MSRV above the LTS version, just as authors may try to avoid breaking changes and such. It’s just a nudge, nothing more.


  • An LTS release scheme, combined with encouraging libraries to maintain MSRV compatibility with LTS releases, could reduce this friction.

    This actually sounds like a good idea. Currently crates are choosing their MSRV all over the place. If we just got a bit of alignment by calling every ~17th Rust release (roughly 2 years worth of releases) an “LTS” release, then crates could be encouraged to keep their MSRV compatible with that release.

    But we also heard a consistent shape of gaps [in core]: many embedded and safety-critical projects want no_std-friendly building blocks (fixed-size collections, queues) and predictable math primitives, but do not want to rely on “just any” third-party crate at higher integrity levels.

    I think some fixed-size collections and stuff like that would be super nice in core. Something with simple, predictable semantics, just like Vec has (i.e. no optimizations for certain usage patterns, like small string optimizations and that sort of stuff). With const generics working for integers, fixed size collections in core shouldn’t even be that hard (it’s certainly been done in many crates already).





  • It might be because I am in Denmark which has quite a functioning and lawful system and where I see the most graffiti is in public transport, like on trains and train stations. The transport company spends a lot of money cleaning that graffiti, making public transport more expensive for everyone else (hence antisocial behavior).

    So I can understand where you are coming from but my perspective is just different.



  • SorteKanin@feddit.dktoFediverse@lemmy.worldwe need more users
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    10 days ago

    Isn’t this not much better than graffiti? I think advocating for the fediverse is great, but let’s not plaster unnecessary and potentially illegal posters/advertisements everywhere.

    If you want to display an appreciation for the fediverse, perhaps there are T-shirts with the fediverse logo?



  • the goal is so vague that everyone can be on it.

    Could you elaborate on why that is a bad thing? I’m sort of confused why you wouldn’t want everyone to be in on it. To be clear, I don’t think we really need to change the goal, I just think the wording is unfortunate.

    But again, I think we honestly shouldn’t focus on this small disagreement of the words, as long as we agree on the idea itself. We may not agree on feminism or egalitarianism as words, but I think we both agree on the much more important ideas behind it.

    It may also be that I’m coming at this discussion from a Danish perspective, which is very different from an American perspective (I’m assuming you’re american, sorry if that’s not correct). We usually use a word like “ligestilling” which translates as “equality” rather than use a term like feminism.


  • SorteKanin@feddit.dktoComic Strips@lemmy.worldyou are
    link
    fedilink
    arrow-up
    54
    arrow-down
    10
    ·
    21 days ago

    He had a point but he kinda fucked it up in the third panel.

    Tbh I think the term is kind of unfortunate exactly because of this confusion and rebuttal. We would spend less time discussing this if it was actually called egalitarianism or whatever, I feel. People use the “fem” in feminism to make the movement seem unequal. I think the term is just kind of unnecessarily confusing and egalitarianism would be less ambiguous.

    But I don’t really care that much, the ideas behind are obviously more important than the word we use - but words are also important.


  • Fediverse platforms are not in competition with each other. In fact, it’s more like symbiosis. There’s no problem with having 15 or even 100 fediverse platforms.

    Why do you need a culture shift if anyone can just pick whatever platform they personally prefer? If you want a certain cultural approach, then feel free to use a fediverse platform with that approach, but there’s no need for anyone else to follow the same choice, unless they want to.


  • I think the author brings some interesting points, but ultimately I think it’s a faulty premise.

    The fediverse is whatever the user wants it to be. That’s the whole point really. If you want a reliable communications platform with zero dropped messages, aka email 2.0, then you can definitely build that on the fediverse and people can join such a platform if that’s what they want.

    If that’s not what you want… Well then don’t join such a platform. Join another one. You do you.

    We don’t need anyone telling us how to communicate or consume content or whatever we want to do with the fediverse. The whole point of the fediverse is that everyone gets to decide for themselves, so there’s no need to be prescriptive about any one approach.





  • This is the way with modern software engineering, especially in the industry. It comes from the basic fact that:

    1. Companies want to get code for free from the internet - someone else already wrote that code, let’s use it for free and have better profit margins!
    2. Companies do not want to spend time and effort vetting that free code, as that would make it… well, not free. That would require manpower (perhaps unless you trust AI to do it these days…) and that’s money.

    Basically they want to eat their cake and have it too. This applies to all modern package managers for modern languages that make it easy to distribute your own code and consume free online code.

    I doubt the industry will ever mature to a point where this will stop, as the tradeoff of getting free code with no work is just too good for most companies, especially the smaller ones.



  • I think that’s quite harsh. As I said, I know it’s not what OP asked and it was just a suggestion. I’m just adding it as an option. Perhaps someone else reading the thread will find it useful, if not OP (who I don’t think you should speak for).

    OP mentioned they want native speed and were struggling with badly documented libraries. I feel like it was appropriate to at least mention Rust, considering those two things. Since when is widening a discussion slightly considered bad? You don’t have to reply to my comment either, if my comment does not seem interesting to you. Let alone downvote it. You can just leave it alone, it doesn’t hurt anyone.



  • I know it’s not really what you’re asking, but have you considered learning Rust? In many ways, Rust is more similar to C than C++ and is just as capable. There are quite a few very well documented (as is common in the Rust ecosystem) Rust libraries for GUIs, including efficient native ones or immediate mode ones and such. Just a suggestion.