C is depricated thread #2

It's like he set this up intentionally:
> where is ls?
github.com/ogham/exa
> where is cat?
github.com/sharkdp/bat
> where is grep?
github.com/BurntSushi/ripgrep
> where is word count?
github.com/Aaronepower/tokei
> where is the ksh
github.com/redox-os/ion
> where is the kernel
github.com/redox-os/kernel

Also, note how his measure of a programming language abilities is to be able to reimplement tools from some obsolete OS. And when he is confronted with the existence of such tools, he moves the goal posts to POSIX compatibility, the most irrelevant thing you could have come up with in 2017. Of course ripgrep isn't POSIX compatible, it's much better.

Why does every C programmer on Jow Forums think they don't make any mistakes when literally any C project of any non-trivial size has had bugs. If the openBSD guys can't avoid vulnerabilities in their C code, what makes you think you can?

Is it just Dunning-Kruger from working on small hobbyist projects?

Attached: eternal.png (387x550, 339K)

>replace manual retard-checking with manual borrow-checking + bonus steps
yeah I wonder...

someone show me a doubly linked list in Rust

doc.rust-lang.org/std/collections/struct.LinkedList.html

Honestly shit like Bash should be killed off regardless, and if someone writing it in Rust ensures we have a 2019 fresh start I'm all for it.

None of these are drop-in replacements, because features of the original tools can't be recreated in Rust

>Why does every C programmer on Jow Forums think they don't make any mistakes

I make, but I fix before anyone sees it, because I test my shit.

The only *proven* alternative to C is Fortran. Rust looks good and it may have the potential to overthrow C, but so far it has no real world traction to speak of.

Attached: Fortran_acs_cover.jpg (610x780, 87K)

>where is nosoft?
kek

> None of these are drop-in replacements
Neither are they intended as ones, being drop-in replacements for shitty 40yo tools would undermine the purpose of the projects.
> because features of the original tools can't be recreated in Rust
What?

>&mut self
this is why Rust will never fly.

Well obviously you're not going to write airplane software in a beta language.
But what does &mut self mean anyway?

>doc.rust-lang.org/std/collections/struct.LinkedList.html
At first I thought that "std" meant "standard", but after reading the link, think it means "STD".

What an eyesore.

it means that you need to OWN the object to do anything useful with it. You need the mutable reference. But also, that means nothing else can have a reference because rust.
I mean, if you think about it in "perfect safety" terms, it makes sense.
If you can mutate it, then if anything else had a reference the information could change (ie not safe). So only one thing can own it; or it's unowned and can be referenced freely. all good, except check the number of things you need to own it for.
just to have an iterator, you need to own it.
How you would steal ownership, I have no idea. Some sort of dispensory of objects in your program? maybe. Maybe you just need to pass everything into every function.

> &mut self is bad but void *(*f[])(void*)[] is good
A mutable reference. It's like a regular reference from C++ (ie a C pointer which is statically guaranteed to be valid), but in contrast with C/C++ references in Rust are immutable (i.e. const) by default and have to be explicitly marked as mutable.

Attached: 1550262872768.png (1388x826, 118K)

>Some(&12)
wut

i enjoy C do
Also most libs are coded in C and then you have a whole kernel with C libs

good strawman

>That level of COPE

>mutability is good

Kek, what a chimpanzee.

notice how defensive the speaker got. all his points were shit. it's like someone arguing that we've always used a horse and we don't need cars.
fun fact, people _actually_ argued that back in the day.

we'll be looking at these C fanatics the same way we look at the people arguing against the car.

this. also, this:
>some obsolete OS
Modern Unixes like the Linux distributions are a mess, I hope we collectively move onto something like NixOS or GuixSD. Don't even bother mentioning BSDs no one uses that shit.

hasklet detected

REWRITE EVERYTHING IN RUST

Whom are you quoting? In Rust everything is immutable by default.

I cannot take any language which has an 'official community' seriously - i.e mascots, cons, cutesey names, etc.

this thread is being astroturfed take care readers

> I cannot take any alive language seriously
Btw, why there are no C conferences? C++ has several hug annual confs, Rust has a lot of local conferences, so does Go. Hell, even practically dead D has a conference of its own.

Why don't C programmers meet up to discuss their favorite language, to share best practices and insights, to discuss the coming standard? Could it be because there is no active creative force in the C community and most of the C programmers are dead-inside boomers?

>Why is it allowed to build software using inherently unsafe languages?
Because there are many projects where the costs associated with the safety guarantees are unacceptable, or at least the subject of tradeoffs that can reasonably go either way.

>Why not let the computer to do all the checks instead of relying on the imperfect human mind?
Because of performance. Having the computer do those checks at runtime is expensive as fuck. Often that is worth it, but there are quite a few cases where it isn't.

If someone were to find a way to accomplish the same safety guarantees without the associated runtime cost -- perhaps with clever compile-time static analysis, perhaps with hardware tricks, or whatever other way people can think of -- that would be great and we could mostly scrap C. The rust people are doing praiseworthy envelope-pushing in this area, and if they ever get that to work it would be fantastic. Sadly it's not nearly strong enough to supplant C and other unsafe languages yet, so we are stuck with writing C and C++ (which has much the same problems) for now.

> it's not nearly strong enough to supplant C and other unsafe languages yet
What does this mean exactly?

They actually do tons of conferences but usually they speak about the code implemented in a context rather than circle jerking about the language it self, you see all those conferences about how cool a language is its just normie tier no one cares about semantics its something you learn in a month and after that theres no need to speak about it any more.
If you want to see those conferences instead of googling "how awessemoe mu langugea is" and try "Linux Kernel talks"

No it isn't?

>tfw Community College is no longer offering the "C as a second language" class for next quarter

Attached: 03.jpg (1000x750, 491K)

I think Rust would be a great language if its code weren't so terrible to read. It seems conceptually sound, but it's ugly as sin. It's like they thought C wasn't terse enough, so they just abbreviated every keyword and threw casing guidelines out the window.

I mean look at this shit: github.com/rust-dev-tools/fmt-rfcs/blob/master/example/lists-elided.rs

>pub config: &'a Config,
Nevermind the fact that they refuse to name the generic type parameter "T" - of course they have to be different - but what the fuck is this sigil puke?

Rust is probably harder to read than modern C++, except maybe when it comes to the template pissing contests in the latter, and that's saying something. Even if a Rust feature has an exact equivalent in another language, they give it an obscure keyword.

Just imagine being this afraid of a little circuitry.
>What if my code segfaults?
>I'm literally shaking right now!
We're not cops armed with lethal weapons chasing down violent killers, we're nerds with keyboards and little calculators that draw funny pictures of cats on screens. Get over yourselves, already.

> what the fuck is this sigil puke
Rust is the only mainstream language with lifetime specification, so of course, it's unusual to look at.
Generally, people don't assume they would be able to read a language they don't know - no one whines about Haskell, Scala, Smalltalk, Lisp or Forth being unintelligible to those who haven't spent an hour reading a manual. Yet for some reason, some people expect to be able to read Rust without even knowing what lifetimes are and get upset when they don't understand what's going on. The problem is, the underlying semantics is non-trivial and unusual, so there's no trivial way to express it syntactically.

It literally says so in the manual: doc.rust-lang.org/book/ch03-01-variables-and-mutability.html
> by default variables are immutable

It means that there are quite a few things you can do in C-like languages that are totally reasonable ways of using memory, that you cannot do at all in Rust without turning off the clever safety innovations entirely, which sharply limits the added value of the language.

The fundamental limitation here is in-memory data structures that include objects pointing to each other in complex interlocking ways. Or, more pragmatically, pointer loops. Things like a doubly linked list, where each node has a pointer to the next and previous objects and thus can be walked in both directions, is something you cannot make in Rust, unless you throw the entire safety system out the window and fall back on the unsafe logic that C also uses.

This may sound like an esoteric special case that should usually be wrapped up in a handful of container data structure libraries. But it really isn't. Nontrivial data structures that aren't just containers are a big part of a lot of complex software. Your browser rendering engine likely stores a tree of HtmlNode-like structures, each containing a list of child nodes, as well as a pointer to the parent node, and likely sideways pointers to shit like "next/previous line in this line breaking sequence", "first ancestor node with (some property)", etc. Your 3D video game will contain geometric data structures with each chunk of geometry pointing to all the adjacent chunks; et cetera, et cetera. Structures like this are very common, in any language.

But in rust, this is basically impossible. Rather, you can do it, by making your complex data structures entirely out of unsafe pointers, and thereby *basically* just falling back on C as soon as you are doing something vaguely unusual. Which beats the whole point! Because those unusual things are exactly the pieces of code that you tend to fuck up.

When rust can deal with that without unsafety, it can replace C and C++. Until then, it's a curiosity, praiseworthy as it may be.

>Whom are you quoting?
>.
Pray tell why do RUST shills all use such elocution my dear boy?

>Why don't C programmers meet up to discuss their favorite language
They meet at adult's conferences on embedded systems, safety critical systems, system programming, etc.
They don't have conferences with codes of conducts and people dressed like furries, like Rust, that's true.

Ada is better.

There is a reason why many safety-critical systems are written in C, and I'll share the wisdom with you Rust retards:
The *ONLY* way to guarantee that a system performs how it was specified is to TEST it.
If you have comprehensive tests you can pretty much write in any language. People use C because it's standard, simple, well-known, has good static analysis tools, many implementations for any possible platform, etc.
There are more lines of code to test SQLite than to implement SQLite. Again, anyone competent knows why.
sqlite.org/faq.html#q17

Kids and autists who program in Rust think they can avoid the "boring" stuff like testing because their compiler will magically fix their bugs. It's a completely retarded way to think about it because there are many potential problems beyond memory safety. So they're essentially programming with this false sense of confidence that will actually lead to disasters.

The reason Rust is not taking off is because you have to learn to program in the way that the Rust compiler wants you to program. Two talks that illustrate that point very well:
youtube.com/watch?v=aKLntZcp27M&t=2200s
youtube.com/watch?v=LjFM8vw3pbU

C is used even though it has huge flaws and misdesigns precisely because it's extremely unproductive and badly designed. C is unproductive, so C programs need more programmers, so there are more C programmers and a bigger demand for them. C is incompatible with any language with real arrays and strings, so if you want to be compatible, you either have to convert all your data types each way or stick with C. C sucks so much that techniques used on systems like Multics and VMS to allow programs written in different languages to work together won't work with C because of array decay and null-terminated strings.

The bad design also means C (and other UNIX languages that inherited this brain damage) are more complicated, which is why there are so many "graduates" that only know one language when it used to be common to learn several different languages. The standard is also much longer even though C has fewer features. The language is harder to compile efficiently, which is why compilers are so bloated. The C standard itself is so poorly written and ill-defined that the standards committee could not add a single feature between 2011 and 2018 (besides increasing the version number) because they spent all that time fixing bugs in the standard itself.

Another reason is the huge revisionism campaign started by AT&T shills in the 80s, which is why there are people out there who believe C was the first high-level language used to write an operating system and other bullshit. There are even some weenies out there who said OOP came from C and C++

Your analysis is sound, but the conclusions are too overreacting.
Yes, there are some things that couldn't be done in safe Rust, like the double linked list. This is exactly why Rust has unsafe - but unsafe Rust is still Rust, it's a part of the language, not some antithesis for it. The key here is what some code being unsafe doesn't mean we should abandon the idea of code safety as useless - 99% safe code is better than 0% safe code, 90% safe code (like the Redox kernel) is better than 0% safe code. Hell, 5% safe code is better than 0% safe code. So yeah, not everything can be safe, but that doesn't mean nothing should be safe.
I'm not a native speaker, so I speak in a mix of incorrect and bookish grammars.

What are you even talking about?
Is that code safe against floating point arithmetic mistakes? Against logical errors?
The only way to know whether code is safe is to test it. Flight safety standards are all about how a system is specified and tested without saying a lot about languages, because the first two points matter way more.

If you have an out of bound access, you program is wrong anyway. The fact that in C++ it might result in a particular way of terminating the program and in Rust a different way of terminating the program is completely irrelevant to anyone trying to write actually safe software, because the idea is OBVIOUSLY not to have out of bound accesses in the first place.

> Kids and autists who program in Rust think they can avoid the "boring" stuff like testing because their compiler will magically fix their bugs
No? It's just everyone realizes that testing, whatever extensive, ain't gonna find all the bugs, so to accompany it with an extensive static analysis would improve the end result enormously.

>Should starting a new C project be a crime
Maybe in your commie little eurofag shithole.
Also >medium.com
Seeing that you're trying to force this into a general thread, something doesn't seem very grassroots about this.

>that testing, whatever extensive, ain't gonna find all the bugs

RETARD ALERT

you didn't really address anything he said. his point is a good one, c has excellent tooling that has held up for decades. creating the same tools for a significantly more complex and less used language would leave you with a small handful of buggy utilities that couldn't really be trusted. rust will likely never have even half the ecosystem that c/c++ or even java has, it will be entirely dependent on itself for code security. that's not a safe language in real terms, it's a rather dangerous one. when you see companies investing billions of dollars into an industry that runs on c, you have to wonder what makes them so sure it's a solid investment. if c was the nightmare language you're trying to make it out to be, it would have been supplanted decades ago.

> Is that code safe against floating point arithmetic mistakes? Against logical errors?
Again, just because the static analysis isn't able to find some types of errors doesn't mean we shouldn't use it to search for the types it's good at finding, especially if these kinds of errors account for 70% of all the security bugs: zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ . Borrow checkers isn't a replacement for testing, it's an additional level of safety on top of testing because as we know, testing is never enough.
Welcome to the real world: see cvedetails.com/vendor/9237/Sqlite.html , despite SQLite having the state-of-the-art testing routine: sqlite.org/testing.html .

Question to Rust fags:

Let's say I'm writing safety-critical software (say, flight control).
Does it matter that, when doing an out-of-bounds access, in C++ I get undefined behavior and in Rust I get a panic instead? Are the passengers going to die in a better way if I have a panic() as opposed to doing UB?

What you can't seem to understand is that the language itself is also a thing you can test. C has been tested to hell and back, it's simple to define but the specification is very detailed because of the edge cases discovered over the years. Newer languages can't have such detailed specifications because they haven't had time to develop them. Rust doesn't have a specification at all, it hasn't been tested enough to develop one.

Panic is much easier to catch during testing than UB, which could go on unnoticed for years. Plus, Rust having to pointer arithmetic, it's much harder for a programmer to end up with an out-of-bounds access.

>Plus, Rust having to pointer arithmetic, it's much harder for a programmer to end up with an out-of-bounds access.
Nice. You should remove floating point operations as well, they are the source of many issues.

>C is incompatible with any language with real arrays and strings

Attached: hmmmmmmmmm.gif (320x320, 240K)

why did i laugh so hard at this?

Now you're just moving goalposts, m8. No one cares about "testable specification of a language" outside of academia. C itself is full of UB, so it's like a minefield anyway.
> you can't eliminate all the error
> so you shouldn't try to minimize them at all

>99% safe code is better than 0% safe code, 90% safe code (like the Redox kernel) is better than 0% safe code. Hell, 5% safe code is better than 0% safe code. So yeah, not everything can be safe, but that doesn't mean nothing should be safe.
That is true, but I feel that in practice, while the value of this safety is not zero (no argument there), it is so small as to not be worth the hassle of other aspects of the language. The sort of code where you don't need complex data structures is the work I can do very nearly flawlessly in both C and C++ as it is; having my compiler check it for me is a perk, yes, but a pretty tiny one. It's when I want to do more complex things where I am clearly prone to mistakes as much as the next man, and that's exactly the point where rust gives up and leaves me to my mistakes. Not zero value, but pretty tiny value.

Moreover -- and this is a personal taste that I'm sure many would disagree with -- I feel that a safety checker that is known not to be able to deal with many reasonable and sound ways of doing things (and not JUST pointer loop situations, either) is therefore pretty close to useless even for the cases that it CAN cope with. Because every single time the borrow checker barfs at me because my code doesn't pass muster, I have to wonder whether:
- I am doing something sound that the borrow checker can validate for me, but I didn't annotate it in the right way for the static proof to work, and I need to fix my annotations to make it work;
- I am doing something sound that the borrow checker fundamentally can't deal with, and I should just switch this whole chunk of logic over to unsafety;
- I am doing something stupid that will break in some edge case I didn't think of, and the borrow checker saved my ass.

[continued 1/2]

Fuck you. I just want speed and readability. No other language can offer these.

[continued 2/2]

If I can't tell the difference without a line of analysis that is AT LEAST as error-prone as the original code, the error message is not very actionable. What I will inevitably do is check whether I see any actual mistakes, then try to see if I can annotate it properly, and if that fails I will switch over to unsafe. Which means that for all of the SUBTLE bugs I made, I will end up switching to unsafe code to shut up the borrow checker, after having falsely concluded that the reasonable thing I want to do is just something that the fucking compiler can't deal with. Which means the borrow checker, being entirely right, still fails to help me out in the cases where I need it most.

A big tenet of safety interfaces is that automated safety checking should NOT have many false positives. If a safety check complains at me too often for something that is in fact perfectly reasonable and that I then have to override, sooner or later I'm just going to ignore the safety check, and subconsciously draw the link between "error" -> "safety check acting up for no reason, ignore". I feel the rust borrow checker, as it is, has a FAR too high false positive rate to have significant value.

>This is exactly why Rust has unsafe - but unsafe Rust is still Rust, it's a part of the language, not some antithesis for it.
That is true, but for the sake of this thread (which is about language safety), I see unsafe rust as mostly interchangeable with C. When it comes to making software with my computer shielding me from as many bugs as possible, I don't see rust-used-unsafely as adding anything substantial over C, and far behind C++.

>> so you shouldn't try to minimize them at all
I mean, if the solution to a problem is just to remove the tools, then that's a very easy and obvious solution, isn't it?

We could solve many industrial safety problems this way, actually. Let's get rid of everything that is rotating at high-velocity, and everything with a blade. This should solve most issues, and we can maybe have some section of a factory floor marked as unsafe where we locate those machines.

I'm not saying that Rust is completely bad, but basically the trade off is:
* You give up decades of tools and libraries
* You give up having multiple, stable implementations
* You give up having a standardized language
* You give up many useful language features

In exchange for what?

* It panics instead of doing undefined behavior (big fucking deal)
* You get to put the unsafe code in clearly marked 'unsafe' sections

That's basically it. The reason why no one is using Rust except a few old Ruby fags is that no one wants to make that trade, it's a shitty trade. You'd get a completely immature ecosystems run by political activists, no serious libraries, for some marginal safety benefits.

>Does it matter that, when doing an out-of-bounds access, in C++ I get undefined behavior and in Rust I get a panic instead?
Yes, absolutely.

When your program panics, it shuts down, and some management routine notices that your program crashed and will restart it. A redundant setup may continue without a hiccup by relying on the remaining controller to keep things up, and even if you don't have that, odds are things will work fine if your program just restarts and resumes working after a second of downtime.

Your undefined behavior program, on the other hand, will keep running and start *making the wrong decisions*. Your automatic restart routine won't notice that, and neither will your redundant setup, unless you have a full-power majority vote type of setup like some aviation deployments.

Crashing with a big fat error message will enable you to deploy the repair and recovery mechanisms straight away. A programming humming along and just starting to fuck up is far harder to respond to, because you may not notice how bad things are until it's too late.

>Should starting a new software project in C be a crime?
No. The government should not have the legal authority to dictate what programming languages people are able to use.

>Why is it allowed to build software using inherently unsafe languages?
Everything is allowed unless otherwise disallowed.

>Why do we expect from a C programmer to be an infallible automaton?
Nobody expects them to be infallible. They just expect them to know what the fuck they're doing.

you forgot
* You give up compile time
* You give up code being actually readable

> picture
Here's one of the problems though: there actually ARE good C programmers.
Imagine the argument being made but with medical doctors instead: surgeon kills patient after patient and afterwards blames his knife?!?
What's really broken isn't the tool but the education the programmers (don't) receive. Nobody became a good C (or really any other lang) programmer after a 21 day boot camp.

>C as a second language
>not as a first language

What if I told you that maintaining an entire kernel and shell is much more daunting than maintaining/building a small console app that does one thing.

>some management routine notices that your program crashed and will restart it.
Kek.
The "let's just try again" zoomer / Ruby/Rust fag school of error handling.

> it is so small as to not be worth the hassle of other aspects of the language
Now, this is just pure speculation.
> It's when I want to do more complex things where I am clearly prone to mistakes as much as the next man, and that's exactly the point where rust gives up and leaves me to my mistakes
Do you do anything besides double linked lists? Again, an OS kernel is only ~10% unsafe, for other crates, it's mostly 0% with occasional 1%. And these aren't trivial crates.
> Which means that for all of the SUBTLE bugs I made, I will end up switching to unsafe code to shut up the borrow checker
I mean, if you're gonna give up this easily, then sure.
> I see unsafe rust as mostly interchangeable with C
This isn't true to, unsafe Rust, despite being as unsafe as C, is still a better language ergonomics-wise.
> to remove the tools
To remove completely unnecessary primitive tools and provide with modern equivalents.
> You give up decades of tools and libraries
Rust is arguably the best language to interface with C because it doesn't have a runtime.
> You give up having multiple, stable implementations
> You give up having a standardized language
Choose one. Having single implementations means you don't need a standard.
> You give up many useful language features
Yet get even more new ones.

> In exchange for what?
> It panics instead of doing undefined behavior (big fucking deal)
> You get to put the unsafe code in clearly marked 'unsafe' sections
Well also the fact that kind of bugs that cause the most security vulnerabilities and bugs is statically prevented. Also you get to use a modern language with lots of nice features instead of outdated trash frozen in time, and I mean it besides the BC/safety aspect.

and its not because of the aids ridden trannies and fags

Yes, exactly. You will find that EVERY SINGLE PIECE of critical embedded software has some logic to restart the damn thing if it visibly breaks. It's not great, but it beats doing nothing.

>Choose one. Having single implementations means you don't need a standard.
Yes in the same way that not wearing clothes means you don't have to do laundry.

seriously you can instantly tell an inexperienced or even worse a totally retarded low IQ FAG when he says that Rust is great and no need to stay with C, what proves his the latter (a low IQ retarded FAG) is when he mentions the SJW argument to bash C

What about write unsafe parts in C/C++ and safe in Rust?

> he thinks it's better for a program to continue to work after OOB access
How to tell cniles itt never had a job or are really shitty at it.

Fuck you
Fuck your safety
Fuck your ideas, and fuck you 2nd time for pushing them by force onto others

Just learn to CODE IN C you fag

>C is dead the tranny says nervously for the third decade in a row

C didn't have a standard in the first 15 years of its existence and only get one when incompatible compilers started to pop up. The vast majority of the languages don't have a standard and it doesn't affect them in any way. So why should the Rust community waste its time on it, especially if the language keeps growing?

>the seat belt argument
people die regardless of seat belts, focusing on the survival rate of deaths saved by a seatbelt and ignoring all the car fires that killed a stuck driver/passenger is just as retarded as the whole rust vs c argument.

The Rust faggots should just prove C wrong by example, build something useful, tell me the resource it took and compare the cost/time/safety/long-term maiintance.

> bargaining
Good.

Attached: XilsKrW.png (1024x1024, 112K)

Daily reminder to learn Haskell and become one of the master races in the ivory tower.

>Do you do anything besides double linked lists?
Yes, all the flipping time. Structures like this are NOT uncommon peculiarities that occasionally happen as a single magic component that can be wrapped up in a black box.

If pointer loops were a thing you would occasionally see in container libraries, it would make sense to accept this as an occasional annoyance that 95% of code just doesn't have to deal with. But it's not.

I find that in toy software, I rarely need complex data structures, and some vectors and linked lists and red-black trees are about all I do that might warrant pointer cleverness. But in actual serious software, the complex software that does actual involved computations rather than just scripting the real powerhouses around, complex data structures are a big part of what they do. Most of the code that does the actual heavy lifting relies on it. And when you write clever custom data structures on a weekly or even monthly basis, which for example every game engine does, then Rust is an ongoing hassle far more than it is a solution to anything.

Why dont manly men go on PRIDE PARADES?
Coz we just do what we do, we go to work, build safe and secure systems in C and go back home to our family (yup, I have wife and kids, we are all white btw, and we go to church on Sundays)

>Quote from medium
OH NO NO NO NO NO NO

Oh, I wanted to write Rust, but it lacks some performance. Your graph is shit, sorry user.

>needing CoC so your community doesnt sue itself to death for pronouns
fags

>it doesn't affect them in any way
>C$ getting the eight revision in a decade while devs hide in a corner to cry

>going to church
Cringe.

>medium
>paying neo marxist to push marxist propaganda against the western civilization
>rust
>actually the same trannys

boy some ppl are so lazy