Programming thread

Generally, when you work with other people, you aren't supposed to rewrite what they did unless you absolutely need to.
Companies also sometimes have rules about languages you can use.
These are both non-sequiturs, unless what you would "rather use" use is simply what your boss wants you to use. There are plenty of reasons to prefer c(++), but "companies sometimes have rules" is not very compelling.

I'm pretty sure we do have pinned crate versions
In this case there is no reason for you to complain about crates in production having "open bug issues".
Also, using crates.io in "production" at a large company is dubious. Using it without pinned versions is insane and I have never even heard of this.

To name a few:
You provided one, perhaps two *specific* grievances. It is difficult to say anything meaningful to criticism of 'almost all "opinionated" projects'.
I think you can not point to any instances of your perceived problems manifesting in a serious way, much less demonstrate systemic "hostility".
Saying "one of the most famously hostile communities in CS" is an extraordinary claim, with no evidence provided.
I find the language/compiler is set up in a way where it will constantly fight you on stuff that has little to do with memory safety (e.g. stylistic choices).
I would love specific examples of this.
 
These are both non-sequiturs, unless what you would "rather use" use is simply what your boss wants you to use. There are plenty of reasons to prefer c(++), but "companies sometimes have rules" is not very compelling.

In this case there is no reason for you to complain about crates in production having "open bug issues".
Also, using crates.io in "production" at a large company is dubious. Using it without pinned versions is insane and I have never even heard of this.
Tell me you've never worked at a large company without telling me you've never worked at a large company. You would be surprised at how proscriptive things can be in companies like this, and when you have a multi-million line codebase and a bunch of tooling set up for one language and 100+ other people working in that language, the company absolutely wants you to use that language. In this case, the company has a bunch of Rust code and "cares about security" so they would rather use shitty Rust than well-engineered C. Any C or C++ code will get auto-rejected unless you go through bureaucratic hoops to get it custom approved.

Using crates.io with pinned versions is also very common at large rust shops. They have no realistic other choice. The standard library of the language is too small to functionally use it without reaching out to crates.io for stuff. Generally, if a crate version hits a bug you care about, you will just update the pin to the version without the bug. This is also how JS shops use NPM and Python shops use pip. It's common practice.
 
Tell me you've never worked at a large company without telling me you've never worked at a large company.
This was largely my response, too. I implemented a requested feature in the wrong language once (leveraging/expanding code that was currently in production!) and I never heard the fucking end of it, mostly because my manager at the time had become a nocoder and had literally no idea what I did beyond what reports he could get from others on me.
 
Where I work everything is stored in JFrog artifactory. And there is no concept of just choosing what language you want.
Only Architect could decided something like that. I cannot even look up any libraries myself, they have to be first prepared by special team, that I need to send request for.
It is funny sometimes, because sure there it's supposed to be single Java framework, but it has like 5 different JSON libraries that are approved and part of it. :story:
So much for consistency.
 
Can you post them?
Nigga...

I would love specific examples of this.
I literally gave a specific example in my previous post's quotes. See if you can find it. Regardless, I'm not going to play this autistic game of hunting down examples you deem worthy of consideration.

I don't like the language for the reasons I provided, among others. I'm not going to cite sources at the bottom for shit like this. Bing it if you care that much.
 
Tell me you've never worked at a large company without telling me you've never worked at a large company. You would be surprised at how proscriptive things can be in companies like this
I do not disagree at all about "rewrite it in rust lol" being bad. I wish you would expand on why you dislike rust personally, as you originally mentioned that, and we agree that it is often not a good choice from a business perspective (because of practical concerns or simply momentum/experience with another language, etc.).
Using crates.io with pinned versions is also very common at large rust shops. They have no realistic other choice.
Using 3rd party libraries ultimately from crates.io, I agree of course. I haven't seen direct crates.io personally, vendoring/artifactory/aws artifacts/(or even a private git repo) is a "realistic... choice", and flatly a better one.
I think you mentioned having to write rust at work (perhaps it was the other person), so I suggest looking into one of those options, it will probably be some easy bonus points from higher up.

I'm not going to play this autistic game of hunting down examples you deem worthy of consideration
Very hostile.
You do not have to dig up citations or anything, I am just interested in the claim "the language/compiler is set up in a way where it will constantly fight you on stuff that has little to do with memory safety (e.g. stylistic choices)." The primary thing I can think of here is rustfmt, which you can turn off or adjust.
 
Using 3rd party libraries ultimately from crates.io, I agree of course. I haven't seen direct crates.io personally, vendoring/artifactory/aws artifacts/(or even a private git repo) is a "realistic... choice", and flatly a better one.
You know where the crates on those places come from, right? The general flow is:
  1. Crate appears on crates.io
  2. A customer of one of those private repos wants it
  3. They do some sort of nominal automated review of the crate
  4. Crate gets published on the place
The shit flows downhill from crates.io. The only practical difference is that you now don't trust crates.io to hold the correct code for the old versions - you trust AWS or artifactory to hold it. The exact same issues with bugs, bad maintainers, etc. flow down.

And I don't like rust for several reasons:
  • The design philosophy of "Javascript but it's a zero-overhead systems language" leads to very dumb syntax for a lot of things. Idiomatic rust looks a lot like APL thanks to this.
  • A systems language should be able to be compiled mostly in your brain. C is 100% this way, C++ about 80-90% once you really know the language. Rust stuff is too full of side effects and there's no written spec, so good luck.
  • The compiler is too restrictive of what you are allowed to do with the language, because it needs statically-managed lifetimes for the borrow checker.
  • Troons maintaining the whole language, with no sense of discipline. They are too busy getting their discipline from rustc and cargo mommy, all while fucking around with the internals of the language and core libraries (and cargo crates that should be core libraries) with reckless abandon.
There are good things about Rust, like its type system, and the fact that the borrow checker allows JS developers to write passable systems code. If you are a real power-user of your CPU, though, Rust handcuffs you to a single development style that is not always the best and saddles you with a JS-like development enviornment instead of full control of your hardware. That is also why many Linux maintainers resist Rust.

If you think that the troony development culture of Rust is not a problem that flows down to the language, I point you to async as exhibits A-Z.
 
Last edited:
Thanks for the detailed comment. I agree about rust being a bad replacement for c(++), especially due to the "brain compiling" thing (even unsafe pointer stuff is typically quite divergent from the lower level).
The compiler is too restrictive of what you are allowed to do with the language, because it needs statically-managed lifetimes for the borrow checker.
Show some code you have written that uses lifetimes in a nontrivial way.
 
Very hostile.
You do not have to dig up citations or anything, I am just interested in the claim[...]
Show some code you have written that uses lifetimes in a nontrivial way.
2014-09-19-1062sea.png
 
Last edited:
I will always refuse to use Rust specifically because of total ideological contamination of its community, long live C (not C++). Despite my great admiration for LISP, Haskell and even Java I think C is still my favorite language to write in personally, and the one I have the most fun making things with

P.S. I wish people stopped saying things like "C(++)," I don't think the modern-day experience of the two is at all comparable!
 
That book radicalized me against Rust.

"No, child, linked lists are in fact a bad thing. Enjoy unsafe prison."
...all because Rust happens not to support them very well.
I can't even make it past the 1st introduction page without arguing with my computer monitor. A number of this guy's counter-arguments can be summed up as:
Dumb Tranny said:
Yeppers! Although doing ________ is a really niche use case and reeks of laziness/retardation and never should be done by anyone ever. So what if you're used to doing this in your preferred language? Hardly any Rustaceans™ do ________, and you're a fucking moron for even considering it. We know better than you, your paradigm is trash, and we are going to force you to do things our way. So what if it makes everything 1000x more convoluted?

But yes, if you want to be a big gay poopy pants retard, then your idea sounds stuuuuuuupendous!

Maybe the reason no one seems to do _______ is that Rust makes it damn near impossible to pull off.
 
I can't even make it past the 1st introduction page without arguing with my computer monitor. A number of this guy's counter-arguments can be summed up as:


Maybe the reason no one seems to do _______ is that Rust makes it damn near impossible to pull off.
"Just so we're totally 100% clear: I hate linked lists. With a passion. Linked lists are terrible data structures. Now of course there's several great use cases for a linked list:"
This faggot needs to answer how I'm supposed to implement any kind of tree or graph if the most basic possible version of a graph is this unwieldly to write.
 
"Just so we're totally 100% clear: I hate linked lists. With a passion. Linked lists are terrible data structures. Now of course there's several great use cases for a linked list:"
This faggot needs to answer how I'm supposed to implement any kind of tree or graph if the most basic possible version of a graph is this unwieldly to write.
For our Sea Lion friend from earlier, this is another thing I can't fucking stand about the Rust community. They will never concede their language has glaring faults and massive limitations, so they will do as much mental gymnastics as possible to make you out to be a retard for wanting to do a procedure that would be straightforward in literally every other language. Anything that doesn't fit neatly in their gay little paradigm suddenly gets labeled as unsafe, hated vehemently, and quickly shouted down en masse as a cardinal sin of a shitty programmer. They always think they know better.

>Well why would you even want to do ________
 
Last edited:
The Rust community reminds me a lot of Apple fanboys. It's not just the insistence that their way of doing things is the one true way to do it, but also, if they are ever gracious enough to answer a question, the way they speak/write is just so off putting.

I'm honestly half tempted to look into Rust properly just to write a "Rust for C/C++ programmers" that's actually tolerable...
 
Back