Open Source Software Community - it's about ethics in Code of Conducts

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
oh wow they added more i remember when it was just
c,c++,fortran, ada
Yeah. They have a gcc front end for rust as an alternative to the llvm based compiler. From what I've heard it's come a long way. Although I'm not sure if it's 1 to 1 with the default llvm rust compiler at this point. I haven't tried it myself, and I'm just trying to make myself learn rust in my extra time in between whatever other little projects I want to work on. Maybe if I git gud at rust I'll give it a go.
 
Yeah. They have a gcc front end for rust as an alternative to the llvm based compiler. From what I've heard it's come a long way. Although I'm not sure if it's 1 to 1 with the default llvm rust compiler at this point. I haven't tried it myself, and I'm just trying to make myself learn rust in my extra time in between whatever other little projects I want to work on. Maybe if I git gud at rust I'll give it a go.
Rust is a fine little language for certain type of smaller, simpler projects. The only issue is that if there are any questions or you want to ask about style, best practices or advice you will have to engage with the community.
That is the main reason I stay away from rust. The fear that at some stage I would have to engage with the community.
The whole thought of that makes me reject the ;language in full.
 
Rust sucks ass to do anything thats beyond a TUI in my experience. I have a coworker who is a huge Rust fanboy, and so I sometimes humour him by trying it out for some of my ideas. Every time I have tried, the things I want to do seem to touch all the pain points of Rust. Oftentimes I am not exactly sure what my implementation is yet, so the borrow checker makes my life hell instead of letting me shit something out then fix it later. The crates I get told are good are five years old and lacking modern features (this happens all the time in GUI crates), or are just straight up not finished. When I tried to make an API for a service, I got pointed to three different crates, one was feature complete but supposedly abandoned, another was the new community favorite, but overcomplicated everything as it was geared more for huge projects, and then there was a third crate at version 0.1, that seemed to do what I wanted to do based on the source code, but had nothing for documentation other than the auto-generated documentation that describes nothing about how to use the crate. As if the function declaration and name is enough to guess what the function does, which in my experience is never the case because modern Rust writers always name their shit the most retarded way possible. Maybe its just a skill issue, but I don't have the same problem with any other language.

Meanwhile in the C++, Python, and even Java world, most of the libraries I want to use have "getting started" sections that will lead you through a basic Hello, World! implementation so you know how the whole thing fits together, and often times the documentation includes human readable text about what each function or class achieves. I guess if a program never gets written in the first place, its memory safe by default, so I guess Rust is doing its job there.
 
Yeah. They have a gcc front end for rust as an alternative to the llvm based compiler. From what I've heard it's come a long way. Although I'm not sure if it's 1 to 1 with the default llvm rust compiler at this point. I haven't tried it myself, and I'm just trying to make myself learn rust in my extra time in between whatever other little projects I want to work on. Maybe if I git gud at rust I'll give it a go.
I dont know if its still the same but the main difference between gcc rust and llvm rust is different optimizations because gcc does a lot of wild things to the AST due to legacy code.

one was feature complete but supposedly abandoned, another was the new community favorite, but overcomplicated everything as it was geared more for huge projects, and then there was a third crate at version 0.1, that seemed to do what I wanted to do based on the source code
oh god they brought the worst aspects of nodejs to the already messy language.
 
oh god they brought the worst aspects of nodejs to the already messy language.
Thats a great way to put it, and to expand on that thought because now you have me thinking back on all the time I wasted trying to do anything with the language I have to complain some more.

In the Rust community they swear by the Learn Rust "Book", where it goes over the standard way to do things over about two dozen chapters or so. The problem is, the community has now standardized on all these crates to add so much complexity to the language you end up using about half of the chapters if even that. The chapter on error handling is totally useless, because everyone uses a new "improved" crate for error handling. The chapter on async programming is effectively useless because everyone else is using some overhaul crate to add their own special async. You cannot avoid these community crates, because the moment you want to use a web framework or something of moderate complexity, it will require the use of these "overhaul" crates. (And those overhaul crates will require other crates, and now you suddenly have a thousand dependencies for a simple program.) God help you if the crate you are trying to use handled errors with crate A, and then another crate you are trying to use handled errors with crate B, you're fucked.

The best thing I can compare it to is like having someone learn C++98, then throwing them into C++20 right after they finish writing toys and want to work on something useful. Sure its the "same language", but the changes are enough to throw a beginner off. Unlike C++ however, the Rust community will give you the fluoride stare the moment you say "I don't really want to use anyhow or tokio in this project." I guess I'm retarded for trying to match the error type like how the fucking book said I should, oops I should have realized there are a dozen things I have to replace that knowledge I JUST learned with the "correct" way instead.
 
In the Rust community they swear by the Learn Rust "Book", where it goes over the standard way to do things over about two dozen chapters or so. The problem is, the community has now standardized on all these crates to add so much complexity to the language you end up using about half of the chapters if even that. The chapter on error handling is totally useless, because everyone uses a new "improved" crate for error handling. The chapter on async programming is effectively useless because everyone else is using some overhaul crate to add their own special async. You cannot avoid these community crates, because the moment you want to use a web framework or something of moderate complexity, it will require the use of these "overhaul" crates. (And those overhaul crates will require other crates, and now you suddenly have a thousand dependencies for a simple program.) God help you if the crate you are trying to use handled errors with crate A, and then another crate you are trying to use handled errors with crate B, you're fucked.
Kind of good to know as someone that was going through the book, and some of the other recommended learning material. I stopped about half way though to go back to working on some other projects I have in C, but I plan to go back and finish when I have some time. I guess it's mostly good to know what my expectations should be.

It is pretty obvious tokyo is just the standard way to do async that seems to have been adopted by the rust trannys, even for someone like me that hasn't even got to the point of looking into the libraries that are available I already know from seeing it talked about, and using some rust programs. Every single thing using rust has tokyo or some version of tokyo. At least at this point it seems unavoidable. I kind of wonder why it hasn't just been adopted into the standard library if EVERYONE uses it. At least then it would just be the standardized approach and probably cut down on some of the situations like you mentioned.
 
well at this point what is the difference between Cargo and npm?
About a decade of addressing security issues. Bad as NPM is, it's light years ahead of Cargo in that regard. I always found it amusing they named it that, given it's a cargo-cult of the NPM and Python package ecosystems to begin with. Maybe they thought they were being clever.
 
SELECT 'I was one of those assholes.' AS confession;
To solve this mystery, let me add that it used to be called the Structured English Query Language at first, therefore, simply calling it sequel was a viable way to remove the cumbersomeness of having to spell out a four-letter acronym. Once they removed the English from the name, it suddenly became reduced to a three-consonant abbreviation which made calling it sequel appear weird and unviable.
 
Last edited:
I see no place for Redot tbh. Just make a game in Godot and piss the tranny devs off, they can't do anything about it.
1772938233526.png
Full announcement: https://blog.redotengine.org/2026/03/03/rex-v0-0-1-is-here/

How they come off

kissing-vaggie.gif
 
>First "Big change" is installing a plugin you can easily get through the asset store built into godot
>Performance improvements can't be verified to come from them because there is no source code for rex and no recent pull request for redot LTS mentions anything regarding that.


I'm betting 90/10 they've done nothing and are cherry picking godot pull request that haven't yet made it to a stable release, especially since for some reason they are comparing themselves to godot 4.5.1 instead of the month old 4.6 release, which claims they "doubled-down effort on performance optimization."
 
>First "Big change" is installing a plugin you can easily get through the asset store built into godot
>Performance improvements can't be verified to come from them because there is no source code for rex and no recent pull request for redot LTS mentions anything regarding that.


I'm betting 90/10 they've done nothing and are cherry picking godot pull request that haven't yet made it to a stable release, especially since for some reason they are comparing themselves to godot 4.5.1 instead of the month old 4.6 release, which claims they "doubled-down effort on performance optimization."
Even Blazium is more interesting than Redox, it's just classical grifting.
 
Back
Top Bottom