Sell me on Rust

ive been teaching myself cryptography the past couple weeks by writing various crypto related programs, i decided to try out rust and i have coding extensively in it now. my background is in c++.
there are lots of cool things about rust but all in all, i wouldnt say its ever going to replace c or c++ altogether. unfortunately it solves some problems and introduces others.
rust introduces many abstractions to keep you safe, and thats great, but so far, im not sure if i think its worth the trade off. in c++ its easy to write safe code as well, but its also easier to write faster code because it is less restrictive. and since c++ has less complex semantics, you also have a better idea of exactly what your code is doing. rust will force you to make copies and put stuff on the heap even in cases where you know it will be fine not to.
for example, i was writing a program to calculate probabilties of possible ciphers which were applied to text. i decided this would be a good chance to try out multi threading in rust. it was almost exactly the same as the way I would have done it in modern c++ -- except rust's life time feature forced me to make copies for various objects that were used in the closure each thread was executing, even though I knew none of the variables would leave scope while my threads were running due to my programs design. so i had to write a lot more code to make my program slower, for no reason. it wasn't any safer.

another good example is how borrowing a mutable reference to something keeps you from borrowing it immutably. this is to prevent bugs like having a pointer into some data behind a vector, and then some other scope resizes the vector causing the buffer to be re-allocated.
Thats great that the compiler can actually prevent that bug at compile time, and i think lots of people get bit by this bug at leaast once while they are learning c++. but it comes with a trade off. now in cases where you know that will never happen, and you want to both read and modify the contents of a buffer across various scopes, you cant do that, and you are forced to make an allocation and copy the buffer contents. like the sheer number of pointless copies that rust forces on you in the name of safety, makes me want to pull my hair out.

C-nile here, am I retarded for disliking rust because it makes things too easy?

i think i know what you mean. in my mind though, its not that it makes things 'too easy', its more that it forces you to do things in a very particular, restrictive, and not altogether desirable way.

like you dont get to make as many decisions, and it just isnt as fun to write code in rust. rust makes many decisions for you, even if they dont correspond to your desires.

Exactly, I like my hacky-garbage code because it made me think

It's not making anything easy except sidestepping dumb mistakes. You have to pay attention to lifetimes and types in either language.

Yes, but just switch to hating it because it has no GUI libraries and you’ll be just fine.

but my problem with it is that its not just sidestepping dumb mistakes, it also prevents the programmer from doing many perfectly safe things, restricting the number of creative possibilities.
what is the point of this system if it is only good for catching 'dumb mistakes', anyway? if a programmer makes a dumb mistake more than once or twice (maybe three times), then there is no helping them anyway. its like i said, once you encounter a bug where your pointer into a vector is invalid cos it was reallocated in some other scope, and you figure it out, you have learned a hard lesson and dont make the mistake again anyway, unless you are a total retard who loves pain.

sometimes when you are just hacking out a quick program, its perfectly fine to just pass raw pointers around and shit like that, when your program is simple enough that you know its safe. its so much easier and simpler to write code like that, you just pass a pointer around without fear, not having to write robust perfectly safe code. and often, doing that is quicker at runtime and compile time. now, would i do this if i was working on a larger / more complex / more important code base? obviously not, because i know better. do I really need the compiler to tell me something so obvious, given the huge drawbacks?

I am gonna put my time into Rust when tracktion capable companies get behind it. Mozilla is a joke.

Nearly every major advance in type system design has been about catching dumb mistakes. Mistakes don't need to happen 'more than once or twice' to be absolutely devastating in effect.

Pretty much any major software project in C has some track record of gaping vulnerabilities that could have been prevented with stronger typing or lifetime analysis. If you're going to take the position that anyone who stumbles over memory issues on multiple occasions is retarded then the only conclusion to draw is that everyone who programs is C is a retard and you haven't written enough to find this out about yourself.

Reasons to use Rust:
You want a multi-core, concurrent program.

Anything else will take forever to build, the level of abstraction is very low. If you want strict type checking et all, use OCaml w/Jane Street libraries.

>introduces others
The borrow checker gets highly complex with any large program, it's actually easier to reason in C++ with a pile of pointer arithmetic than it is the borrow checker.

>if you want strict type checking go use this slow piece of shit dead language
no thanks

i was talking exclusively about c++. c is very different than c++, its very easy to make these mistakes in c because it provides you with no higher level tools to build higher level memory safety semantics for yourself using the type system.

> Pretty much any major software project in C has some track record of gaping vulnerabilities that could have been prevented with stronger typing or lifetime analysis
possibly, or possibly not. often times a lot of these bugs are considered so nasty and surprising precisely because they were very particular cases that static analysis tools missed.

> If you're going to take the position that anyone who stumbles over memory issues on multiple occasions is retarded then the only conclusion to draw is that everyone who programs is C is a retard
those are your words, not mine. like i said, i think as soon as you are working on a program that is bigger than "tiny personal project scale", you absolutely have to start building more robust semantics to avoid memory errors. you cant really do this in c, so personally, I wouldn't use it for such products. but i wouldnt say that the people who made the decision to do that are retarded.

Lisp could have fixed all these problems 60 years ago.

nah i totally disagree. its very easy to write some monstrous c / c++ program that you HAVE to dynamically analyze to locate the bug, which is a magnitude more complex than dealing with it at compile time. personally i will always prefer to deal with shit at compile time. thats why i dont write c++ programs where you have to think about pointer arithmetic and are relying on your own diligence to not create inconsistent memory state. thats one of the whole reasons c++ provides you with higher level features

>Reasons to use Rust:
>You want a multi-core, concurrent program.
But why not Erlang or Ada or any of myriad other languages which can do that without being hipster faggotry?

Ada is a dead meme
Erlang is for large fault tolerant systems, and even then it's a better learning experience that you can then apply in performance efficient languages since Erlang is not that fast at doing everything.

I like it because it's like someone actually tried to make a useful successor of C, as opposed to the huge pile of crap C++ is.

c++ is good, definitely one of the greatest and most influential languages

Erlang/Elixir + OTP is great... until you need to debug the library. Good luck with that. We're talking gigantic abstractions, piles of obfuscated C... you'll be rewriting a shitload of libraries like Discord had to do.

Rust doesn't even have a debugger user.

Discord is Erlang? Also am I the only one that dislikes the Ruby-like syntax of Elixir? Erlang has some bad spots, but damn is Elixir annoying to me.

> Rust doesn't even have a debugger user.
? Im pretty sure it does. I havent look into it much but ive seen people talk about it.... never used it yet though.

>Why would I still have to deal with low level concepts such as pointers?
This is how you should realize that Jow Forums's opinion on anything is worthless.

Discord is Elixir which is basically Erlang w/different Syntax. Read this, all the modifications they had to do: blog.discordapp.com/scaling-elixir-f9b8e1e7c29b

Not that I'm shitting on Erlang/OTP. If you run a moderately scaled site, it's amazing as in you never, ever need to do maint. It just runs forever. However if you're doing something more custom than just passing messages, you'll run into serious problems with OTP and need to rip apart those libraries.. good luck.

I code C++ for a living, but I still think it's crap.

>Rust doesn't even have a debugger user.

of course it has

so what? probably at least half of c++ users are people who suck at the language and write awful code. i code c++ for a living too (actually i recently quit, but my career has always been professional c++ programmer )

You can kind of use gdb with a pile of hacks but there's no official debugger yet. This is the problem with Rust, they keep cramming features and don't work on crucial things like a native debugger.

Your example of reference invalidation is common to C and C++ and is one of the gaps in C++'s toolset that Rust aims to plug. It's one of those 'dumb mistakes' that there now exists an answer to.

>those are your words
You said anyone who fails to learn from that kind of error is 'a total retard who loves pain'. There's a lot of bad apologism for C and C++ on this board that sounds like that and basically covers for the languages' design faults by calling anyone who laments them retarded. If that wasn't your intent, then great.

>i wouldnt say that the people who made the decision to do that are retarded.
I think most people who start serious projects in C are driven by well-considered performance and compatibility constraints, but the ones who aren't probably really aren't very bright.

What do you mean? It's not that I don't understand them, it's just that it's cumbersome to use.
In Swift e.g., you don't have to deal with it in most normal code. You can just rely on ARC for resource management.

So basically Joe lied to me about erlang being able to handle millions of processes?

I've yet to find a professional C++ programmer IRL who says "c++ is good"

i think it would be easier and better to integrate it with gdb than writing an entirely new debugger anyway.

It handles all that no problem, but only for certain tasks, Discord (if you read that post) had to make a ton of changes and tune BEAM because once you stray from the original task of Telecom message passing, like needing to be able to mute somebody in a chatroom with 30k people, you run into serious problems and need rewrites.

However if you want to write bots to do arbitrage on a hundred altcoin shitcoin exchanges erlang is your pal

That's because any professional C++ programmer is going to be stuck maintaining legacy junk which is basically 20 years of horrible C++ code and he's the one that has to keep it going which is a tedious annoying processes.

True

This is disappointing.

And who do you think is to blame for that "horrible C++ code"? Don't you think that in part it's the language itself? If a language enables or encourages writing horrible code, then it will be written by someone.

>rust
>good syntax
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHHAA

Ada is very much alive, dumb Rustfaggot.

>And who do you think is to blame for that "horrible C++ code"?
People from 10-20 years ago who adopted C++ when it was pure shit.
> Don't you think that in part it's the language itself?
I agree, early C++ was pure shit. No one will argue that.

They made C++11/17, etc for good reasons.

Build whatever you want in Erlang/Elixir anyway.
But if it's something you plan on running a long time then maybe think about using something else and doing it all yourself, you can offload the concurrency bits to Erlang and the business/program logic to whatever else you want, like writing non OTP Erlang.

Name one language that doesn't enable writing horrible code.

> There's a lot of bad apologism for C and C++ on this board that sounds like that and basically covers for the languages' design faults by calling anyone who laments them retarded.
they aren't design faults of these languages at all. its like with everything in engineering: a trade off. c is a very simple langauge that gives you some programming constructs that are miles above coding in assembly, but also very minimalistic compared to modern high level languages. there are very particular use cases for such a language, and adding in rust-level memory safety semantics wouldn't improve c at all, it would make it worse, because no one uses c because it has extreme memory safety semantics: they use it for the opposite reason.
c++ provides all the tools you need to add in whatever kind of memory safety checks you want. technically you will always have the ability to circumvent them though since you still have raw pointers and even inline assembly. c++ lets you be as meticulous (or not) as you want at compile time. its not at all a short coming of the language that they dont strip out features that are useful far more often than rust's totalizing borrow checking and lifetime semantics, just to prevent the possibility of mistakes. its very easy to write memory safety code if you know the basics of constructors and deconstruction, and basic principles of abstraction.
people who lament these aspects of the languages are retarded, absolutely. its like complaining that a hammer isn't a screw driver.

Would it be a good idea to just write my own supervisor and actor model in another language?

i just told you that i am one such person. Im definitely not saying its perfect... but is it good? absolutely. actually its my favorite language

ARNOLD C
lhartikk.github.io/ArnoldC/

Attached: flat,550x550,075,f.jpg (550x528, 24K)

I'll name two: Ada, Parasail. Sure, it's still possible to write horrible code as in any turing complete language, but you have to put in work for it.

A strictly typed language sure
Jane Street/IEX (uk) does this.

But I would just go with Erlang/Elixir anyway and roll an MVP for whatever idea you have, and sell it immediately. Let them work on the OTP libraries in anger

Absolutely, unequivocally, checked and based

I prefer Swift instead. nvim+

github.com/apple/sourcekit-lsp

We're gonna get there, at the expense of Apple.

>and sell it immediately
That's kind of sad to make something and then just throw it away like an orphaned bastard for quick cash.

I agree that it improved with C++11 greatly but it still allows the old shit. That's the problem. Rust has most of the stuff C++11 makes good as it's foundation. RAII + Move semantics + references (as opposed to pointers) + smart pointers + ez concurrency.

That's why I like Rust better than C++.

>quick cash
Which pays you to sit around for 6 months rewriting highly concurrent things in some other language from the ground up, even redoing you're own idea and making it better, competing with the idiots who bought your MVP

exactly. the main criticism of c++ is how terrible the c++ code bases of the professional code monkey world are.
only a retard would make this criticism, because every real programmer knows that you can write shitty code in any language.
c++ is the most powerful and multifaceted language of all time (perhaps), is it that surprising that retards can use it to create a big mess?

well, people with shit taste exist

Teach me

Rust also has horrible syntax that makes me want to hurt myself. Did I forget to mention the compile times from having to compile everything for one change? Really who thought using a two-stroke key was a good idea to identify macros. Fuck.

>c++ is the most powerful and multifaceted language of all time (perhaps), is it that surprising that retards can use it to create a big mess?

Common Lisp is more powerful and expressive.
C++ has better performance tho

no, its not a problem at all that it allows 'the old shit' (no idea what you are referring to... hopefully you arent making the idiotic suggestion that it would be preferable to get rid of pointers from c++...)

i think rust is cool dont get me wrong, and i think its better than c++ in certain ways, but personally c++ is better in my view because it gives you (or can give you) everything rust has, but it also doesn't force it on you when you dont need it.

>Did I forget to mention the compile times from having to compile everything for one change

nice 2017 post. Rust has gotten incremental compilation already

functionalcs.github.io/curriculum/

i think rust's syntax is pretty awesome, what dont you like about it ? i love match statements, how flexibly you can use expressions and shit like that, its great

lisp owns but the 'lisp is the most powerful' meme is a meme

>matching
In every other functional lang.
The problem with Rust is .unwrap() to infinity

It's good for microservices, targeting an FPGA, ect. It sucks for any levels of abstraction beyond that. You will contemplate the borrow checking until Jesus returns

It's not that much of a meme thanks to how powerful macros are and basically let you extend the language in any way you want. Performance is the only thing keeping me from doing more things Lisp.

Dead meme?
You gonna program ICBMS in fucking JS or some shit?
With crap like self driving cars proveably safe languages like Ada/SPARK of more important than ever.

Show us your cool Ada code, Ada-user.

why are you unwrapping all the time? i propagate the result type through everything because its an excellent error handling scheme, and because you dont want to make decisions about how to handle errors for the caller....

i maybe have like 1 or 2 calls to unwrap at the top of the call chain. very infrequently do i unwrap something if its in a situation where it is 100% safe to do so

>no one uses c because it has extreme memory safety semantics: they use it for the opposite reason.
Firstly, I don't believe a lot of people who use C actually need the unrestrictive memory semantics they insist on, and I don't think a lot of people in projects which use C++ are very well informed or eager about its RAII features. Programmer practice and mindset in C++ is pretty well known for lagging far behind the standards.

Second, and I'm only speaking from what I see on Jow Forums, but C gets pushed a lot here by people cargo culting its famous legacy and insisting it's still the preferred applications programing language. It's not at all retarded to criticize that and there is an abundance of people on this board who will vehemently tell you a hammer is a screw driver.

>c++ lets you be as meticulous (or not) as you want at compile time. its not at all a short coming of the language that they dont strip out features that are useful far more often than rust's totalizing borrow checking and lifetime semantics
Remember Rust was created to support development of a browser engine. What you posted isn't absolute and depends wholly on the nature of the software being worked on and a tradeoff between security and expressiveness. For a lot of networked applications the option for security is so obvious there isn't really even a choice to be made in that regard and fighting with a borrow checker is acceptable.

Lisp as a system development method is also totally awesome: stevelosh.com/blog/2018/08/a-road-to-common-lisp/#lisp-as-a-system
You can write your own strictly typed Lisp, a C clone, a Rust clone, anything you want. This is why nobody uses it except niche areas like GrammaTech Security, because every hacker rolls their own libraries

yes, but that performance drawback is a huge drawback. and also, lisp letting you extend the language like that in the is definitely a cool idea, and i think a programming language is barely worthy of consideration unless it has similarly powerful metaprogramming capabilities. but you can write a lisp parser and extend it in anyway you want in like 5 minutes in pretty much every language, not just lisp. so lisp isn't particularly powerful in my view. I use emacs so im definiltey not a lisp hater or anything... lisp owns

>You can write your own strictly typed Lisp
>common lisp
>strictly typed

Attached: .png (680x521, 94K)

You mean poor error handling scheme.
Immediately go forth to youtube and look up Effective ML then apply it to your Rust code youtube.com/watch?v=DM2hEBwEWPc

You know Typed Racket exists right?

Interpreting lisp in your favorite language would likely be slower than optimized compiled lisp code. The fact that Lisp sees data and code as one thing makes it incredibly easy to do whatever you want while in other languages that claim to have these make you jump through hoops like you're some circus ape.

Forget the 'performance' meme.
You can rip out GC and run OCaml/ML even Golang or Lisp at fucking lightspeed. Plenty of people do this. They're even tuning the GC to ridiculous NYSE levels running millions of ops per minute .. on a single threaded application. Yes, you can do this single thread. Rust is not the only fast 'safe' language, in fact it's perfectly acceptable to write C or C++ safely by restricting half the features of C and getting the same performance. Every single day in industry this goes on. Rust will have it's place for highly concurrent massive applications, like say a combinatorial auction for trucking routes, but writing everything in Rust is just stupid. You could tune F# to be just as fast for most things like FIX protocol.

Attached: aftergoogle.jpg (838x855, 80K)

The GC is unironically not the reason why Lisp is slow. Its compiler simpler doesn't produce as high of quality opcodes as GCC/Clang does.

i see people pushing it as a language to learn, or a first language, and i think c is a great first langauge to learn, and a great language to learn. i agree that it isn't a great applications programming language though, but that doesn't mean anything, since people use it to great effect on some of the biggest software projects in the world. personally i want to have the option to build more exacting semantics and make the compiler check for more issues for me if i am working on a large complex project. but you will be perfectly fine in c if you know what you are doing and managing the project properly.

> What you posted isn't absolute and depends wholly on the nature of the software being worked on and a tradeoff between security and expressiveness.
yeah but my entire point was, c++ doesn't force you to make that trade off. you can absolutely use c++'s type system, metaprogramming and modern features to build rust levels of static analysis for whatever potential bugs you want. it just doesnt FORCE you to.

> For a lot of networked applications the option for security is so obvious there isn't really even a choice to be made in that regard and fighting with a borrow checker is acceptable.
to be honest (and again im not trying to shit on rust, i actually do like it), i kind of doubt that it is all that much more secure. this is because static analysis is limited in the types of checks you can do and the static analyzers themselves are exploitable. furthermore, tons of rust libraries are just bindings to c or c++ libraries anyway. like i said i decided to start teaching myself cryptography and i have been writing intensive crypto code in rust for a few weeks now. guess what? no one has reimplemented openssl in rust, they are just bindings to the c library. do you think that is going to change any time soon?

ya i like it too, like i said i use emacs so im fucking with lisp all the time :)

I bet you love fucking lisp, sicko.

> lol its not good you meant to say its bad now watch an hour long video

Why use Rust when you can use Carp?
github.com/carp-lang/carp

>Automatic and deterministic memory management (no garbage collector or VM)
>Inferred static types for great speed and reliability
>Ownership tracking enables a functional programming style while still using mutation of cache-friendly data structures under the hood
>No hidden performance penalties – allocation and copying are explicit
>Straightforward integration with existing C code

because you're doing it wrong
i don't really care though, the more shitty error handling you write the more money I make to fix your junk

>yeah but my entire point was, c++ doesn't force you to make that trade off. you can absolutely use c++'s type system, metaprogramming and modern features to build rust levels of static analysis for whatever potential bugs you want. it just doesnt FORCE you to.
C++ is getting better but there isn't any combination of features or third-party tools yet that brings to parity with Rust when it comes to checking lifetimes. Being on Rust's level would require support from the type system.

>no one has reimplemented openssl in rust, they are just bindings to the c library. do you think that is going to change any time soon?
I doubt it, much like I doubt the incumbency of C has a lot of bearing on the merits of other languages.

nah im with you man, i love that about lisp as well. i guess i just mostly use it for hacking features into emacs and havent done much crazy shit with it.
there are other cool languages that do shit like interpret themselves at compile time, give you access to the AST of your own program and metaprograms, let you extend the grammar of the langauge in anyway you want, do whatever you want. haskell and D have crazy features like this (tho no one uses D and apparently its pretty shoddy in practice). boost (c++ library) also has a library which is a compile time parser generator, that lets you generate code from whatever language you want at compile time

whatever fag, either summarize your ideas or fuck off