Babbies first programming language

doc.rust-lang.org/1.7.0/book/loops.html#loop-labels

That's why I said you can simulate goto with macros. Rust still doesn't support jumping to labels on arbitrary lines of code.

frankly no reasonable use of goto except in nested loops, please tell me any reasonable use case in Rust if you have a one

If you truly believe you'd never make a mistake the Rust compiler could catch, your an idiot and dangerously overconfident. People like you shouldn't be systems programmers.

We should use all possible tools at our disposal to make sure our code is secure, from languages with advanced type systems, fuzzers, and quickcheck-like shrinking, to sandboxing and isolation. If you think because you "know what a register is" you don't make mistakes, you're more dangerous than a pajeet who knows only Java.

There isn't one, I don't think they should add generic goto. I was just clarifying what I meant when I said "for the most part" in . I didn't know they'd since added C unions, which were a major FFI wart forcing you to awkwardly use transmute in Rust in the past.

The consequence is that its a literal fucking nightmare to get anything to compile in rust.

Rust doesn't have higher-kinded types like C++ does.

Still a better language though.

>your an idiot
Programmers use C because they are competent enough to never make mistakes, or because they are learning to program or somewhere in between
Rust is too difficult for beginner and intermediate programmers and too easy for expert and master programmers

There is an alternative use for goto, but only in languages like C that don't have RAII. Basically, if you've got a function with multiple points that can fail with an error, and you need to clean up resources at each point, it makes sense to just goto an error handler within the function that cleans everything up at once. This is particularly useful in kernel code where you're likely to be holding onto plenty of resources you need to allocate yourself.

It is completely useless in Rust, because you can just impl Drop and flat out return your error without writing any cleanup code in the function at all.

>>your an idiot
>Programmers use C because they are competent enough to never make mistakes.
Thanks for pointing out my typo and giving me a chance to restate: you're an idiot. No programmer is "competent enough to never make mistakes". If you think this, you're either the first perfect programmer in the world, you're deluded, or you haven't written enough code or worked on large-scale enough projects to understand that bugs are inevitable.

>The point of a good programming language is to curtail the stupidity of bad programmers.
No.
The point of a good programming language is to allow a programmer to tell a computer what the fuck to do.
>oh no no no I can't let you make the computer do THAT, silly goose :D
Fuck off. The only things that a language and compiler should prevent me from doing are the things that are literally impossible.
Still using C. Not going to stop. If you don't like it you can lick my fucking asshole.

If you want to improve on C, your motto should be: "If it parses, it compiles."
Anything less means the compiler is playing god.

You should check out "Python" and "JavaScript". Most languages that improve on C try to improve the "type system", which is the part of C that makes your code not compile when you pass variables of the wrong "type" to a function.

Lole if the compiler says its legitimate, it is xD
I luv using goto macros in rust!

Attached: 9ae.jpg (1024x521, 48K)

>Most languages that improve on C
But, user, there are no such languages

isn't it ironic that the people here in Jow Forums who defend C are the very people who never programmed in it or had a job, ever

This is truly you just stroking your ego isn't it? Modern C++ is incredibly hard to read and understand if you haven't used it for years.

Rust has some weird concepts, but you can grasp them within just a week or two of using it.

In a real world situation you'd spend 20 hours coding a multithreaded pprogram, and 100 hours debugging with C++, With rust it would be just 10 hours coding and 5-6 hours debugging, because errors stem from logical flaws, not data races.

It's more complicated to learn to be at all productive in Rust than in C++, because the very basics of the language require learning more stuff. In Rust, you need to understand the borrow checking rules, references, scopes, function calling semantics, etc all from the very start, even to write relatively simple programs. In C++ things ultimately get more complicated, but you can use pointers without understanding C++ references and C++ scoping rules. In

To elaborate, I completely agree Rust is simpler in the long run. I write C++ professionally and often wish I could be using Rust. But I would not say it's a good beginner language. People need to use C or C++ first to understand why all the borrow-checker rigamarole matters.

Rust sucks for the very fact that you are forced to work within the constraints of the language and can encourage you to reinvent the wheel in order to circumvent the type system. Jonathan Blow did a good talk on it.

All the idiots trying to push Rush fucking drivw me nuts.
It's as sóyboys collectivelly decided to forget that Ada exist and has been doing what rush does (and much more) for the last 35 years

Not that guy but I agree. Rust may appear simpler, but in order to write anything at all you need to understand semantics of the different reference types, how to use them properly and how to structure your code. C++ is significantly easier to write and become productive with because you don't need to know to how the whole language works to get it working, you can use the simple C parts or use the object orientated parts. And yet after all that time knowledge in learning Rust, you don't even come close to the amount of power you could learn from C++ in the equivalent learning time. And all of Rusts memory safety features are basically useless to modern C++.

>The fact that Rust prevents mistakes at compile time is a good thing
This really isn't nearly as true as rust shills want you to think.
marc.info/?l=openbsd-misc&m=151605305629876&w=2

this is the most retarded thing I've ever read in years, I almost got cancer

Wrong.
A good programming language doesn't even consider the existence of retards.

>everything that would be differentiate a good from a bad programmer is not allowed
>the ability to autistically check for memory leaks and replace stuff by shitty text macro "would be differentiate" a good from a bad programmer

Explain what's wrong with it.

>boy I sure can't wait for the next shitty Rust thread

Attached: 1537009695693.jpg (466x700, 48K)

I'd be fine with Rustoddlers if they weren't that obviously undeducated and obnoxious about it. Just look at Steve's "C runs on a virtual machine" shitpost.

rust is great but its community bugs the shit out of me, and not because of sjwism (which i'm all in favor of) but because of other stuff

like, they seem deadset on taking rust's beautiful error handling system and throwing it away in favor of what amounts to exceptions, with pervasive panics everywhere and errors that implement error-chain and failure

also they refuse to back down from crates' stupid way to allocate names

>rust is great
>sjwism (which i'm all in favor of)
Out.

>Moreover, *good* C code is about as safe as it can be.
Wow, that guy _is_ a retard.

>and not because of sjwism (which i'm all in favor of)
It's like you don't want stuff to be productive

>What is context

the rust community is so evangelical and annoying, not to mention the politics they so adamantly want to involve in the project. just that is enough for me to want to avoid it for now.

Attached: mad.png (100x100, 23K)

This statement, while correct, is retarded without context.

Only language brave enough to bring back clippy and make it a first class toolchain feature.

>Ada exist and has been doing what rush does (and much more) for the last 35 years
I wish that was true, user.

>everything that would be differentiate a good from a bad programmer is not allowed

That's right, bad programmers leave memory leaks, stack overflows, out-of-bounds shit everywhere.
Also, not all programming is systems programming.

>C++ is significantly easier to write and become productive
>productive
"it compiles and launches" != "productive"
If your code blows up or is easily hackable, is that "productive"?

you never worked in software professionally and even less in a team. Everything you're saying is cringy

how do you say "im good on this thing bro" in CV?

the point of any job or tool is to deliver value (feature-rich, bug-free, maintainable software), not to differentiate those good at the job from those who are bad

Why would you use a systems programming language if not for systems programming?

Personally I like Rust's type system, emphasis on unboxed values, and borrow checker enough to use it for normal applications and not just system stuff.

tbqh Golang community is the most hostile and annoying community I've ever seen

Keep going, give us more of your anti-meritocracy insights

can't we implement stuff like this:

rust:
crypto, xml/audio/image/binary*-format parsers/validaters, ssh, tls, minimal system resource apis for sandboxing, etc.
C:
kernel/interfaces/close to hardware device abstractions/drivers
C++:
buissness software, anything that needs a lot of written down logic that fits well within oop and/or uses a database, real time software

and all be friends?

by friends i mean HATE together on the crowds of
java, c#, haskel, swift, kotlin, scala, php, perl, ruby, python 2/3, go, javascript/electron or rather anything that doesn't value efficiency and has a perception of being slow because of memory miss-management and crappy runtime issues. in short that programmers of said stacks can't solve because they aren't used to it and that why their apps take 2 seconds longer to start.

i'm making an exception for stuff that compiles to C like vala or nim as a peace offering.

>babbies first
baby's first

Attached: 24174.png (433x716, 348K)

Same thing could be said of Rust. Just because it compiles doesn't mean it is free of bugs.

You are looking at things from the wrong angle. Rustc is just giving you advice, and once your code compiles (which isn't that hard after practicing with a couple of small toy programs) you'll probably need to debug much less, and less obscure errors.

Yet another bloody dialect of C

t. never got beyond VB6

But it's free from the most common and exploitable memory errors, which are incidentally some of the hardest to debug. It's a significant improvement.
Why does he bring up the integer overflow problem? Is there any static analysis tool that could have catched that? Also, I wonder if the bounds checking that rust does wouldn't have catched the overwrite outside of the hash table. Nobody said Rust would eliminate any kind of vulnerability, but it definitely is going to eliminate a big chunk.
>can't analize the binaries
But you literally can?
>You'd have to deactivate the safety guarantees
Most of the time, you wouldn't. Then, when you eventually have to, you don't loose all of your guarantees, and you have a smaller section of the code to debug.
>There is no use for abstraction when writing a kernel
I mean, not at all? Not even a handy (free) iterator?

I really don't get the laziness of not sticking with a few extra rules (that were good practices in other languages, to begin with) and miss out the possibility of being less exploitable and debugging less.

annoying syntax: the language

>Why does he bring up the integer overflow problem? Is there any static analysis tool that could have catched that?
Yes.

That one I can actually agree with
Well, that's quite nice. I wonder why didn't they use it over anything that allocated memory?

You have the freedom to write good code or write bad code in another language where you belong

Experimental GC-as-a-library in Rust: boats.gitlab.io/blog/post/shifgrethor-i/

I've never written anything more complex than a math problem solver for uni, but want to start a side project text editor, is it a good idea to write it in rust?

>anything that doesn't value efficiency
Rust is precisely that, but at the programmer level
When you know what you're doing, C gives you exactly the toolset you need to write safe, correct, performant code that runs as fast as possible
Whereas the Rust compiler forces you to only write programs it knows how to prove correct, which is a very small group of programs, mostly microbenchmarks
Doing anything it doesn't expect requires literally turning your organs inside out and tying your code in knots

What do you expect? Steve is a fucking webdev fag who doesn't know shit about Rust but spends all his time shilling the language on social media.

>Most of the time, you wouldn't. Then, when you eventually have to, you don't loose all of your guarantees, and you have a smaller section of the code to debug
The times that you don't have to use unsafe in rust, there are tools for c that catch the same memory issues but c has the bonus that these tools work everywhere since there's no concept in unsafe blocks of code. With the tools you end up actually bring even safer. Things like heartbleed didn't happen because c is dangerous it is because the OpenSSL team might as well have intentionally written in bugs since they refused to have basic security practices. There's a reason openbsd forked OpenSSL. They still refuse to have security standards.
>>There is no use for abstraction when writing a kernel
>I mean, not at all? Not even a handy (free) iterator?
How about you write a kernel before you pretend to know what your talking about. This is an actual kernel dev.
>I really don't get the laziness of not sticking with a few extra rules
Agreed, you clearly missed his point.
>But it's free from the most common and exploitable memory errors
Likely all of these common errors have static analysis tools that find them for you.
>Why does he bring up the integer overflow problem?
If you knew anything about the bugs that have come over the years you'd know that interger overflow is a big deal.
>Also, I wonder if the bounds checking that rust does wouldn't have catched the overwrite outside of the hash table
Unless you're using unsafe. Funny thing is that the static analysis tools for c would catch it.
>Nobody said Rust would eliminate any kind of vulnerability, but it definitely is going to eliminate a big chunk.
False, all that's going to happen is everyone is going to feel safe and then write extra bugs in their logic. There's a lot more to security than buffer overflows.

Attached: obsd.png (1000x600, 125K)

And C++ has tools to remove the most common and exploitable memory errors, with RAII, references and smart pointers.

Jesus Christ, Rust does not "force you to only write programs it can prove correct". When will this fucking meme end. Unsafe is a part of Rust YOU ARE SUPPOSED TO USE. Rust just forces you to put the code it can't check inside "unsafe", too minimize the audit surface required to verify a program is memory safe.

If you write a linked list in Rust, you aren't supposed to use safe Rust. If you write a vector in Rust you aren't supposed to use safe Rust. but both linked list and vector can EXPOSE A SAFE API, and they're part of the standard library so you don't have to write them.

Ehh, not trying to go full zealot, but I see some points to respond to, so I will
>How about you write a kernel before you pretend to know what your talking about. This is an actual kernel dev.
This seems like an argument from authority. In a kernel you obviously have to acces memory secuentialy. Why not use an iterator here, which will keep your code mantainable and eliminate the need for one ounds checking? (non capturing) Closures are pretty much matched by inline functions in these aspects, but at least they are nice to write.
I suspect that the dev in the article was talking mostly about expensive abstractions.
>Likely all of these common errors have static analysis tools that find them for you
Isn't it more practical using your compiler? There are also other benefits in the usability side of things.
>If you knew anything about the bugs that have come over the years you'd know that interger overflow is a big deal.
My question was, why is he bringing up an error that the tools being discussed have never claimed to solve? Not that it isn't a big deal.
Also just checked and you can force overflow checks with a compiler flag (which would turn it into a runtime panic, falling in the denial of service), which you can make into an abort. So I guess there is room for improvement, but is not a totally neglected area.
>Unless you're using unsafe. Funny thing is that the static analysis tools for c would catch it.
Not totally correct. You'd have to use an unchecked dereference, which is indeed only available inside the unsafe block, but is not the default, and actually has unsafe in the name too, so if you are using it, it's pretty much the same as writing the C code without the tools (imprudent), only that it's more explicit.
1/2

>False
Uh, Whats false? that Rust hasn't claimed to solve everything? Or that the problems being eliminated are not that many? I guess you raise good points about how the culture of programming in rust could lure into a false sense of security, but then again, thats hardly the fault of the tool. Just like fuzzing is becoming more pervasive in the Rust comunity, it could also happen to the implementation of static analisis tools/features for other security critical bugs.
>There's a lot more to security than buffer overflows
Theres also iterator invalidation, or race conditions. Rust isn't solving all problems, but it is solving more than one.

To be human is to err. Even an experienced developer will make mistakes from time to time. Mistakes in low level code can be disastrous. It is infinitely better to catch those mistakes at compile time than runtime.

Rather than circumventing the type system, you should be working with it.

>The point of a good programming language is to allow a programmer to tell a computer what the fuck to do.
You can do that with assembly. The point of programming languages is to make it easier to develop programs. The development process consists not only of writing the code, but also debugging and maintaining it. As the latter two tasks can be more time consuming and annoying, it is best to shift as much as possible to the programming part.

Even if it takes longer to write, and you have to fight with the compiler the whole way, if you can spend less time in debugging and maintenance, then all the better.

>Still using C. Not going to stop.
Well that's fine. But don't knock on Rust for legitimately improving upon the capabilities of a systems programming language.

>>How about you write a kernel before you pretend to know what your talking about. This is an actual kernel dev.
>This seems like an argument from authority.
I don't tell rocket scientists how to build rockets. I'm not qualified. It's not authority it's expertise. No one authorized the kernel dev to be knowledgeable about developing a kernel. You cannot just pull things out of your logical fallacy bag expect them to be right.
>Isn't it more practical using your compiler? There are also other benefits in the usability side of things.
Are you talking and adding this to the compilers? It flat out breaks the unix minimalism. One tool for one job.
>My question was, why is he bringing up an error that the tools being discussed have never claimed to solve? Not that it isn't a big deal.
>My question was, why is he bringing up an error that the tools being discussed have never claimed to solve?
Why the fuck would I know what he's thinking?
>Also just checked and you can force overflow checks ... So I guess there is room for improvement, but is not a totally neglected area.
Fair enough
>Uh, Whats false? that Rust hasn't claimed to solve everything?
Rust supports claim it fixes and detects issues and there is no equivalent for c which is either an ignorant or a complete lie.
>>There's a lot more to security than buffer overflows
>Theres also iterator invalidation, or race conditions. Rust isn't solving all problems, but it is solving more than one.
You are far off. Much of the time someone breaks into a system it's not because any issue that can ever be detected. It's literally issues with the application logic itself. The issues that rust is trying to protect from are very uncommon now. Granted nothing is perfect but Rust is trying to solve a problem that more or less doesn't exist anymore. Even given buffer overflows there are mitigations in modern operating systems such as stack canaries.

>The point of a good programming language is to curtail the stupidity of bad programmers
this is false. In the right hands, """unsafe""" languages like C can be an immaculate display of discipline and skill, both of which are lacking in the modern software industry where node and python run rampant. We've created a .com bubble 2.0 because VC keeps pissing money away on shitty software that purports to fix kludgey bullshit, when it reality it's just more kludgey bullshit on slapped on top of the original kludgey bullshit. God forbid we actually try to be good at what we do.

read my above statement, but consider the engineering feat that is the Rust compiler. The fact that that shit even works is fucking impressive. I spent some time learning a little Rust, even though I have no use for it because I'm good enough at C to not need it. Rust is an example of brilliant design. It's just a really fucking good programming language. Rust lets you do anything you can do in C++ or C, you just do it differently and close-minded spergs can't wrap their head around it.

>ISO C++14: 73 different keywords, 70 operators
>ISO C11: 44 keywords and 37 operators
>Rust: 35 keywords, 53 operators
>Rust is more complicated than C++
Obviously that isn't a perfect heuristic, but I think it gives a pretty good idea for just how bloated C++ is. Rust is unique, and it has a high initial learning curve as a result. After that initial stage of learning the borrow system, Rust is more orthogonal, more expressive, and every bit as powerful as C++.

I realized long ago that the Rust hate is a crazy advanced form of gatekeeping.

>You cannot just pull things out of your logical fallacy bag expect them to be right.
It wasn't that big of an assumption to assume there would be secuential access to some memory.
>One tool for one job.
But then you end up with code that needs refactoring, instead of already having many (not all) guarantees buit into it. Also, I'm not a Rust contributor so idk what should they add desu, but what it already has seems to work for many. The experiences around bringing Rust to production show that it really lowers the manteinance code in many real time and low level (mostly graphics) aplications
>inb4 argument from majority
I know, but it at least is a hint showing that there is a valid niche for it. I'll admit that kernel development might not (or might) be Rust's forte, what do I know? It is still pretty obvious that kernell development could be way better than how it s whit C, even if Rust aint the anwser.
>there is no equivalent for c which is either an ignorant or a complete lie
I'll admit that I have learned several things about static analysis in C with this convo, but then again the interation of these patterns in the language itself (something C++ tries to apply, but just as a set of best practices) is a more effective way to lead the development of large projects toward this path of memory safety.
Kernels might be the one niche where the analisis tools are standanized enough to already cover what Rust does.
>Granted nothing is perfect but Rust is trying to solve a problem that more or less doesn't exist anymore
Well, that connects with what I said just now, that maybe kernell development is the one place where Rust is already replaced with something else.
>stack canaries
And randomized memory layouts, right? Well, thats pretty safe, but wouldn't it be easier if the compiler checked that logic for you, so you hadn't to write it?

>Internet comments that use capslock on certain phrases

>green meme arrow posts

Attached: ferris-pepe.jpg (350x300, 33K)

>The point of a good programming language is to curtail the stupidity of bad programmers.
Oh. From now on, I'll take the anti-C/C++ shilling as a compliment on my intellect.

>Any systems programmer who needs the language to protect them from fuckups shouldn't be a systems programmer.
This philosophy is what has brought decades of bugs.
And that on software developed by competent developers not fizzbuzzers as you.
kys

>isn't it ironic
Not really. Who else will defend C?

>perl, ruby, python
Yeah, I'm sure you used Rust/C/C++ as scripting languages and found them viable.

>>babbies first programming language
If only you had ANY clue how hard Rust actually is...
Rust's static borrow checking alone makes C++ looks like child's play. I've been writing C++ for over a decade at work and for personal use.

A text editor is a good first project in every language. That and an IRC client for fiddling with networking.

>A text editor is a good first project in every language

No, text editors are much much much more complex than they seem, you need a very good performant language with excellent support of concurrency and data race prevention like Rust to make a good editor in the current year, also google xi-editor

>to make a good editor
A toy project doesn't have to be the next big thing.
A nano-like (if TUI) or mousepad-like (if GUI) editor is fine.

Making an error != retard.
A good language takes into account the programmer can make a mistake, but it only considers professionals who make mistakes, not retards who make mistakes.
There is a difference.
The difference: C++ and Python.

of course, but I need to remind you that editors deal with many IO blocking operations, memory copying/moving/mapping and even graphics with acceptable fps, if you want to write the next vim, you need to deeply understand how to deal with concurrency, data races, and non-blocking syscalls

Not him but even the text editors are pretty fucking complex once you think about implementing asynchronous rope and a textview model. Not to mention parsing hundreds of encoding schemes and Window's retarded newlines.

t. writing a text editor

>Rather than circumventing the type system, you should be working with it.
You can't circumvent a type system that doesn't let you do anything interesting. Hence why you have re-implement things.

>ISO C++14: 73 different keywords, 70 operators
>ISO C11: 44 keywords and 37 operators
>Rust: 35 keywords, 53 operators
>Rust is more complicated than C++

>I spent some time learning a little Rust
Really you shouldn't talk if you don't know much about it. The hardest part about Rust isn't remembering the keywords, the hardest part is working with the high friction language and understand all the reference types and actually using them properly.

>Rust is more orthogonal, more expressive, and every bit as powerful as C++
I agree that Rust is more orthogonal, but that is because Rust doesn't have to maintain backwards compatibility with C. Otherwise, Rust is far less powerful and expressive than C++.

Care to give an example of something you can do in Rush that Ada doesnt to better?

i'm a tech lead and in charge of hiring at my cunt. if i see rust, javascript, html, word, ruby on rails, code of conduct, or cobol on a CV, it goes into the garb

i answer to no one

t.

Attached: 1525095830105.jpg (315x315, 21K)