[ home ] [ q / soy / qa / r / nate ] [ a / health / incel / int / mtv / pol / psy / raid / sci ] [ overboard ] [ rules ] [ bans ] [ wiki ] [ booru ] [ archive ] [ merch ] [ donate ]

/tech/ - Technology

Name
Options
Comment
File
Embed
Password (For file deletion.)

File: 1687230669675.png (141.81 KB, 800x789, 1674306290167.png)ImgOps

 6389

>is that... RUST? N-NOOOO HECKIN TRANNY LANGUAGE
>JUST USE C CAUSE IT'S TRAD AND KEYED OR SOMETHING (even doe I never write any code)

 6390

>>6389
>>6389
programming inherently is either autistic, schizo, or tranny tier.
pick which mental illness you have.

 6391

>>6390
schizo autism

 6392

>>6389
ML is done in c++ thoughbeit so cope and seethe

 6397

JavaScript is the nigger of programming languages

 6398

Segmentation fault le bad because uhh

 6414

why would i care about security when my processor has 50 bajillion mossad backdoors baked in and the internet nodes and certificate authorities and everything else is compromised to fuck too? WHY WOULD I CARE?? i'm root. i've got an internet facing SSH server running with no password. kike backdoors are useless if i open the front door. yeah anyway, use C. it's faster and that's all that matters. if you've got malware on your machine it's because you're a fucking idiot and no amount of security is gonna help you. you put the gun to your own head and pulled the trigger

 6417

>>6414
also i don't care if C is inconvenient to programmers. not everyone should be writing code. we need extremely competent, extremely intelligent, 300 pound giga neckbeards, in their basements, with 150+ IQs - i'm talking about people who have COMMITTED their lives to programming at every other expense, who are in the FUCKING ZONE 24/7, and we need them writing code as low to the hardware as possible - that's how it has always been done - and that doesn't include ANYBODY reading this right now. it doesn't include anyone who browses /g/. it's not me and it's not you. the competent programmers are 1 in 10 million. competent UI and user experience designers are 1 in 100 thousand. tranny rustoid gnome developers are 1 in 10 thousand. everyone else in the world could potentially be a web developer electron developer fucktard if they performed at their highest level. that's the truth

 6419

>>6417
because i'm talking about software that people billions use every day. windows should be PERFECT. android should be PERFECT. OSX should be PERFECT. everything about these operating systems should be FLAWLESS when trillions of hours of cumulative runtime are being accrued every month and hundreds of trillions of dollars in the global economy are riding on your OS being a productive work environment. it's a matter of life and death. THERE IS NO EXCUSE FOR WEB DESIGNERS, INDIANS, OR NIGGERS TO BE WRITING SOFTWARE THAT BILLIONS OF PEOPLE USE. NO EXCUSE. you don't see em designing nuclear reactors, or artificial heart valves, or anything that peoples lives hinge on - so why are they involved in operating system development or software development when it pertains to billions of lives? programming should be the most elitist profession in the world. you should have to pass an IQ test and solve 50 applied algebra problems to even use any of these git hosting websites. microsoft should only be hiring 300 iq savants. anything that makes programming easier is a bad thing. also they should be basing every UI on mountains of research and psychology like they used to in the 90s before purple haired nose ring having web designer literal cuckolds took over and threw all the empirical evidence and UX science in the garbage can. cleanse them all

 6421

File: 1687272720103-0.png (338.58 KB, 600x398, laughing.png)ImgOps

File: 1687272720103-1.png (44.54 KB, 1285x1369, android feraljak google je….png)ImgOps

File: 1687272720103-2.gif (1.17 MB, 598x765, wintoddler blue screen of ….gif)ImgOps

>>6419
>android
>windows
>macOS
>"perfect"
see what happens when you write operating systems in java and copypaste someone elses work with slight modifications that ruin it?

 6422

>>6414
this
also tell me your servers ip, is root login enabled?
im gonna uninstall your proprietary blobs for you and recompile your kernel to make it 5% faster

 6423

>>6419
so ultimately i don't want more languages that make programming easier and produce slower binaries, because i care about the user experience and i know security is a farce. i want fast software. i don't need a false sense of security salving my conscious while my CPU, motherboard, and network hardware are backdoored and open to 5 million different side channel attacks half of which the CIA and mossad don't even know about. JUST DON'T RUN EXECUTABLES YOU PIRATED YOU FUCKING IDIOTS

 6424

>>6423
>>6419
>>6417
>>6414
and if anything i said makes you slightly uneasy or upset, then you need to admit right now that you are not worthy. even if you agree with me you're probably still not worthy - but if you think i'm wrong you're definitely definitely not worthy to program anything or contribute to ANY project. you should not be allowed near an IDE, version control system, or a compiler. social services should take your computer away because you're abusing it. if you have a github account you should be banned permanently and you should be blacklisted from every git host and also every svn host and every cvs host until the end of time

 6425

test

 6426

we must stop the spread of rust. have you tried reversing that shit

 6427

>>6423
>implying proprietary rootkits you bought are any better than proprietary rootkits you torrented

 6428

>>6424
this, if you can't program and think you need a ""memory safe"" language, dont program.

 6431

>>6427
as long as they run fast i don't care. rootkit or no rootkit, it should run faster now then it did 20 years ago when my computer had 1/32 the memory and throughput. if it's just as slow as it was then, because of some fucktard typesafe language (or whatever the case may be) - and if billions of people are inconvenienced by that fact, then honestly that's as bad as mass murder - because you're wasting billions of hours of peoples time and trillions of dollars. you should be punished with a death sentence by forced labor for writing slow software - especially if you work for a government subsidized monopoly like microsoft and everyone is forced to use your garbage. work for a communist design bureau? maybe you should get the communist treatment in a gulag

 6432

>>6431
every microsoft employee should be sent to siberia to mine coal RIGHT NOWWWWWWWWWWWWWWW
if they refuse to work they should be gunned down and their deaths broadcast to the others so they know their place. insubordination should be punsihed with DEATH

 6436

>>6426
Yes, it has a completely different ABI than C++ - evidently, this includes raw strings, calling conventions, ...
It also has a fuckton of thunks and PDB symbol names aren't exactly human-readable because they offer relevant info because of cargo as a pack manager, which clutters most of your decompilation view, but it's not much better than modern C++ (I do reverse engineering professionally, especially on Microsoft applications - it's incredibly unreadable even with their incredibly kind agreement to share PDBs).

Rust addresses many modern problems, but it's not necessarily optimal in, for example, Windows. Rust goes against anything Windows, which is why we don't use it at work here, if you do things that are very platform specific, Rust won't be ideal for you out-of-the-box, you'll need to do a lot of meta-hacking (good that we have that), frankly just like you have to with C/C++, but way more complex (both a positive and a negative). Rust is also not designed for very old computers, so things such as Rust field ordering prevent people from assuming structure layouts as we have for long in C/C++. It allows way easier cross-platform, example for Risc where you need size boundary alignment, Windows NT had to be ported to RISC and they had to manually update the source code to meet the requirements because of field ordering following assumptions which we probably shouldn't have. Field ordering is also good for performance on non-RISC processors, if you look at vAbi in C++ Microsoft STL, you'll see optimizations which are literally just moving fields in other places.

 6437

>>6426
Yes, it has a completely different ABI than C++ - evidently, this includes raw strings, calling conventions, ...
It also has a fuckton of thunks and PDB symbol names aren't exactly human-readable because they offer relevant info because of cargo as a pack manager, which clutters most of your decompilation view, but it's not much better than modern C++ (I do reverse engineering professionally, especially on Microsoft applications - it's incredibly unreadable even with their incredibly kind agreement to share PDBs).

Rust addresses many modern problems, but it's not necessarily optimal in, for example, Windows. Rust goes against anything Windows, which is why we don't use it at work here, if you do things that are very platform specific, Rust won't be ideal for you out-of-the-box, you'll need to do a lot of meta-hacking (good that we have that), frankly just like you have to with C/C++, but way more complex (both a positive and a negative). Rust is also not designed for very old computers, so things such as Rust field ordering prevent people from assuming structure layouts as we have for long in C/C++. It allows way easier cross-platform, example for Risc where you need size boundary alignment, Windows NT had to be ported to RISC and they had to manually update the source code to meet the requirements because of field ordering following assumptions which we probably shouldn't have. Field ordering is also good for performance on non-RISC processors, if you look at vAbi in C++ Microsoft STL, you'll see optimizations which are literally just moving fields in other places.

 6440

>>6426
Yes, it has a completely different ABI than C++ - evidently, this includes raw strings, calling conventions, ...
It also has a fuckton of thunks and PDB symbol names aren't exactly human-readable because they offer relevant info because of cargo as a pack manager, which clutters most of your decompilation view, but it's not much better than modern C++ (I do reverse engineering professionally, especially on Microsoft applications - it's incredibly unreadable even with their incredibly kind agreement to share PDBs).

Rust addresses many modern problems, but it's not necessarily optimal in, for example, Windows. Rust goes against anything Windows, which is why we don't use it at work here, if you do things that are very platform specific, Rust won't be ideal for you out-of-the-box, you'll need to do a lot of meta-hacking (good that we have that), frankly just like you have to with C/C++, but way more complex (both a positive and a negative). Rust is also not designed for very old computers, so things such as Rust field ordering prevent people from assuming structure layouts as we have for long in C/C++. It allows way easier cross-platform, example for Risc where you need size boundary alignment, Windows NT had to be ported to RISC and they had to manually update the source code to meet the requirements because of field ordering following assumptions which we probably shouldn't have. Field ordering is also good for performance on non-RISC processors, if you look at vAbi in C++ Microsoft STL, you'll see optimizations which are literally just moving fields in other places.

 6441

>>6440
you work for think-call don't you

 6442

think-cell

 6443

fuck this slow ass board nigga

 6444

File: 1687277125850.png (761.88 KB, 1440x2035, GNU slash yes cirno.png)ImgOps

>>6431
>it should run faster than 20 years ago
soydevs say otherwise, in fact, most wintoddler computers nowdays run SLOWER than computers 20 years ago and can still do the exact same shit, sometimes even less
old MSDOS winkike allowed you to continue after a bugcheck call (aka bluescreen), while NT garbage just tells you "fuck you, we're turning off 'your' computer for you, 'for your security'" without giving you an option
>durr hurr rootkit le good
rootkits are malware and nobody needs them, theyre more bloated than they'd have to be and thus slower
>>6432
this, in minetest, so it pisses microshaft off because youre not running their own proprietary slow pajeet java game, but instead run a blazing fast C++ chad game.
>muh ""minimalist"" and ""lightweight"" software le good
by the way, dont fall for this lie. some of GNUs binaries are smaller than busybox binaries, they all have more features, they all run faster, and busybox cant even handle POOSEX compliant file names properly because of how garbage it is. this is meme "minimalism" and its just as bad as making everything bloated and slow like winglows.

 6445

>>6441
No but I do RE office suite often

 6446

File: 1687278974864.gif (1.67 MB, 512x512, 1669059515208.gif)ImgOps

>>6443
>fuck this slow ass board nigga

 6447

>>6414
You're a neurotic, impulsive retard who doesn't really want to understand how stuff happens and why, you are just in love with your ideas because you probably developed some personality disorder as a coping mechanism to your inability to dig into the nitty gritty - because you have 0 discipline. Sure, zog-niggers read your HTTPS communications through their certificates that are already installed on your computer, sure, Microsoft has a fuckton of telemetry and other shit that they hide through AppContainer (abusing a design), but the people who really want to go against this stuff empower you by writing, fuck, software like Fiddler for example, there's many ways to actually fucking verify your computer acgivity, it's not magic as you freetards force yourself to believe.

>>6417
C is not inconvenient, but merely surpassed by modern needs. Systems nowadays are more complex than anything in the 1960s, in part because of many choices we as a community made then (for example Lisp VS. C). C did not have, for example, a garbage collector, because it was designed for platforms where a garbage collector would be physically not fit alongside the other required feature-set. C has not been formally verified because C cannot be mathematically proven, it's an amateurish set of rules compared to what we have discovered since then, and it shows in the pain of properly parsing it's current form in accordance to the current standards and extensions, it shows in the way they had to hackily bootleg generics, it shows in the fact that you have to deal with headers and because fo that bad design then also linker autism is common, it shows whenever you erase types in stupid ways (ignoring current packing, alignment, whatever), arguing otherwise is really just a way to defend the matter of fact that you don't want to evolve your programming skills and move on to new ideas. Let me connect it back to how you are enamored with your ideas and yourself, and as a coping mechanism you shun everything you don't immediately understand: if you had any of the ideas that you critique today yourself, you'd (perhaps rightfully!) think you're hot shit.
You should really participate in standardization circles if you think that your ideas are so great, and fight against the people with vested interest in moving shit forward, using your arguments and not just saying "NIIGGER NIGGER NIGGER YOU'RE RETARDED", it'll humble you. You probably have a friend group of people even lesser than you in the regard of programming who never contest you on any related matter.

>>6419
I made a comment above on how your dear C could be an impediment to stuff just werking


Also, you shouldn't be writing code as close to your machine as possible, it should be as abstract as possible so that you can shoehorn optimizations that are architecture specific into generic operations, whilst also being able to easily support other architectures. Furthermore, you should be writing C like you're writing code for an abstract machine, if you're writing C. If you have a really custom architecture then why are you even writing C? You are just so enamored with your own ideas that you can't think of people using the right thing for the right job. If you really like C then have fun manually reordering your structures to respect size boundary alignment or shit like that.



>>6428
Have you thought that, if you can't use a language in which lifetimes are embedded in the type, that maybe you're the issue?

 6455

>>6447
>there's many ways to actually fucking verify your computer acgivity, it's not magic as you freetards force yourself to believe.
it's not magic, and i'm not obsessed with security - which is why i don't want to see everything re-written in rust. 90% of security incidents are, and will continue to be user error related - whether everything is written in rust or not. i will admit that rust probably should be used in areas of software requiring high security - but does every program in userspace have to be 100% airtight as well? it's not necessary. the average user cares more about speed than the low margin of security rust offers them over C or C++. programmers (mediocre programmers) are the monomaniacal cultists obsessed with proliferating rust everywhere without even knowing what it ought to be used for - users don't care about that shit. i particularly don't care, because i know how farcical it is. there are hundreds of hardware backdoors just waiting to be discovered. once they're found, they'll be acknowledged, patched, and new ones will be added to replace them. so who cares??
>you shouldn't be writing code as close to your machine as possible
as low as possible without compromising on portability, at least

 6465

>>6455
Lifetimes aren't about preventing security incidents so much (because the inherent flaws languages like C brought about are addressed by mitigations nowadays), because if someone has to abuse that to develop an exploit then it's likely really grim for them. Lifetimes are merely about bringing closer to defined runtimes for programs, because fo the embedding of a variable's lifetime into it's type. Your compiler merely makes sure that you don't break any general laws. What is wrong with that? It teaches and shapes programmers by making things concrete.

> but does every program in userspace have to be 100% airtight as well?

You seem to have implied so.

>programmers (mediocre programmers) are the monomaniacal cultists obsessed with proliferating rust everywhere without even knowing what it ought to be used for

I have to agree but probably not in the same way you do. Yes, Rust is trendy because of their approach to community (which I heavily dislike and it has been attacked recently on multiple occasions), which leads to enthusiastic youngsters trying to have others embrace it by following the contagion. Those are mediocre programmers by definition because they are young. likely don't have jobs, or skin in the game - if the technology is adapted (it's not like it'll blindly be in real systems, but the matter is they don't consider potential ramifications of their worldview).

Rust implements many great things that I wish to see in more modern systems programming languages. I wish to see a new one because old ones come with negative baggage. I wish there'll be something less convoluted than Rust but with all of the benefits. I wish the static linking craze will also stop.

>as low as possible without compromising on portability, at least

This requires a common core or a base emulator. Maybe my computer doesn't even have virtual memory! Use the right tool for the right job. This is where compromises happen that you complain about.

I genuinely wish all of you here stop falling for the radicalization meme ('lest it's ironic and I',m missing it due to autism) and do something nice with your lives, to help others, yourself, and your family.

 6466

>>6465
Doesn't have contiguous memory*

 6467

>>6389
I use C because I want it to be as small as possible, use as little ram as possible, compile everywhere (with different compilers) and also be usable by everyone. Every language can interface C. If you write a core component of a project in any language other than C then you are not a serious programmer.

 6470

>>6467
gr8 b8 m8

 6472

>>6467
Fundamentally Lisp is more portable than C.

 6498

>>6389
>HECKIN TRANNY LANGUAGE
is he any wrong?

 6506

>>6472
because it's (bytecode) interpreted. FORTH is more portable than Lisp. But you are still going to need a VM for both. (You still need a compiler for C though if you are writing in C)

 6554

>>6498
this



[Return][Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ home ] [ q / soy / qa / r / nate ] [ a / health / incel / int / mtv / pol / psy / raid / sci ] [ overboard ] [ rules ] [ bans ] [ wiki ] [ booru ] [ archive ] [ merch ] [ donate ]