/frt/ - Friendly Rust Thread

>>55768235
How does Rust compare to Ada for code safety?

File: 1434500854742.jpg (48KB, 600x484px) Image search: [Google]

48KB, 600x484px

cee
e
e
plus
l
u
S

Is Rust really as good as it seems? Putting sjw things aside of course

>>55768402
I'm not familiar at all with Ada. Here's the best thing I could find: https://www.reddit.com/r/rust/comments/48vh1m/rust_vs_ada/
Keep in mind that Rust is very new and constantly-changing, and therefore discussions on it that are several years old may not be accurate at all anymore

>>55768486
I suppose that depends on how good it seems to you. It's definitely a step up from C as far as memory safety is concerned.

>>55768402
Look at it this way: Only one of these languages has been used to write firmware that goes inside a nuclear missile.

>>55768658
And one of them has been around since 1980

>>55768235
OP is a faggot

>>55768658
As far as you know. If they wrote nuclear weapons GNC code in Rust today you wouldn't know about it unless you had clearance(and if you had it, you couldn't say)
>>55768532
Well, I was asking because I'm a machine learning/numerical computation scientist and I've seen that some people have started some stuff on this in Rust, so I kinda want to contribute but I don't want to contribute to something that'll end up being a waste of time.

>>55768235
>muh safety
Rust's "safety" makes it harder to make mistakes in laughably simple code, and does not help with code that has any complexity.

>>55768810
This. Any Rust program over 100 lines or so will use the equivalent of shared_ptr, so all the borrow checking happens at runtime instead of compile time. And any program that needs to be very fast will use a lot of unsafe operations. Rust is only "safer" than C++ in rare edge cases.

>>55768810
>>55768878
You're both idiots that don't understand how the borrow/lifetime system works.

>>55768235
>muh speed
rustc is slow

>statically links everything
>except libc, so your executables aren't really self-contained
what a joke rust it

I probably won't use Rust for anything but I appreciate that it's actually trying to advance programming towards something more than "lol it probably works, ship it".

>>55769279
This comment doesn't seem inaccurate

>>55769338
...by default. Most systems don't have Rust installed, but do have libc, therefore statically linking rust libraries and dynamically linking libc is the best choice. But you can statically link everything if you want. See this for more information: https://doc.rust-lang.org/book/advanced-linking.html

You guys may want to check out my disassembler. It's 24k lines of Rust with a frontend written in QML.

https://panopticon.re/
https:/github.com/das-labor/panopticon

>>55770787
That's pretty awesome. Why'd you choose Rust over other languages?

I soooo want to get into Rust. But it feels like even basic stuff for day to day usage will be difficult. Parsing XML, GETting webpages, loading/saving images, maybe a GUI...

File: 2 knife 1 sword sword.jpg (101KB, 500x667px) Image search: [Google]

101KB, 500x667px

>>55768453
>C+
nice try

polite sage for off-topic

>>55771098
GETting a webpage is really simple using Hyper. There's also a libcurl binding, if you'd prefer that.

Loading/saving images is pretty straightforward too (as Vec<u8>s specifically).

I've never worked with XML parsers but there's apparently a few to choose from. As for GUIs, I think those are pretty much always painful. There are GTK bindings though, and I think QT bindings as well.

So what seems difficult, exactly?

>>55768235
>muh ids cleaner
Six fucking string types: str, String, CStr, CString, OsStr, and OsString

>sepples syntax
Huge mistake. I like the language design, but I refuse to ever use it because of the pants-on-head-retarded syntax.

>>55771086
It's the better C++. I've been programming C++ for ~10 years now and Rust delivers what I missed: sum types, safe concurrency, memory safety w/o GC and an end to all the cruft from C. A previous version was in C++ and when Rust reached 1.0 I switched immediately.

>>55768486
It can get verbose (x.unwrap or try!(x) everywhere, if try!(x), error type description in function signature, often try! doesn't work because you need error type conversion so you end up using error type adapters, etc.), but other than that, it's really fast, safe as can be without bordering esoterica, is light as fuck and can be made even lighter (libcore), and has a great standard library with libstd. It honestly feels like "what C++ should have been". The functional/ML-style features are also awesome.

>>55768750
Leaf is looking really good, although development seems slow. As soon as it does automatic diff (auto or symbolic - by the way, symbolic is much faster, auto advocates are 99% of the time simply ignorant about what they're saying), I'm switching all my experiments to it.

>>55771616
why do you lie?
rustc is slow
hello world programs can take MBs
rust is bloated as fuck

>>55771676
>shills are this desperate to FUD against rust
My sides!

>>55771207
>GETting a webpage is really simple using Hyper. There's also a libcurl binding, if you'd prefer that.

OK didn't know abou that, pretty useful.

>Loading/saving images is pretty straightforward too (as Vec<u8>s specifically).

I meant something that can encode/decide at least jpgs/pngs for me.

>I've never worked with XML parsers but there's apparently a few to choose from. As for GUIs, I think those are pretty much always painful. There are GTK bindings though, and I think QT bindings as well.

I've found third-party bindings for a lot of stuff. But these personal projects can be unreliable or outdated, can't they? There is some reluctance... Is there a resource for rust libraries (like Boost-C++ but not necessarily all in a single project)?

It's not that there's something bad with the language, I like it a lot. But I hit some walls as I try to come up with something interesting to make.

>>55771098
There are bindings for most usual tasks as well as some pretty good native libraries. I think you can do GETting and XML parsing with native libraries, but you might need bindings for GUI and images.

>>55771710
>Is there a resource for rust libraries
crates.io and github are the best places to find rust libraries. Crates.io is what cargo gets crate information from when you add deps in your cargo.toml.

>>55771696
Yeah, it's pretty sad.
>executables are larger when you statically link stdlib!
Who would've guessed?
As if the ~6 megabytes is even a big deal when you can get a terabyte HDD for 50 USD.

>>55771710
What >>55771760 said.
For encoding/decoding images you probably want this crate: https://crates.io/crates/image

>>55771696
nice argument SJW faggot

>>55771841
>~6 megabytes for a fucking hello world
>le not bloated
This is why rust is a meme

>>55771841
Everything static with no optimization isn't even 1mb, -C prefer-dynamic -O is 8.1kb. With the same option, the C is 6.6kb.

>>55771890
Alright, install Rust on whatever system you'll be using the program on, and then dynamically link when you compile it. Problem solved.

>>55771734
>>55771760
>>55771841

Thanks.

>>55771911
Additionally, compiling hello world in C using -static with GCC (i.e. the same setting as the default rust program) yields a 794kb exe (773kb for the compiled rust). In that setting, rust literally produces thinner executables.

>>55771944
You're welcome!

Here's an example of reading a file: http://rustbyexample.com/std_misc/file/open.html
Note that this example is reading to a String. For an image you'd need a Vec (created with the Vec::new() function) and you'd have to read into it using read_to_end rather than read_to_string

>>55771867
>dynamic linking is harmful says rob pike and john carmack
>but "muh bloat" says NEET faggot on /g/

>>55771914
oh sure, except it statically links everything

>>55772592
i actually like static compiling. the problem is rust is bloated shit and static compiling just make it worse
>muh rust says NEET faggot on /g/

>>55772647
>>55772674
t. lone paid shill

>>55772647
https://doc.rust-lang.org/book/advanced-linking.html

>>55772790
and just how's paying me?
Since rust is by SJW I bet you're being paid by soros or the like

>>55773044
>rust is by SJW
Could you elaborate on this statement? What exactly does it mean? What are its implications?

>>55771370
I don't even know rust yet I understand the reason behind there
str: probably correspond to inmutable string in the .text segment of the binary, but troublesome to transform
String: I guess it lives on the heap and thus you can change it
OS* talking the OS, I guess because windows defaults to UTF-16 and unix UTF-8
C* compatibility

>>55773114
>str: probably correspond to inmutable string in the .text segment of the binary, but troublesome to transform
Almost. &'static str (i.e. all hard-coded strings) are that. Strs with other lifetimes might not be. Strs can be allocated "anywhere" but represent contiguous bytes and are immutable. The str referenced by a String is on the heap, whereas other str are either on the stack or on the text segment. They are somewhat analogous to C arrays (with a much better interface) in that they are almost always manipulated from a reference, since str is an unsized type (i.e. the size of an str is not necessarily known at compile time).
>String: I guess it lives on the heap and thus you can change it
That is correct. Strings reference memory on the heap and represent dynamic strings.

Nobody uses Os* or C* in usercode.

>>55773114
Pretty good guess! The distinctions between &str/String, &OsStr/OsString, etc. have to do with the concept of ownership.
https://doc.rust-lang.org/book/ownership.html
https://doc.rust-lang.org/book/strings.html

&str/String are required to be valid UTF-8. No exceptions.

&OsStr/OsStrings, as you stated, vary based on the platform. The book explains it pretty well, but it seems like you understand the concept already. https://doc.rust-lang.org/std/ffi/struct.OsString.html

CStrings, like you guessed, are for compatibility. "An instance of this type is a static guarantee that the underlying bytes contain no interior 0 bytes and the final byte is 0." https://doc.rust-lang.org/std/ffi/struct.CString.html

There's also &Path/PathBuf, which is basically an &OsStr/OsString with additional path-related helper functions such as is_file, is_dir, exists, extension, etc. https://doc.rust-lang.org/std/path/struct.PathBuf.html

>>55773207
>Nobody uses Os* or C* in usercode.
Well, I've seen some people recommend using OsString rather than String for command-line arguments (specifically using std::env::args_os rather than std::env::args). Considering using Args can result in a runtime panic if invalid UTF-8 is passed as an argument, I'd say this is a decent suggestion.
As for CStrings...yeah, you're probably never gonna see those outside FFI bindings to C libraries.

I really, really hope they figure out TCO. I know they're reserving become as a keyword for it, but last I checked they didn't know if it was technically possible without unreasonable performance cost.

>>55773758
As far as I know become is a very old thing and TCO is automatic at the llvm ir level.

>>55773083
it means rust is created by SJW, is SJW, is made for SJWing, destroying all white men, makeing into cucks
must not let people use rust

>>55771616
>is light as fuck
What do you mean? Rust programs seem to eat more RAM than C++ ones for whatever reason.

File: why.png (42KB, 561x469px) Image search: [Google]

42KB, 561x469px

>>55774117
Am I missing something?

>>55775439
Never mind, compiling with -O works.

have you considered rewriting this thread in rust?

>Rust is otherwise quite permissive with respect to other dubious operations. Rust considers it "safe" to:
>Deadlock
>Have a race condition
>Leak memory
>Fail to call destructors
>Overflow integers
>Abort the program
>Delete the production database

Is it feasible to write a REST API in Rust compared to writing it in Go?

>>55768235
is anyone having issues using Rustup on El Captian?

Seems like every time I install it, after the reboot it's gone

File: screenshot.png (783KB, 1026x770px) Image search: [Google]

783KB, 1026x770px

Who /REDOX/ here?

http://www.redox-os.org/

Microkernel Design
Most features are implemented in Rust
Includes optional GUI - Orbital
Newlib provided for C programs
MIT Licensed
Drivers run in Userspace
Includes common Unix commands
ZFS Filesystem Support (WIP)

>>55771639
Development of Leaf has stopped: https://medium.com/@mjhirn/tensorflow-wins-89b78b29aafb#.n0i425l9u

>>55777362
Redox is impressive, although i have no idea what its purpose is.

>>55777362
I tried compiling it a few weeks ago but it was failing due to something in the compiler changing. Maybe I'll try again today

>>55777599
I'm not sure if it's its purpose, but it proves that writing a kernel in Rust is possible

C# is miles better.

File: 1453188536747.jpg (48KB, 480x348px) Image search: [Google]

48KB, 480x348px

>>55778057
ah, yes, the language that INJECTS TELEMETRY AT COMPILE TIME whether you want it or not

>using any language that runs in a VM, or uses a JIT

>>55778057
Interesting statement! Any evidence to back it up?

>>55778129
>Not using a HolyC JIT compiler as your shell

>>55775846
Yeah for some explanation, Rust doesn't implement tail call optimization but sibling call elimination but only when compiling on release so as to not fiddle with the stack frame when debugging.

Whilst understandably it's a bit frustrating since you can write code reliant on sibling call optimization but then you might have some trouble debugging with stack overflows and be forced to pay the additional compile time for release build when debugging.

>>55778004
>proves that writing a kernel in a turing complete language is possible
you don't say

>>55778497
So where's your Brainfuck kernel?

>>55778717
i don't know brainfuck

>>55778783
There's only 8 commands. You'll pick it up in no time.
https://en.wikipedia.org/wiki/Brainfuck#Commands

>>55775439
Have you tried compiling with -O?

>>55777288
What a load of bullshit. How writes this crap? It would be hilarious if it weren't infinitely pathetic.

>>55774978
It needs the same amount of memory as a C++ program compiled with clang when compiled with the same options

>>55777328
There are readily available native frameworks for that, such as rustless and rustful. I don't know how it compares to go though.

>>55777458
That's pretty sad, especially since they're grievously mistaken about the supposed advantages of tensorflow. It's also too bad they don't see how big a problem python and lua are for ML in real life (and fuck caffe, it's no good for actual science). Although maybe that's for the better since they didn't seem to care about ML, as opposed to making money.