Rust language appreciation thread

addresssanitizer and valgrind.

>even haskell

You run those in production?

>I need an entirely new language to understand the promises only resolve once
woah..........................so this is............... woah................. the power of............... RuST????

no, you fucking idiot. you would find where the code is segfaulting by inspecting coredumps and then you would reproduce the issue with addresssanitizer and valgrind.

Does your core dump come with a plane that's still in the air?

That tweet is unironically liked by trannies and faggots exclusively. Thus the language has no future

>Rust has even surpassed Haskell now

whoa, it has more than 10 users?

Attached: 066308FC-D636-45FB-B730-A7D456CBF5B6.gif (320x240, 2.65M)

I'm pretty confident in assuming that anything Jow Forums hates has a great future ahead.

Compile speed is why you choose C over C++, not why you would choose C over other languages. Other languages have fast compile speeds (sometimes even faster than C), and I personally wouldn't mind slow compile speeds if I also had some reasonable assurance that my program wouldn't spontaneously combust if I looked at it funny.

the c programming language

Attached: the_c_programming_language.jpg (664x3432, 422K)

>still no AI to interpret and compile plain english prose into working software

fuck coders, nerds, mathy-wathy wigwogs, and fucken progaymmers

>Compile speed is why you choose D over C++
FTFY.

1. I like linear types.
2. I don't like Rust's community. SJWs are like vampires. Starting an open source project in Rust is like inviting a vampire to your home.
3. Therefore, I'll wait for another moderately popular language with linear types.

C is chosen for literally nothing in the current year.

C is chosen correctly when your codebase needs to run on CentOS 4, AIX, your garage door and the PlayStation Vita. It is (sadly) still the most portable language. It not the right choice for your Linux/OS X/FreeBSD command line utility.

Java is probably even more portable. Java even run on Smart Cards.

>dead distro, dead unix, dead console
So nothing from the current year?

Java is perhaps more portable, but it isn't as widely ported. You aren't getting a Java compiler with your stupid embedded device. The language itself has a host a problems. Its good native compilers aren't FOSS.

That was a synecdoche. Read it as "a wide range of platforms, some of them outdated and obscure".

>only C runs on CentOS

Attached: 1519264861280.png (645x729, 62K)

That's not a wide range of platforms, that's just a bunch of dead an niche platforms where other languages are just as suitable.

Yes, D would likely fit into one of those mentioned alternative faster compiling languages. His post was bragging how fast C compiled, though, so substituting C for D in my reply would have resulted in a complete non-sequitur.

I explained what I meant. I accept that my metaphor could have been better.

Dead and niche platforms are still platforms. ANSI C is the maximally portable language that runs on the widest range of platforms. If you software doesn't need to run on the widest possible range of platforms, you don't need it, but if you do, you do, and there's no other option.

You can compile another, safer, better language to ANSI C.

The code you write for those niche platforms are not the same as other platforms, writing C will not magically abstract over the hardware restrictions. Be real.

Which is what Julia is, and why you should use Julia over Tetanus.

Sure. So what do you suggest?

>C is portable

Attached: 1548876559645.png (645x729, 70K)

I thought Julia used the LLVM and didn't generate C code,

>writing C will not magically abstract over the hardware restrictions
lmao as opposed to what, reimplementing everything in raw assembly for each platform?
because this was how it worked decades ago and there are no fond memories of it

C is less portable than many other languages. It doesn't abstract the underlying platform as well as they do. C is more portable than any other language. It has compilers for the most platforms.

You seem to fail to understand "writing C will not magically abstract over the hardware restrictions"
Instead you are asking brainlet questions like "hurr durr xDD wut lang"
If you are so much interested, C++ is perfect for those but that's not the point I made. I digress.

You are responding to two different posters thinking they are one.

>reimplementing everything in raw assembly for each platform?
Because compilers build themselves when you publish the isa, this is a known fact...
At no point you have to write a compiler for your arch, it's automatic, right?

maybe it's about time for shitheads to realize some things exist because other people on this planet are actually doing the dirty work so you can sit your sorry ass at your desk and profiting.
Yes some people are still writing asm code for a living
yes some people write compilers to simplify the work of others
yes some people spend lots of time debugging cryptic hexa code to find hw bug
they HAVE TO exist overwise nothing else can exist.

This is also true for non-CS things too.

Do you feel underappreciated, compiler-porting user?

Possibly true in theory, but I don't think one exists in practice. You can probably easily find a language that supports a large majority of C compilers and platforms, but I don't think one exists that supports every single ANSI C compiler ever created.

No, of course it won't. So you write the majority of your app in C and for the implementations on the other side of the HAL you either write system-specific asm and link it in, use whatever the native language is and FFI between it and C or....you write system specific C.

>You can probably easily find a language that supports a large majority of C compilers and platforms, but I don't think one exists that supports every single ANSI C compiler ever created.
Fair point. Of course, a large majority of C compilers and platforms is usually good enough.

>Do you feel underappreciated, compiler-porting user?
I did for some time
I worked on a realtime jvm scheduler for java 6 and people wanted things that did not exist in real life at this time, it was for a fucking toy I don't remember the name, worst job of my life.

not when your user base is extremely overrepresented in suicide statistics

Attached: 1476046374944.png (488x381, 304K)

Libertarianism? Pit bulls? Anime?

>C++ is perfect for those
Explain why. Assume the program in question is not a video game.

Attached: SPRC%20Charts_09[1].png (1200x927, 455K)

This.

wow it's almost like whites have been constantly demonized and at the same time expected to provide all the resources for the welfare system that goes to the negros and latinos, nice white supremacist society you've got there buddy, we must sure tear this shit down to free the minorities suffering right?

sad that artificial intelligences have such a high suicide rate

Attached: 8f2aee8333a3a6dcb275c64bbf68c7c0c5f9c841f0ef55c7131ce3be1d46e10d.png (1307x848, 101K)

All I ever see is garbage political bullshit people like in the op link, is there even one normal person that's involved with rust?

>using rust in 2019
lol

pic related

Attached: nim.jpg (720x903, 137K)

>more economically and socially successful than other races
the goyim doesn't know

Attached: 1492950995516.jpg (1600x1024, 197K)

Learning it now

Fuck the community, but the language is unironically pretty comfy, I like it

All languages are the same
Only the communities differ

Nim is a decent core idea of a language saddled with a bunch of crufty weird crap in the compiler and the standard library and shackled to a development team that (from an outsiders perspective) seems lost in the woods and a bug list that only seems to grow. I enjoy using it when I find the occasion to, and the developers themselves are nice enough people, but it's not a language I would trust until 1.0, and the developers really need to do a better job articulating where the language is going in a form that's not a 20 minute long youtube video.

>Look at how nice rust is
>I coded things so poorly I had to go redo them properly after looking at what was supposed to be done.

Is it still buggy? Crystal will probably reach 1.0 first. They're fairly similar, but Crystal doesn't compile to C.

>crufty weird crap in the compiler and the standard library
care to name examples? The only thing people seem to point out is style-agnostic identifiers. If that's all you've got, then I'd write it off as a massive success.

there are features under development that are still a unstable, but it's only very niche/new features. The core language and most of the intermediate-to-advanced aspects of it have been rock solid for the better part of a year.

I like crystal a lot, but i havent used it for a few years because im a rust fag

Does Rust have a statically typed Rails clone? It's Crystal's major selling point. It has two, though the way these things usually go probably only one will survive. Crystal won't compete with Rust, and it isn't trying to, but I hope it reaches stability and bites off a piece of Go's, Java/C#'s and RoR's market.

based and kek pilled

_ ____ __ ____ ____ ____!

b-but i'm a vampire...

You don't understand rust. Only an idiot would ever unwrap something they haven't already checked. Even if you do you can debug it in one second because it literally tells you where the error is.

I've put jammers in the kitchen

Not him, but c++ is a superset of C, with a lot of goodies.
If you stop at c++11, c++ is a great language.
After that it became a mess.
If you think that c++ is bad due to oop, then you have to go back and read oop, again

You clearly haven't looked at the source of any popular crates or projects. They're packed with unwrap/expect/other functions that can panic. That sort of shit isn't suitable for production.

Just looked up two popular crates (rand, lazy-static), they only have unwraps() in comments for documentation. So what crates are you referring to?

Look at the issues raised for the image crate. There are countless reported panics in completely normal circumstances. C code simply DOES NOT DO THIS.

What do you mean? Panic is just a bug in your code, when something unexpected happens, not necessarily related to unwrap(). Sometimes you manually write sections where you want your program to panic, with a nice panic message you know exactly where to debug your code. And there's only 47 reported panics in the image crate.

Some C projects has panics as a safety measure, like the Linux kernel for example.

Are frogs nazis?

C++14 is just a couple of fixes and quality of life improvements on C++11 (make_unique, etc.). How did that make it become a mess?

C++17 adds static-if, which is a fucking game changer for compile-time metaprogramming.

err, constexpr-if

Funny, static-if was actually proposed a couple of years ago by a D developer, but it got rejected.

constexpr if is good for qol but it doesn't actually add new possibilities. Just like concepts.

b-but what if I want a qt vampire loli gf?

Rust ain't gonna give you that

Attached: 342b670bae93a950c73050e958dcf33e.jpg (1100x1530, 1.36M)

Nigga go use scratch or smth

rust is cool but you can already do deterministic resource management in haskell. ResourceT lets you allocate resources dynamically, and bracket (or another combinator that uses it, usually called something like withBinaryFile) lets you allocate them statically. linear types for correctness are mostly a meme

>Does your core dump come with a plane that's still in the air?

The only way to ensure that is to test your code. Whether it's written in Rust, PHP or REBOL is irrelevant in that case.

In Rust you'd get a run-time exception instead of a CPU trap and your plane would crash the same.

The problem is that C++ (and java, c#, etc.) OOP is not good. Smalltalk OOP is good, and CL OOP is good, but not C++. However, C++'s OOP being optional makes it palatable, unlike java or c#.

The point is that rust does not have memory-related bugs which are known to be somewhere around 70% of all bugs. In particular, there are no segfaults in rust.

So what happens if your Rust flight control software tries to make an out of bounds access into an array while the plane is over the Atlantic?

If you give the right answer to that question, you understand why you can write perfectly safe flight control software in C or assembly.

That's because haskell uses gc (a bad one at that, that may leak memory by misidentifying data, primarily when handling numerical arrays - the curse of conservative gc's). gc is significantly more convenient for the user but it's borderline impossible to make a gc with suitable properties for realtime systems (even soft-realtime). Go, some CL implementations, ocaml, .net languages and jvm languages are the only languages with sufficiently good gc's for that, and you still need to program very carefully to make them work.
Rust doesn't have any automatic gc, so all pauses are deterministic and predictable, making it suitable for even hard realtime and embedded applications.

The biggest boondoggle that I can think of off the top of my head is the Javascript target. The language should have stuck to targeting C and C++, but now there is a completely different language target that needs to be maintained where none of the existing C/C++ interop stuff is useful at all, or has a different meaning. If your program is doing any C FFI at all (And why wouldn't you be, it's one of Nim's strongest features) it's a completely useless feature.
But the language is full of weird boondoggles and old features that were never properly removed, new features that don't have the ramifications thought through and parts of the stdlib that, while pretty, have to actually work properly and be maintained in the future (and possibly rewritten for the new GC-less version of Nim that might come on down the line). I see a lot of churn, but a buglist that outpaces the churn, and not enough clear direction in the language.

>So what happens if your Rust flight control software tries to make an out of bounds access into an array while the plane is over the Atlantic?
The compiler rejects the program, so the program never gets to run in the first place.
C and ASM don't have bounded arrays. While some compilers can insert bound-checks, that still only deals with one of very many ways to perform operations on out-of-bound memory, it's far from sufficient. It is also usually not possible to do static analysis for bounds checking, which is why the compilers insert them in the program instead of actually doing like rust.
Sad that you don't know even that much.

>The compiler rejects the program, so the program never gets to run in the first place.
Kek.

Try to run this code after you compile it, brainlet, and see what happens. Now imagine you're in the plane.
let niggers: [i32; 4] = [1, 2, 3, 4];

let faggot_nigger = niggers[num::integer::sqrt(88)];

There's a reason why absolutely no one in the safety-critical software industry even gave a glance to Rust.

>Be airliner pilot
>Be flying over the ocean
>See all lights go to red
>See error on the console
>"Hey senpai this is your friendly Rust program here. Sorry I couldn't compute the altitude because there was an out-of-bounds access attempt, because the main developer was having a sex change instead of testing xir code. Rest assured, as you plunge to your imminent death, that the Rust run-time was able to log which exact line caused it, unlike those unsafe C programs that would have simply caused a segfault. The panic message and the backtrace have been added to the black box record. RIP."

There is no reason to care about the lack of safety in Rust if you can do it in C. I just want a modern language with native performance.

Do you still not realize everything they don't want people to do is paired by propaganda with LGBTSJW communities? They don't want you to go vegan because cholesterol clog brain arteries and reduce cerebral blood flow. They don't want you to eat onions because it's a cheap healthy alternative to meat, phytoestrogens compete with the body hormones for binding to estrogen receptors thus actually making more manly. Then they don't want you to support open source projects. SJW aren't inherently evil, but weaponized with malicious intents.

You are wrong

>There's a reason why absolutely no one in the safety-critical software industry even gave a glance to Rust.

What reason? You example does not illustrate it. C/C++ will fuck things up silently in this case. Unless you get lucky and undefined behavior will be merciful to,.