Any Rustaceans here? Does Rust have a future? How does it compare with C/C++?

Any Rustaceans here? Does Rust have a future? How does it compare with C/C++?

Other urls found in this thread:

github.com/alexcrichton/futures-rs
twitter.com/SFWRedditImages

Please refer to Rust users as "rustfags", this is not reddit.

Rustaceans? More like homos
Rust is the only language with people literally begging you to use it

Yes, I am. My pronouns are they them theirs btw.

Lol what future

Rust has a great future ahead of it, in ~2020 it will probably become usable. Currently, Rust is not usable in any form except nightly which is not stable or production ready. Rust 1.0 is exactly as usable as rust 0.1 but they do have people working full time.

It is very similar to C++ in design goals but C++ will never ever die because legacy shit won't die. On the plus side if you study Rust-nightly you won't have to fall back to maintaining ancient C++/C89 tier garbage to get a job.

Yes, rustpacker reporting for my gay duty!

Rust is a pretty cool guy, but would of been even cooler if they'd not been so singularly obsessed with being the new kewl systems programming language and also threw in more syntactic sugar and maintainability support so it could also be a great language for writing desktop applications.

Can you write your own Rust compiler you stupid NIGGER!?

As long as they don't support Qt officially or at least an own decent GUI API, no.

"owning" a GUI APi isn't necessary, they've got bindings to literally everything already.

They have
>incomplete, undocumented Qt bindings
>incomplete, undocumented Wx bindings
these would be the only widget sets that matter

>a lot of bindings to stuff nobody wants to create actual applications with like gameshit like Conrod or TK or GTK (the last one without documentation, but for GTK that goes without saying)

Tk is perfectly valid, at least on par with Wx. I can't speak for Qt/docs though, I would imagine they require experimental features to implement anyway. Everything does in Rust.

Pretty much this. The main thing is that they have libraries and crates that really should be 1.0 but aren't and especially the crates has trouble getting to a 1.0 state.

There's also the fact that it can't compete really with C because it's missing low level features like allocation alignment and a way to use unions other than hacking a struct together. libcore is still behind freestanding C because of the above and the rough edges.

It will get there eventually but I don't have any hope it will be in 1-2 years. More like 4-5.

This desu
No other language has such a whiny p-please use me senpai culture surrounding it, it's fucking pathetic.

>Tk is perfectly valid, at least on par with Wx.
[laughting_everything.gif]

Superlanguage by 2020

>Any Rustaceans here?
Yes.
>Does Rust have a future?
Yes: github.com/alexcrichton/futures-rs
>How does it compare with C/C++?
It's better.

WAIT A MINUTE
Rust:"we will be a superlanguage by 2020"
India:"we will be a superpower by 2020"

Could it be that the pajeets are behind rust?

No, thats Go.

I love Rust!

I guess you'll be able to make GUIs using HTML with the component that Servo uses. Like browser.html except you won't necessarily make a browser.

I like Rust, someday I want to use it.

We've seen how well that works in Electron. And while JS is a piece of shit, the real problem here is HTML + CSS, aka making GUI elements out of limited, quirky and cache-unfriendly DOM nodes.

Just use canvas then

rust syntax FUCKING SUCKS

I don't use rust but I enjoy brainlets being triggered by it here.

This also is abstracted with a shitty API. Plus, you lose scaling and assistive technology.

From the relatively little I looked into it, it seemed like it tried to be C, but with unnecessary restrictions to make you not shoot yourself in the foot. So I'd rather just stay with C.

quads of quality checked

>doesnt use rust
>calls others brainlets
l m a o

These. Unlike just about every other language right now, rust really has its shit together when it comes to creating a usable language that actually fixes the many of the most common programming issues today.

Even though I really do like rust, theres no denying that its syntax is fucking atrocious.

DLANG MASTER RACE

I thought this at first too, but its a lot more like a well desighned c++ with a more functional style.

That doesn't really explain why the borrow checker is forced upon you.

It would be one thing if Rust had a different fundamental mode of variable/value management that had intrinsic limitations, but the way they've done it is just plain old but "you can't do this and that because it's (((dangerous)))". It's just not necessary. That's what you called forced dogma.

>enforcing safe code
>not necessary
really makes you think

it's intrinsicly different under the hood, it has similar abstractions to C++ smart pointers plus a lot of compile time stuff.

It's not the least possible restrictions to make a language safe. It also prevents you from doing things that are safe, but that the compiler doesn't realize are.

Not really, the only difference is that move semantics are the default for assignments, but that's not really anything "different".

its not... new specifically, but there are known fail conditions that are allowed in other languages for no good reason. Borrow checker is one set of rules thats simply best practices designed into the language. Lifetimes are another big thing since general scopes have some more inevitable fail conditions designed out.

These are things that ideally you would be doing manually in some form in other languages too but doing runtime checks can improve that performance-wise as well as enforcing those practices.

*compiletime checks

>Borrow checker is one set of rules thats simply best practices designed into the language.
"Best practices" are always a matter of taste and style, though. As I said in , there are many things you could do that would be safe, and it's just that the compiler cannot be made to realize that. There's no reason for those restrictions other than "you can't be trusted with this power".

>sjw shit
nope

The language is designed for parallelization where everyone else has to implement locks and mutexes and stuff instead. It's not 'more' it's just different. There are GUARANTEED race conditions if you don't implement something there and doing it at compiletime is nice.

Same goes with lifetimes for references. You are GUARANTEED to have bugs if you don't implement SOMETHING in its place. Doing it all at compiletime is a benefit.

>The language is designed for parallelization where everyone else has to implement locks and mutexes and stuff instead.
The thing is, there is exactly nothing that prevents you from doing whatever you do in Rust in C. There is, however, forced dogma in Rust that prevents you from doing things you can do in C in Rust.

That's called 'unsafe' and it is completely viable Rust code, it's just segregated. I don't know if segregating it helps but you can roughly prove safety in non-unsafe regions of code so at very least it's a help in debugging.

Indeed, so the language doesn't even guarantee the result to be safe, unlike eg. Java. Since you have to use unsafe blocks to actually implement real-world programs, you have the exact same problems anyway, and you're just forced to live with the forced dogma in the meantime.

Also,
>There are GUARANTEED race conditions if you don't implement something
Yes, you have to be principled and systematic in writing real-world programs, but in C you can choose your own principles and systems, whereas C forces a specific world-view and ideology on you.

>whereas Rust forces

The problem is that humans make mistakes, as seen by the infinite number of fatal errors that commonly exsist in c and c++ code. The borrow checker is needed because modern technolgy and infrstucture needs code that is has a 100% saftey garentee stamped on it, without sacrificing any run time.

It's shit, now stop shilling your stupid language.

>The borrow checker is needed
Except it isn't. Again: It prevents things that aren't unsafe. Therefore, it is not "necessary".

>a 100% saftey garentee stamped on it
Except that's wrong too, see again: You effectively have to use unsafe code in practice, nulling your "100% guarantee". If you actually want a "100% guarantee", use an actual high-level language instead, like Java, Lisp or Haskell.

>rust gets constantly shilled
>ada is always ignored by most programmers because they hate having to not write shit code

The language guarantees safe parts to be safe. I can't guarantee any C code to be safe and I'm inevitably going to be using someone else's library someday down the line. It's not an individual user's benefit (except in debugging) but the ecosystem's benefit for the unsafe ghettos.

There's also no guarantee other people's principles and systems will work right either with C or other languages. It's enforced and kind of masochistic but if you're working in a large project it's a nice assumption that things will be trustworthy generally. You don't have to worry that some bullshit dangling pointer will show up 20 years down the road in legacy code. Unless it's unsafe, which has a big ol' warning sign right on it.

I'm not even going to shill Rust either, it's completely unusable now because it's so fucking premature. It's still like 15 years ahead of C in that it has a stable standard now, even if thats like 3-4 years too soon for a 1.0 release we've got. As a language it has a lot of potential especially in areas where every new language design is aiming, not shooting yourself in the foot when someone inevitably hires some poos/community members to do work.

>The language guarantees safe parts to be safe.
See :
>You effectively have to use unsafe code in practice, nulling your "100% guarantee". If you actually want a "100% guarantee", use an actual high-level language instead, like Java, Lisp or Haskell.

I like how I have to cast things to a float before I can perform basic math functions like floor. Really neat language.

>The language is designed for parallelization where everyone else has to implement locks and mutexes and stuff instead. It's not 'more' it's just different. There are GUARANTEED race conditions if you don't implement something there and doing it at compiletime is nice.

What a load of BS. When you do parallel stuff in Rust you place it in the types with runtime checks that work with locks and mutexes. The frigging borrow checker can only move variables into threads.

As a non-rustfag, what does this mean? Are you expecting to do floor on ints?

See paragraph 2

The borrow checker prevents known race conditions, it's what they can't do not what they actually do. It's just a reorganizing of known solutions to the problem in the memory management instead of your code. With the abstractions things like some tracked number of read-only borrowed (not just immutable) references to a binding aren't even common in other languages. It's got some new features that haven't caught on yet.

Every other language requires this too, pajeet.

>See paragraph 2
The exact same thing applies, though. Any unsafe block can leave a dangling pointer somewhere 20 years down the road, and any real program is bound to have enough unsafe blocks that you won't know where to start looking anyway.

As I said, if you want 100% safety, there are many languages that actually can provide that. Rust is just the worst of both worlds: The masochism of a high-level language with forced dogma, and the unsafeness of being allowed to do anything when you want to.

you can also implement a floor capability for your class if you want, beats raw templates

what else do you need to floor? integers? strings?

Theres a reason its called unsafe. that basically means you should never use it unless you want bugs

>It prevents things that aren't unsafe. Therefore, it is not "necessary”.
Name one

>you effectively have to use unsafe side in practice
This is simply not true. It is not at all difficult to entierly avoid unsafe code

>because they hate having to not write shit code
sure
>ada exists what long now?
>still shit tier support for most "normal" libraries
>Adacore recently starting to pretend they care about their non-military userbase

It really makes you think

Thats it's niche, it's like C++ covering the whole metal-to-highest-level scale with varying pieces of the language. Most people probly won't ever write unsafe code in Rust, that's perfectly fine.

It's a "systems software language" which means that unsafe thing has to be there, same as inline assembly or whatever you want in C/etc. Doesn't mean it necessarily covers your problem domain. It's generic/multipurpose enough to go either way because it has to, like C++ but you never HAVE to use every feature.

nothing can compare to c++, are you fucking retarded

>it's like C++ covering the whole metal-to-highest-level scale
Except C/C++ allows you to choose your own principles, where Rust forces a specific set of principles on you.

>Except C/C++ allows you to choose your own unsafe principles
ftfy

>This is simply not true. It is not at all difficult to entierly avoid unsafe code
Perhaps, but the main point is that it's a stupid compromise in that if you want 100% safety, there are other languages that do that better, whereas if you want the freedom to do unsafe things, there are other languages that do that better.

It allows you to choose unsafe principles, sure. It also allows you to choose your own safe principles. Unlike Rust.

theres nothing wrong with forced principles if it garentees good code.

Yes, by design. It doesn't force all principles on you, just those that make the design of the language work. If you don't want to use it, that's perfectly cool too. I think explicit lifetime use is pretty rare too, could most likely be avoided. Borrow checker is pretty core but if you felt like copying instead of EVER borrowing I bet you could manage it. It's even remotely possible that Rust isn't ideal for some types of problems! There's plenty of other options for those too. I'm not one of those rust-all-the-things fags, or the same only with shitty poo-in-loo Go. Just.... use it when it's appropriate or don't. It has a unique purpose in the field of programming languages and maybe that is convenient in some cases for some people. I think it's preferrable to the clusterfuck of random people's C/C++ in most cases but maybe it isn't.

So use Java instead. It has already been around for 20+ years. No need for a new language.

>just those that make the design of the language work
The problem with that statement is that it also chooses principles that aren't necessary to make the language work, and are only -- only -- there because it doesn't trust the programmer.

The design implemented such that you're not forced to rely on trust. That's kind of interesting and unique and probably helpful again in those large clusterfuck environments/projects. Similarly to Go's halfassed design it seems aimed towards contract/slave poo in loo shops working for massive corporations and ultra long term dont-be-fucking-clever-or-your-replacement-wont-figure-it-out system software destined to become legacy.

Boy, you're all talk no action. The borrow checker doesn't do shit to help you write parallel programs, end of story.

>The design implemented such that you're not forced to rely on trust. That's kind of interesting and unique
No? That has been true for every actual high-level language ever, including but not limited to Java, Lisp, Haskell, Prolog, Python, and anything else under the sun. Those language don't trust the programmer either, but arguably does so better, because they don't have restrictions that are unnecessary under their own semantics.

It universally prevents conditions where a race condition can occur, even if you're not doing parallel work. You can't read AND write to a thing, except with complete guaranteed exclusivity. That's it. It's mutexes inside smart pointers. That's what it does.

Rust is not solely a high level language. It has high level features and low level features with varying levels of trust attached. Again you're not aiming to use every feature in every project by necessity, it's one big ecosystem with both types of code in it in their appropriate places.

Those high-level languages also have FFI for when you absolutely need to break abstraction. They just do the high-level parts better because they don't try to mix it unnecessarily.

I'll write a C compiler that only allows calls to pthread_create if they're directly followed by pthread_join, that also allows race-condition free """mutlithreading"""

I think there is a fundamental disagreement here where one group believes that speed and saftey are the most impotent things in programming even at the expense making programming harder by restricting programming practices, while the other group thinks that programming is somthing that should never restrict the programmer even if it means you can only have speed at the expense of saftey or vise versa. I think rust has a place in this world for those with the first belief, but its not for eveyone, and we’re all entitled to our own opinions.

Rust's also aiming at performance greater than a lot of those high level languages and iirc might have java beat. I'm pretty sure their optimizations are complete shit on a lot of things though so probably not competitive everywhere, also unusable because lots of those 'unsafe' requiring language features are only available in nightly. So there's benefits available to the rust masochists even IF they only use high level features. A lot of the optimizations come from designing the checks into the compiler and not dealing with them at runtime. Not impossible in other languages though.

Then do it, if you can herd the community into moving towards safe practices without going full on revolution and forcing them into one specific way of doing things then good for you.

It really makes me think you are one of those guys who writes shit code

The JVM has a runtime profile at hand, it knows tons more than your lousy borrow checker.

JVM is also significantly slower than Rust is right this second. Shitty version 0.1-totally1.0 Rust that exists today. Also a larger surface for bugs/vulnerabilities in the entire JVM being orders of magnitude more complex. Not exactly a systems-software tier, not bad though by any measure.

fpbp

Wouldn't Rust's focus on safety mean that code written in Rust is less likely to have exploits?

>Rust's also aiming at performance greater than a lot of those high level languages
If there's anything I'll give Rust, it is that it's slightly cool that they have system of memory safety that doesn't require a GC.
Putting arbitrary restrictions on me to prevent me from shooting myself in the foot is hardly something that makes me excited about a language, however, and my emphasis is squarely that the "arbitrary" part, because again, all that the language really does is enforce a specific programming ideology.

A memory-safe-ish memory abstraction isn't unique to rust though, it's been like the coolest shit in C++ since 11. Rust's just a bit more noob friendly, which again is sometimes/usually good because people are shit. Especially when they have shitting streets.

It's also VITAL to maintain safety in projects that want Rust features. Like Firefox because they're 100% exposed. Or the high performance network servers and things where other older projects have had major public failures very recently.

As others have mentioned, the safety is pretty much illusory once you actually need it anywhere of relevance.

>It really makes me think you are one of those guys who writes shit code
Pajeets like you should really be forced to write Rust code 8 hours. However, even with SPARK there isn't much reason to not just go with C++ and some statical checker/restriction tool instead.

More illusory is any power-feature that isn't in a nightly branch. Hell even one of the STD things had a pretty big bug a while back, the standard library should be basically guaranteed safe (written in unsafe code) but it was fixed in a timely manner. I don't know what more you can ask for such a fledgling language/ecosystem.

The unsafety though is literally the red flag in your code that balances out the green flags in 99% of the rest of it. It's an interesting experiment in community safety trends if nothing else.

>However, even with SPARK there isn't much reason to not just go with C++ and some statical checker/restriction tool instead.
>believes this
>calls anyone else a pajeet

prove me wrong, poojeet/adacore shill.
pro-tip: you can't because it's the truth

designated

Alternatively, Rustniggers is also acceptable

Rustniggers is more fitting with the demographics.

Give me your gender.

And your OTHER gender