[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 19760



File: 1477699458489.png (80.15 KB, 300x300, logo-v2.png)

No.19760

Anyone here interested in or learning Rust? This language looks like it will finally be the one language to put C++ away for good. It gives very low level control over memory, more so than C++ even while using very high level Ocaml-like abstractions. So far no big project has been made with Rust so there is still speculation as to what its capable of. Ive read a couple of books (there are only a couple out) and gone through the official tutorial and while much of it is easy to understand I still lack an overall grasp of this language. Have you guys tried this language yet?

  No.19761

>>19760
>No big project has been made with rust.
What about Mozilla's servo? It looks very promising and it already has a big community around it.

  No.19762

>>19761
> big community around it.

Define "big". A bunch of paid hackers at Mozilla doesn't really mean it's a big community.

Everybody is buzzwording and peacocking over how great Rust is, and yet oddly there just don't seem to be very many interesting projects in production using it.

Definitely an emphasis on projecting awesome rather than implementing it, though that's understandable.

  No.19765

>there is still speculation as to what its capable of
Just about every other language.
In a scale from C to LISP, I'd say it's a Rust

  No.19767

I learned Rust. It seemed like it was *very* constricted in what it could do, unless you entered 'unsafe' mode and basically lost all guarantees provided by the language.

You'd be better off using all the fancy new features of C++11

  No.19769

>>19761
>What about Mozilla's servo?
Servo is just part of the rendering engine that still has a lot of C++ in it. Mozilla is starting work on Quantum that is a full web engine that will be coded in Rust.

  No.19772

>>19767
>I learned Rust. It seemed like it was *very* constricted in what it could do, unless you entered 'unsafe' mode and basically lost all guarantees provided by the language.
Its human nature to think that if you do something manually that you will have more control over efficiency than if you rely on the programming language to manage things. The only way to test a language is to use it in a very large project. Thats all that matters is the end result, not some grey haired 1-trick pony programmer stroking himself to how his favorite (and only) language makes him feel free.

  No.19773

>>19772
>stroking himself to how his favorite (and only) language makes him feel free.
why would some "grey haired" programmer know only one language?

  No.19774

>>19773
let me list *all* the programming languages in common use in the early 90s

C/C++
VB
Delphi
Perl

did I miss anything?

  No.19777

>>19760
I use Rust for most of my projects. I'm pretty happy with it, but I would be really interested in built-in formal verification.
It would probably make the language less useful for most people, but maybe it could be made easy to use. Too bad that will never be a Rust feature.

I'm currently working on an HTTP framework(?) based on Golang's net/http. Yesterday it reached the point where I could write simple web servers.

>>19767
I'm interested in what you found constricted about it. Any time I felt constricted, I soon found that it was due to my lack of knowledge of the standard library.

I haven't had to use unsafe code yet, but it is sometimes necessary. For most use cases, you shouldn't be using unsafe often.

>>19774
Maybe Cobol? Not completely sure when it was popular.

  No.19778

>>19777
>I'm currently working on an HTTP framework(?) based on Golang's net/http.
Awesome!!!! I am very curious about Rust's potential to implement web servers considering its concurrency model is a lot stronger and safer than Go's. Recoding something like Hadoop in Rust would be incredible.

  No.19779

>>19778
I think it has high potential, but right now everything is a mess.
Futures[1] and Tokio[2] were announced recently, and it's looking as though a lot of networking software will be switching to these libraries.

I'm pretty sure that most web frameworks make use of hyper[3]. I've never worked with hyper, but I've worked with rotor[4], which hyper makes use of for concurrency.

Rotor is basically a wrapper around mio[5] that reduces a bunch of boilerplate. Mio (and rotor as well) use an event loop for concurrency. As a user of these libraries you implement a state machine.

Tokio combines futures and mio to allow concurrent I/O without having to work with state machines. I'm less familiar with how this works, I haven't had a chance to read the library yet.

At a higher level, there are a few web frameworks available. Iron, Nickel, and Conduit are some examples. There's more information about the state of Rust web development at http://www.arewewebyet.org/ .

[1] https://github.com/alexcrichton/futures-rs
[2] https://github.com/tokio-rs/tokio
[3] https://github.com/hyperium/hyper
[4] https://github.com/tailhook/rotor
[5] https://github.com/carllerche/mio

  No.19782

>>19774
Conflating c and c++ AND naming Delphi (the IDE) instead of Object Pascal (the language). Outrageous and absurd.

But, ehh, there were probably more schemers then than now, though still doesn't count as common I would say. TCL, maybe? It still lingers in old EDA tools that have TCL interfaces. Ada was required in defense contracting until 1997, I would say that counts as common.

  No.19785

>>19779
>Rotor is basically a wrapper around mio[5] that reduces a bunch of boilerplate. Mio (and rotor as well) use an event loop for concurrency. As a user of these libraries you implement a state machine.
Thanks for this info, I'll look this up. I havent spent much time looking into concurrency in Go either but I think that Go uses a scheduler similar to Erlang's OTP which acts as a sort of mini operating system to orchestrate threads. Im guessing the event loop in Rust works the same way in that it manages concurrent processes instead of a single thread process like node.js

  No.19792

>>19777
>Maybe Cobol? Not completely sure when it was popular.
COBOL was a mainframe language that never made it to personal computers and business software of the 90s


>>19782
> AND naming Delphi (the IDE) instead of Object Pascal (the language). Outrageous and absurd.
I think that the version of Object Pascal in Delphi diverged from the standard enough to be its own language

>TCL, maybe? It still lingers in old EDA tools that have TCL interfaces.

TCL is a very interesting language even today, fun to play with and has lots of novel ideas but not something anyone ever wanted to use to get real work done. The TK libraries however are pretty much the default GUI libraries for any scripting language

>Ada was required in defense contracting until 1997, I would say that counts as common.

I really wish Ada had gone mainstream but it never did, its only been commonly used for flight systems. Part of the problem being that there were never any good Ada compilers available to the general public in the 80s/90s.

  No.19795

I don't like the way that crates.io (the Rust package repository) works. It isn't namespaced, so there can only be one package with a name.

In an ideal world, this would work fine; but then you have idiots like the people who run the Iron framework who give all of their middleware generic names.

For example, their is a package called urlencoded that parses HTML form data. However, it is specific to Iron, so it is basically useless to anyone else.

I didn't really care about the official "Community Team" before, but they've completely ignored all discussion about this problem. It really makes me want to stop using Rust.

  No.19804

I've been learning rust, Its alright but i spend 70% of my time fighting with the borrow checker which is less than fun and i was sort of on the way to giving up. However i did discover that Servo has a mentoring contribution programme thing, so i think that could be fun for being an opensource project to contribute to.

Has anyone here contributed to servo? It seems pretty cool

  No.19805

>>19804
I've looked at servo in the past and it seems like a cool project. They do a lot of things differently than the rest of the Rust ecosystem.

How long have you been working with Rust? Most people struggle with the borrow checker for maybe a few months.
At some point you just get it and it becomes a really nice tool rather than a hindrance.

If you have specific questions you could always ask in one of the rust irc channels.

  No.19825

>>19805
Only for a month or so really, I need to just keep practicing with the language.

  No.21368

I'm looking to learn Rust (with already quite a bit of general programming experience under my belt). What would be the best resource?
I'm currently looking at https://doc.rust-lang.org/book/ . Is there anything better or should I go with that?

  No.21387

>>21368
this tutorial is outstanding
http://cglab.ca/~abeinges/blah/too-many-lists/book/
it teaches Rust by showing how bad linked lists are as a data structure

  No.21388

>>21387
>it teaches Rust by showing how bad linked lists are as a data structure
Linked lists are a perfectly fine data structure for their best cases. Efficient insertion or deletion in a vector is complicated and worse.

Memory caching and at times space savings are the only reason I see many advocating against linked lists, which usually amounts to a negligible performance hit.

As it stands, a great deal of efficient software has been written that makes use of heavy indirection, linked lists, and other so-called performance liabilities.

  No.21515

Trying to use Rust for a game, the Piston package is turning out to be complicated and the API is extremely spread out, making it very difficult for someone new to the codebase like me to figure out basic operations.
I'm spoiled by Racket's superb docs

  No.21516

Found this project, seems pretty fun. I'm following along and might improve upon it after i'm finished.

https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html

  No.21517

>>21515
Can you tell more about the Piston game engine, like is it built on OpenGL? Are there any tutorials for Piston or are you just using the docs?

It really pisses me off that there are not books out on 3D game programming for Rust or Go

  No.21518

There's a new project aiming to rewrite the C parts of emacs in Rust, check it out:
https://github.com/Wilfred/remacs

  No.21519

>>21518
mmm nice.
It would be cool if the world of application programming would move from C towards Rust.
Let C be excusively used for the kernel.... yes...

  No.21520

>>21517
>>21517
It has a generic back end interface where you usually put in the opengl implementation, and from then on you don't need to interact with any of the OpenGL API. There are small examples on the github that I am trying to learn off of, but as I said I'm struggling a bit at the moment. The biggest confusions are probably figuring out whats important and what isnt, and how the components are intended to be used. I would love a more thorough guide that explains this rather than just giving you code samples to decipher and pick apart. Especially considering some of the crates used in the simplest samples are outright undocumented.

  No.21521

>>19795
I think it is developers thinking that "modular" means breaking a framework into arbitrary crates, not about actually modularizing API's to be independent. Your particular example is very unfortunate; Rust devs have a lot to learn from languages outside of C++.

  No.21522

>>19761
Is this something a total newb at programming could learn easy? I have no experience.

  No.21523

>>19762

Yeah I'm using rust and know a bunch of people that either use Rust or Go. Most projects are in systems programming and infrastructure. I can't speak to what you might call interesting but maybe it just isn't something thats predominantly in a field you'd be in.

I've seen it plenty in bioinformatics mostly as a glue between cluster nodes.

  No.21572

Does anyone have the "Mastering Rust" book? If you do, please upload it ITT. Couldn't find in my channels for book downloads.

  No.21594

>>21519
>It would be cool if the world of application programming would move from C towards Rust.

No, no it would not. Rust is the complete opposite of C in terms of design, is slower, and can't even do everything C can do without calling inline C or dropping to unsafe mode. Rust is not competing for C's job.

  No.21614

>>21572
it hasnt been published yet

  No.21615

What is Rust like for socket programming and working with blocking io? Does it have epoll?

  No.21616


  No.21631

>>19782
Honestly, Tcl/Tk is still my goto when I want to bang a quick gui or do some prototyping.

I don't know if I would ever want to work on anyone else's Tcl code, or use it in a "real" project. But it's a fun language to use, and it works great for Tk scripting. It's also very flexible too, and fun to hack with.

I'm not sure why it has a "bad reputation" today. I guess it's not as cool as scheme. But man tell me that trace isn't a killer feature!

  No.21648

Hello, lain. How do you guys deal with input in rust? I have a question for my specific method and i'd like to know about how you do it.
Below is my library for dealing with input, however i'd like to generalize it in a way that an input can indicate what type will be returned. For example, i could have an enum with all types, mapped to the input parameter, however i didn't have the time to try that out yet, i'm not sure if it's going to work. Could you help me?
fn read_float() -> f32{
let reader = std::io::stdin();
let mut input_text = String::new();

reader.read_line(&mut input_text).ok().expect("failed to read line");

let input_opt: Option<f32> = input_text.trim().parse::<f32>().ok();

let input_float = match input_opt {
Some(input_float) => input_float,
None => {
println!("please input a number");
return -1.0;
}
};

input_float
}

fn read_int() -> i32{
let reader = std::io::stdin();
let mut input_text = String::new();

reader.read_line(&mut input_text).ok().expect("failed to read line");

let input_opt: Option<i32> = input_text.trim().parse::<i32>().ok();

let input_int = match input_opt {
Some(input_int) => input_int,
None => {
println!("please input a number");
return -1;
}
};

input_int
}

  No.21663

>>19760
>This language looks like it will finally be the one language to put C++ away for good.
If Rust is good, then it's good. But the same things have been said about C and COBOL...

  No.21667

>>21648
Looks like you want to use the FromStr trait
fn read_input<T: FromStr>(default_val: T) -> T {
let reader = std::io::stdin();
let mut input_text = String::new();

reader.read_line(&mut input_text).ok().expect("failed to read line");

let input_opt = input_text.trim().parse::<T>().ok();

match input_opt {
Some(x) => x,
None => {
println!("please input a number");
return default_val;
}
}
}

  No.21668

>>21663
>But the same things have been said about C
C has zero abstractions, absolutely ZERO

There is nothing more annoying to me than programming in C which is nothing but a sea of for loops where you have to manually move every byte in its own variable. It has dangerous/joke I/O and string libraries that you constantly have to manually guard against safety and security errors. The reason people like C and that C has dominated is that it gives a *perceived* sense of control when actually much of this boilerplate kind of programming can be abstracted over with container methods. People who program in C think they are writing *fast code* only because they think that they can manually control something to run faster than what an optimizing compiler can produce, much the same way people think asm is inherently faster than compiler optimization

  No.21674

>>21668
>C has zero abstractions, absolutely ZERO
That's not true. If C had no abstractions then you'd have complete control over the output, there would be no need to use inline asm and the compiler wouldn't even need to optimize.
The fact that the compiler has to perform some crazy optimizations to run fast, even though the language was designed to be easy to create a compiler to and people often refer to it as "portable assembler" means, to me at least, that it has failed as the low-level language it claims to be, and that it offers a very poor API to the compiled code.

  No.21676

>>21674
>very poor API to the compiled code
I mean to the CPU instructions.

  No.21678

>>21668
>>21674
The reason C requires such gargantuan compilers to reach a reasonable speed is, in my opinion, due to the lack of metaprogramming. The C language isn't powerful enough to allow the programmer to specify detailed restraints and compile customized representations, so the compiler must attempt to weed this information out.

As an example of a low level language that does have this, Forth is a language known for being small and efficient. The compiler generally performs no optimizations. However, the language allows arbitrary Forth programs to be run during compilation, which allows a program to manually inline the result of a function, to name one possibility.

What are Rust's metaprogramming facilities like? If Rust didn't perform certain optimizations or include certain features, such as pure function optimization and more than one type of loop, would it be possible to add them?

  No.21695

>>21678
Rust has pretty basic hygenic macros; metaprogramming is not a goal of the language. You can do neat stuff like implementing syntax for building HTML trees, but AFAIK it can't even do, e.g. parsing format strings at compile time.

  No.21699

>>21668
Well, C has structs, functions, function pointers, so I wouldn't say it has ZERO abstractions. Not as many abstractions as other languages, sure, but structs, functions, arrays, etc are abstractions.

  No.22632

>>21695
???
The Println! macro does exactly that, and allows formated printing to be type-safe.

Also, Rust just got procedural macros in 1.15, which are more traditional syntax-quote macros.

  No.22633

I'm working on a medium-to-large-sized project using Rust. Not a big fan of it but it's thousand times better than C++. Just thinking about C++'s retarded syntax and working with STL and libboost makes me cringe.

  No.22650

>>21523
I'm not a fan of Rust, especially due to its community, but it's a fairly new language. I think time will cure the lack of projects and I hope that one day it will improve and it'll actually be worth learning.