RUST Discussion

Gąska

@Bulb said:

Is there a rust binding for some GUI library yet though?

I doubt it.

Bulb

@dkf said:

sentence seems absent … It's Friday night here

It's Friday night here too.

@dkf said:

I'm not up to comprehending it by just visiting the site and poking around.

The modules are approximately classified to categories (like Text, HTML, Email, File, etc.) and are mostly named after what they actually do or work with rather than having random funny/clever/… names.

Though looking there it seems it got much more disorganised lately. I don't use perl much any more, so I was not aware how bad it got.

@Gaska said:

I doubt it.

Actually after a bit more searching I noticed somebody is working on Gtk bindings, but only the Gdk and cairo parts exist is registered as a crates yet.

I also finally found SDL (which does not have much in the way of widgets, but it's at least reasonably usable and well known for drawing) and Allegro (which has some very elementary widgets; I haven't used that thing in ages, but it was the first real graphic library I used back then some 20 years ago in DOS with with djgpp).

The higher level problem is that there is no system in the tags yet. So some of the libraries are tagged ‘graphics’, some are tagged ‘windowing’, but there is no way to find what tags exist, what they are supposed to mean and while it is possible to list packages by tag, the only way to get there I found is to find some package with the tag and open the tag from there.

tar

@Bulb said:

The modules are approximately classified to categories (like Text, HTML, Email, File, etc.) and are mostly named after what they actually do or work with rather than having random funny/clever/… names.

That's a point in favour of Rust at least. I hate trying to find Python libraries where they all have "cute" and "clever" names like PyThis, PyThat and PyMyLife where it's actually not in any way endearing, it's just a demonstration of creepy groupthink and it makes me want to beat people with a cluebat until they stop doing this.

Or, you know, use a different language, where libraries were named by people with an iota of self-respect...

Yamikuronue

Case in point: I had some issues with "phantom"'s installer not being able to find "node" while installing dependencies for things called "grunt", "smushit", and "qunit".

tar

@Bulb said:

https://crates.io/crates/sdl2

This is encouraging. I'll take a look at this before commenting further, but SDL is generally my favourite low-level system/platform API, so it'd be a logical place for me to start from if I wanted to do graphics (or audio) from Rust...

Onyx

@tar said:

I hate trying to find Python libraries where they all have "cute" and "clever" names like PyThis, PyThat and PyMyLife where it's actually not in any way endearing.

And Qt has this fetish for QWhatever. Sigh.

*looks at his latest personal project folder name*

Well... shit.

tar

##Qnyx?

Onyx

@tar said:

##Qnyx?

No... who would be that big of an egoist?

... New → Project ...

tar

@Buddy said:

As for how closure lifetime is relevant (you basically have to think about memory if you want to Rust), I played around a bit with @tar's make_closure function a bit, and I think I've found an example that can illuminate. Note the nested scope in which the closure is created; try to guess why it's necessary.

Taking the closure out of the picture for the time being, this seems to demonstrate one of the defining characteristics of Rust references: you can't have two references to the same memory location at the same time. Once c comes into scope, we can no longer refer to x (presumably it's been "borrowed") until c goes away again.
If this was C++, we have no problems refering to x and *c at the same time...

fn main() {
    let mut x = 1;
    {
        let c = &mut x;
        *c += 2;
        *c += 4;
        //println!("      = {}" , x); //NOPE!
        println!("      = {}" , *c);
    }
    println!("      = {}" , x);
}

[See http://is.gd/l60ItO for a 'live' version of the example at https://play.rust-lang.org/]

tar

@Buddy said:

Awesome. Although, apparently |&mut:| is now obsolete; they want you to let them infer the closure type all by their self.

Not only is the &mut: obsolete, it now causes errors! (Which is fine, it was an ugly syntax anyway—I guess I'll have to abandon the alpha build for the nightly though *sigh*.)

For great justice, here is a tidied up closure code with example on play.rust-lang.org:

#![feature(box_syntax)]

fn make_closure<'a>(start: i32) -> Box<FnMut(i32) -> i32 + 'a> {

    let mut v = start;

    box move |a: i32| -> i32 {
        let t = v + a;
        println!("{} + {} = {}", v, a, t);
        v = t;
        t
    }
}

fn main() {
    let mut a = make_closure(100);
    a(1); a(2); a(3); a(4);
}

Both examples take a variable outside of the closure's scope to accumulate the inputs, the distinction being whether that variable is passed into make_closure() by reference or by value.

tar

@Onyx said:

... New → Project ...

If Qt spawns its own IDE, that's going to end up as "New Qroject..."
Filed under: Qelp! Now I qan't qtop!

Onyx

@tar said:

If Qt spawns its own IDE, that's going to end up as "New Qroject..."

Qt Creator - Wikipedia

Though no one is stopping you from making another one...

Buddy

The advantage of passing a reference in is that the compiler can infer the lifetime of the returned value from it, simplifying the make_closure declaration (for reference, the rules are: if one reference is passed in, the output will have the same lifetime, else if multiple references are passed in and one is a reference to self, the output will have the same lifetime, else you need to annotate). I assume that the need to annotate lifetimes in the no-input-reference case is just a rough edge on the compiler that they're gonna get around to.

Note that you can have multiple const references to the same variable; you just can't give someone a reference to a var and still be able to mutate it.

Onyx

And I thought JavaScript variable lifetimes were enough of a pain already.

Filed under: ok, wtf is this referring to now?

Buddy

Oh, there's no confusion in Rust. If you do something wrong, the compiler will make sure you know about it. Just not what the actual problem is or how to fix it.

Onyx

Yes, I gathered that. It's just that most of the "how do I do this in Rust" discussion that happened here was concerned with "how do I make Rust realize I want this variable to be available here?".

At least it looked that way to me. I will admit I skimmed over some stuff, but that's the feel I get as a person who doesn't really know Rust but is cautiously interested in what people have to say about it.

Buddy

Many new users to Rust experience something we like to call "fighting with the borrow checker," where the Rust compiler refuses to compile a program that the author thinks is valid. This often happens because the programmer's mental model of how ownership should work doesn't match the actual rules that Rust implements. You probably will experience similar things at first. There is good news, however: more experienced Rust developers report that once they work with the rules of the ownership system for a period of time, they fight the borrow checker less and less.

Yeah, to me it seems like an entirely new way of doing things, and I'm starting to see why some people are quite enthusiastic about it. The idea that you can get all of the ease of use (lifetimes don't seem that hard to get the hang of, compared to the intricacies of any other language's memory model) and guaranteed memory safety (in fact, more memory safety, as objects cannot be null) of garbage collected languages while still allocating a majority of variables on the stack is very appealing.

Gąska

@tar said:

you can't have two references to the same memory location at the same time

You can. But neither can be mutable. Also, there's RefCell - a thing that allows you to check if the thing was already borrowed before you borrow it yourself. Most commonly used as Rc<RefCell<T>>, which is effectively C++'s shared_ptr.

cartman82

You guys are still into rust? That's so January 2015. Get with the times.

Why the project stalled? · Issue #8 · ckkashyap/rustix

Hi, Sorry to create an issue about this, but I'm very interested in why you decided to abandon Rust for this task and use Nim instead. Could you please tell us what are the challenges and why R...

GitHub - andreaferretti/on-rust-and-nim: A first experience with Rust

A first experience with Rust. Contribute to andreaferretti/on-rust-and-nim development by creating an account on GitHub.

Gąska

Nim has even weirder syntax and even less tutorials than Rust. Also, it's unsafe. Not to mention it's actually older.

ben_lubar

@Gaska said:

Also, it's unsafe.

Goto considered harmful.
Vaccines are correlated with autism.
Nim is unsafe.

dkf

That's a really terrible attempt at a haiku…

Gąska

@ben_lubar said:

Go considered harmful.

FTFY

@ben_lubar said:

Vaccines are correlated with autism.

Pick lesser evil.

@ben_lubar said:

Nim is unsafe.

According to Rust definition of safety, it is. I know it's probably the strictest definition ever made, but still.

accalia

@ben_lubar said:

Vaccines are correlated with autism

Cite your sources.

No, seriously.

There is no qualified and scientific report I am aware of that has the gall to claim that.

Onyx

Not again...

Buddy

It is possible that what Ben is saying is that the criticisms of goto and nim are similarly reactionary and unscientific.

Filed Under: What we really need, is a vaccination against autism.

Under Filed Under, Filed Under: dwarf fortress.

accalia

Be that as it may, my comment stands.

Too many people take what they read anecdotally as gospel truth and that "fact" had caused to much harm for it to go unchallenged.

Gąska

Except goto REALLY fucks up control flow, which reduces readability significantly and makes room for potential bugs.

Onyx

@accalia said:

Be that as it may, my comment stands.

Yes.

@accalia said:

Too many people take what they read anecdotally as gospel truth and that "fact" had caused to much harm for it to go unchallenged.

Again, yes. But we already did this at least twice and (sadly) nothing was accomplished. Do we really need to tread over it in another thread?

accalia

@Onyx said:

Do we really need to tread over it in another thread?

Hrmmmmm..... -grumble mutter-

Objection withdrawn your honor.

blakeyrat

@accalia said:

Cite your sources.

No, seriously.

There is no qualified and scientific report I am aware of that has the gall to claim that.

Wow. People think I'm Drax.

Did you seriously not figure out Ben's message?

Jaloopa

@Buddy said:

What we really need, is a vaccination against autism.

But won't that give our children Measles?

@accalia said:

that "fact" had caused to much harm for it to go unchallenged.

QFT. Also, http://howdovaccinescauseautism.com/

ben_lubar

Okay, look at it this way:

If there are more people in the world and the same fraction has autism, there are more people with autism.

If there are more people in the world, there need to be more vaccines administered overall, or we'll all die of preventable diseases.

See? Both go up at the same time.

accalia

correlation is not causation. i object strenuously to the idea that vaccines cause autism.

dkf

Yeah! Autism causes vaccines!

ben_lubar

I never said one causes the other. Re-read my post.

delfinom

@Gaska said:

Except goto REALLY fucks up control flow, which reduces readability significantly and makes room for potential bugs.

Or you can bury the error path cleanup in 60 different places of your function! Because that's readable.

Gąska

I didn't say avoiding goto automatically makes your code good. But using goto automatically makes it bad.

delfinom

Shit, I guess Linux and BSD kernels are bad.

dkf

@Gaska said:

I didn't say avoiding goto automatically makes your code good. But using goto automatically makes it bad.

Repeat after me: goto is a flow control primitive, so use it only where necessary, and never where a higher-level construct will do the job more neatly. (And none of break, continue, throw or return are a goto.)

However, bear in mind that making a bunch of boolean control variables instead of using one goto isn't necessarily an improvement.

tar

@Buddy said:

It is possible that what Ben is saying is that the criticisms of goto and nim are similarly reactionary and unscientific.

Anything is possible. It could be an encrypted message about Dwarf Fortress for all we know....

tar

@Gaska said:

Except goto REALLY fucks up control flow, which reduces readability significantly and makes room for potential bugs.

Oh please. goto is just a child's toy. Everyone knows that when it comes to fucking up control flow, (call/cc) is what the big boys use.

Onyx

And real men use break 3;

PHP: break - Manual

ben_lubar

COME FROM

Gąska

@delfinom said:

Shit, I guess Linux and BSD kernels are bad.

The kernels might be good, but the source is awful. Bad code doesn't automatically lead to bad product - sometimes it's needed for optimizations that compiler isn't capable of. Linux is full of that stuff - which makes it a better product and a worse code at the same time.

@dkf said:

Repeat after me: goto is a flow control primitive, so use it only where necessary, and never where a higher-level construct will do the job more neatly.

Give me one example of when goto is a better choice than a loop, a conditional, break, continue, an inner function, a switch, or any other programming technique that can solve the problem leads to less readable code than goto.

dkf

@Gaska said:

Give me one example of when goto is a better choice than a loop, a conditional, break, continue, an inner function, a switch, or any other programming technique that can solve the problem leads to less readable code than goto.

I refuse to do that; in those cases (i.e., excluding the “any other programming technique” as being too bloody vague, natch), the non-goto construct is definitely better. However, as I said, goto is a flow control primitive that exists to cover the other cases where there is not an existing neat flow control primitive that does the job. As the state of language design has advanced over the years, the set of flow control patterns for which a goto is truly necessary has become much smaller; the main area I'm aware of now is for the construction of true state machines (where doing it with a switch in a loop can be rather miserably awkward).

Most programmers don't write such state machines — they tend to be a bit unobvious, as anyone who's tried to debug the code generated by bison or another LALR(1) parser generator would testify — but the capability to write them is very useful. The main use of goto in C is actually to create comprehensible error handling and cleanup code, but that's much less important in later languages like C++ and Java (RAII, GC and try/catch/finally have made a significant difference). Indeed, Java actually doesn't support goto at all (it's a reserved keyword, but is never accepted by the grammar) and programmers survive somehow.

tar

@Gaska said:

Give me one example of when goto is a better choice than a loop, a conditional, break, continue,

Warning: example is unsalted, may contain straw, etc...
We have three nested loops and we want to break out of the inner two on occasion, without breaking out of the outer loop:

void FakeClass::weird_intensive_computation() {
    for(i=0; i<X; i++) {
        for(j=0;j<Y;j++) {
            for(k=0;k<Z;++) {
                // do some stuff inside our tight loop
                // code in here needs to be optimal...
                if(want_to_skip_rest_of_Y_and_Z_start_next_X_iteration) {
                    goto skipped_rest_of_yz;
                }
            }
        }
skipped_rest_of_yz: ;
    }
}

Onyx

PHP:

break 2;

Best language ever! We can all go home now.

Gąska

@dkf said:

I refuse to do that; in those cases (i.e., excluding the “any other programming technique” as being too bloody vague, natch),

It was meant to be bloody vague - my point isn't "you can use break or whatever in place of goto", but "there's always a better way to do something than goto". When making a list of features, it's easy to forget some particular one that you will then write a matching goto-using code where this feature would be perfect, and when I say that you can use this feature instead, you would be all blakeyranty about me not saying in my original post that this feature was allowed.

@dkf said:

As the state of language design has advanced over the years, the set of flow control patterns for which a goto is truly necessary has become much smaller;

My argument is that it isn't just much smaller, but literally empty.

@dkf said:

the main area I'm aware of now is for the construction of true state machines (where doing it with a switch in a loop can be rather miserably awkward).

State machines are now being made using composition and hierarchical polymorphism.

@tar said:

We have three nested loops and we want to break out of the inner two on occasion, without breaking out of the outer loop:

void FakeClass::weird_intensive_computation() {
    for(i=0; i<X; i++) {
        [&] {
            for(j=0;j<Y;j++) {
                for(k=0;k<Z;++) {
                    // do some stuff inside our tight loop
                    // code in here needs to be optimal...
                    if(want_to_skip_rest_of_Y_and_Z_start_next_X_iteration) {
                        return;
                    }
                }
            }
        }();
        // rest of X
    }
}

Don't worry about optimizations - the lambda will be inlined by every production-grade compiler there is. Although TBH, parameterized breaks are clearer. Not all languages have then, however.

tar

@Gaska said:

Don't worry about optimizations - the lambda will be inlined by every production-grade compiler there is. Although TBH, parameterized breaks are clearer. Not all languages have then, however.

See, "parameterized breaks" are spelled goto in C++ :<zxy>P

However, I didn't specify you couldn't use C++11, so I suppose your solution is acceptable. Of course, I'd want to see the assembly language out for both versions of the function before a conceding that the lambda version is a valid replacement.

(I might also profile the compile time for both versions as well, if I wanted to be truly dickweeded in my pedantry...)