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

[Kokonut Kangs Klan]

It's also amazing they don't have automated testing to catch this.

part of their cope was "SAAR it’s critical that [the needful] is rolled out frequently and rapidly as bad actors change their tactics quickly SAAR", attempting to conflate their schema/visibility janny work (not fucking urgent at all) with the actual data in that pipeline. This sadly isn't uncommon, tech jeets hiding behind the critical-yet-dynamic nature of a service to neglect taking basic precautions.

 

[The Freak Who Lived]

Did they seriously not have.feature_names.len() >; 200check or even automated testing for this?

A single line could've avoided this and a second line could've more gracefully handled the error.
.append_with_names(&self.config.feature_names)?;

It's also amazing they don't have automated testing to catch this.

The fact they allow unwrap in their deployed code tells all you must know about that company.

 

[Markass the Worst]

I think it's fair to blame the language when the error is what a lazy retard programmer would do. The single biggest criticism Rust supporters levy at C is that the lazy thing to do is to not handle memory errors, which is unsafe and segfaults and yada yada. Rust is better because the compiler will call you a nigger instead and force you to handle errors.

Except not actually because .unwrap counts as "handling" the error so lazy retard programmers just shit out .unwrap everywhere like it's a pajeet on a designated street. Is this better than the lazy retard thing in C? Since half the Internet died, I don't think it is.

 

[Creative Username]

Except not actually because .unwrap counts as "handling" the error so lazy retard programmers just shit out .unwrap everywhere like it's a pajeet on a designated street.

why is it even allowed in safe code, and why is it 6 letters (which makes it quicker than properly handling the error)
if i were designing a c-like language with type system cbt chastity cage to prevent you from fucking up, exiting to the operating system from random code would be one of those things that is intentionally made extremely hard to do

Is this better than the lazy retard thing in C? Since half the Internet died, I don't think it is.

you know a dos is actually not as bad as something like heartbleed

 

[jeff7989]

you know a dos is actually not as bad as something like heartbleed

Sure would be nice if half on modern Internet wasn't MITM'd by Rajeeshflare.

 

[Markass the Worst]

you know a dos is actually not as bad as something like heartbleed

Yes, but C code is just as likely to segfault, so I think Rust didn't do much better. Is it good that Rust guarantees there to be nothing exploitable by a bad actor? Yes. Is it worth bringing down half the Internet? Probably not.

 

[Max Free]

Since rust is so topical now: rust still uses system calls, for stuff like memory allocation, right? How can apps written in rust be inherently memory safe when they rely on system calls for routines written in an unsafe language?

Except not actually because .unwrap counts as "handling" the error so lazy retard programmers just shit out .unwrap everywhere like it's a pajeet on a designated street. Is this better than the lazy retard thing in C? Since half the Internet died, I don't think it is.

I think searching for every instance of ".unwrap" in your code and review it's handling still is more comfortable than trying to find all the different ways you can fuck yourself up in C.

Is it even logically possible to concoct a language whose compiler can detect every possible fatal error and therefore refuses to compile? If I remember correctly, it wasn't even possible to detect if certain code would produce an app that would block indefinitely or not.

 

[Spergichu]

The fact they allow unwrap in their deployed code tells all you must know about that company.

bloody bitch benchod linter slows down deployment time saar.. pls understand and do the sneedful..

 

[Goose the Redeemer]

I dont see how this is the fault of rust. It seems to me, that it would have failed in the exact same way had it been written in C, C++ or Java.

Which is like saying it was "caused by C" or "caused by PHP". An experienced programmer doesn't say shit like that. A dumbass who has cottoned on to various memes he has no ability to comprehend might, I suppose.

Rust gives you so many ways to unwrap safely that making a mistake here is like somehow getting yourself impaled in a mcdonalds playspace. This has nothing to do with the language. This is just lazy and niggerlicious code that someone had to jump through a safety barrier to write, and then deploy.

If it compiles, it works.

Of course it is the programmers fault, but Rust troons always blame C for errors as if they were an inherent properly of C code and not the fault of the "lazy" programmer so they don't get to run away from this one with "but muh lazy programmer". Rust did this.

 

[Markass the Worst]

Since rust is so topical now: rust still uses system calls, for stuff like memory allocation, right?

It has to, there's literally no other way to do it.

How can apps written in rust be inherently memory safe when they rely on system calls for routines written in an unsafe language?

Isolating all the unsafe bits to system calls is still a major win for safety. There's also not much you can do if a syscall like memory allocation fucks up.

I think searching for every instance of ".unwrap" in your code and review it's handling still is more comfortable than trying to find all the different ways you can fuck yourself up in C.

Yes, that's better. But that relies on the programmer not choosing the path of least resistance, and if we're going to assume that, then it's hard to criticize C for doing the same.

Is it even logically possible to concoct a language whose compiler can detect every possible fatal error and therefore refuses to compile? If I remember correctly, it wasn't even possible to detect if certain code would produce an app that would block indefinitely or not.

Indeed it's not. I'm not holding Rust to that standard, I'm just pointing out how the path of least resistance is .unwrap and the results aren't much better than C.

 

[Creative Username]

Since rust is so topical now: rust still uses system calls, for stuff like memory allocation, right? How can apps written in rust be inherently memory safe when they rely on system calls for routines written in an unsafe language?

yes, the kernel is usually written in c. however, a memory exploit in a system routine really isn't rust's fault, it's a fault of the system. but many things in computing make assumptions about the abstractions below them, and that includes rust assuming that the operating system isn't fucked up. it goes both ways, though, like c assuming that the operating system isn't fucked up too: try running a standards-compliant c program with no ub (which obviously shouldn't have ub) under a libc with a malloc that doesn't work properly, and see what happens

If I remember correctly, it wasn't even possible to detect if certain code would produce an app that would block indefinitely or not.

this is called the "halting problem" and it actually states that you are not guaranteed to be able to know if a certain turing machine ever halts, which is an important distinction
proving eventual termination is actually a pretty cool thing that languages could do, but nobody's really working on it (probably because compilers smart enough to do it are hard to write and specifications for the languages are even harder to write)
just because you can't sort things into "halts" and "does not halt", doesn't mean you can't sort things into "halts", "does not halt", and "maybe halts" which is conservatively treated as "does not halt" unless you override it (since turing-completeness is nice to have actually)

Isolating all the unsafe bits to system calls is still a major win for safety. There's also not much you can do if a syscall like memory allocation fucks up.

you can't magically ensure that e.g. your cpu's arithmetic instructions don't give the wrong answers, but you can ensure that you won't add any other broken shit on top of all the other potentially broken shit

 

[Cuckoman]

I dont see how this is the fault of rust. It seems to me, that it would have failed in the exact same way had it been written in C, C++ or Java.

No. The design pattern in C is completely different.
In C you check and return an error, you do not panic.

Panicing because something unexpected happened instead of checking for or dealing with errors is like thinking cutting off your penis would be a good response to deal with some imaginary issue..

 

[Otis Mallebrok]

No. The design pattern in C is completely different.
In C you check and return an error, you do not panic.

It's the exact same fucking thing. People dont write elaborate error handling code for errors that are thought to rarely or never occur, because programmers are lazy. It happens in C all the time.

 

[Kokonut Kangs Klan]

why is it even allowed in safe code, and why is it 6 letters

and why is it called unwrap, who named this shit. Unexplained in the troontorial and absent in the reference manual , no explanation given for why such an innocently named function "panics" and explodes your rectum in a consent accident.


it's apparently part of the standard library which also fails to explain any pants-shitting aspect of what the name means

 

[Creative Username]

see what white people do in c if they don't want to handle malloc errors or whatever is they make a macro or something called safe_alloc or whatever that does the equivalent of what rust does (instantly die)
but this actually completely doesn't matter if you're on the linux kernel, because if you use too much memory on linux, your process will be killed by the kernel's oom daemon. you do not have any way to detect it or prevent it

of course the white man's way to handle this is to go make everything else redundant and robust to failure (this kind of shit happens anyway, you can't catch a ram module burning itself out as an error)

generally, though, you ALWAYS HANDLE YOUR FUCKING ERRORS

 

[I AM UNDOUBTEDLY FIZZED8%]

Pfft, Faggie Robertson at it again with sucking 3mm Rustnigger cock.

 

[Cuckoman]

It's the exact same fucking thing. People dont write elaborate error handling code for errors that are thought to rarely or never occur, because programmers are lazy. It happens in C all the time.

No, it is very different.

In all training material in C it is repeated over and over that you must check arguments and return codes. Every time.

In all rust training material you are shown and taught to use .unwrap() (because it is too much work to handle errors as they propagate back up the callchain).

Using unwrap() is like cutting of your penis as solution to stop you from getting an STD.

Exception handling and unwrap() has no place in a systems language. Yes. writing error paths as errors propagate through the calls stack is a lot of boring work.

 

[306h4Ge5eJUJ]

it's apparently part of the standard library which also fails to explain the pants-shitting aspect of what the name means

It does explain it in the reference. It's still insanely stupid to make the unsafe operation easier to use than the correct one and then advertise it in tutorials.

but this actually completely doesn't matter if you're on the linux kernel, because if you use too much memory on linux, your process will be killed by the kernel's oom daemon. you do not have any way to detect it or prevent it

This is a persistent myth, it's only undetectable when memory overcommitting is enabled. When MO is disabled, malloc/mmap/etc simply fail. Which still has issues mind you because by the time your small-sized mallocs start failing it's probably already too late to handle the problem.

 

[moocow]

idk what kind of bizarre alternate reality you stepped out of, but in this universe an ancient integrated graphics craptop will shit itself violently running minecraft 1.8 with the render distance turned up above 3 chunks

I have vivid memories of playing this game on sub 10 fps with the shittiest settings possible a few years ago, stalker. Your gaslighting won't work, child. Enjoy bedrock edition.

Not to be rude, but you niggers are drunk. This is unmodded (vanilla) 1.21.10 running at 119 FPS at 1920x1080 on default settings on an integrated (i.e. Mark II Piece of Shit™) Radeon APU, and I have a video player running (w/hardware decoding) in the background and about 150 open tabs in Brave (I'm busy ).

 

[The Noise]

actually minecraft java edition is one of those things that convinces people that java is slow

tbf java edition was slow as fuck for a really, really long time because mojang were lazy niggers and fucked up the engine so bad in 1.13+ that you could get "server is running behind" warnings just by standing still. they had to dedicate an entire major version update (1.15) to just fixing all the shit they broke in 1.13-1.14

granted the game is a lot better these days on account of the fact that one of their jeets finally discovered -XX:+UnlockExperimentalVMOptions