lad

This quote from Linus is what I find inspiring hope of a future wider adoption or Rust:

Thanks. I decided to try to do the merge on my own, but failed. I came close, but it was good to have your example merge to see what I got wrong.

The pin_init becoming a crate of its own, but ‘pin::Pin’ being in the core crate ended up messing with my “monkey see, monkey do” approach to Rust merges.

I’ll learn eventually, in the meantime please do continue to give me example merges and I’ll use them as training wheels.

My girlfriend is gonna be mighty upset is she thinks I’m into that kinda thing. […] please change the image to something Gnome-related and/or trustworthy.

That’s an interesting takeaway from a DDoS issue

It’s a step in between

It then takes it a step further, as they are both 0 in that regard

I’d say that trying to get Rust everywhere is just something that is done in the hope it will help the ecosystem mature faster. It’s a bit hard to compete with languages that are 30, 40, or over 50 years old

TBF, your previous post reads to me the opposite way, like ‘it is not enough of a hate site’. Also I would offer you to look at it as a Venn diagram, if something is a hate site and more, it is still a hate site, just with extra

I don’t think this operator is a real feature, tbh 😅

I couldn’t agree more with the latter part, I know a lot of backend engineers who consider frontend simple without ever trying what it really takes. This is not a healthy way to view someone else’s work, and it usually produces friction between back and front end teams

I was toldo the other day that in ten years there will be no testers because developers will do all the testing.

I’ve seen how it works out in practice: there’s not enough time for testing and for developing, too, developers are going to burn and the product is going to be shit done and shit tested. Maybe it works if your company is willing to spend extra for less results by someone doing all the stuff less efficient than what they could, but that’s a rare occurrence.

Almost nowhere but America exists /s

MacOS does this, but on screen recording it never shows it. Feels good to see Linux records what user actually saw

Oh, that explains it. Well, I imagine a license that also forbids people to imagine it. Fuck you and your imagination

The screenshot seems to violate the licence it contains.

Reasonable and viable ≠ RFC compliant

This quote summarises my views:

There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard.

This is the ideal rendition, I would say. On a related note, I just love it when there are backspaces in my filenames

There are many regexes that validate email, and they usually aren’t compliant with the RFC, there are some details in the very old answer on SO. So, better not validate and just send a confirmation, than restrict and lock people out, imo

and which of these two you are going to get paid more for

It looks like exactly 4 characters are missing, so public and static would fit, but I never saw static instead of public static, so I think you’re right. On the other hand, I don’t use Java anymore and couldn’t be bothered about such details

Depends on what was the course about. If it’s about computation, then sure. If it’s about OOP or architecture design (this one I wouldn’t expect, unfortunately, but would be nice if it was taught somewhere), then the point is not just to run something.

I mostly come to prefer composition, this approach apparently even has a wiki page. But that’s in part because I use Rust that forbids inheritance, and don’t have such bullshit (from delegation wiki page):

class A {
    void foo() {
        // "this" also known under the names "current", "me" and "self" in other languages
        this.bar();
    }

    void bar() {
        print("a.bar");
    }
}

class B {
    private delegate A a; // delegation link

    public B(A a) {
        this.a = a;
    }

    void foo() {
        a.foo(); // call foo() on the a-instance
    }

    void bar() {
        print("b.bar");
    }
}

a = new A();
b = new B(a); // establish delegation between two objects

Calling b.foo() will result in b.bar being printed, since this refers to the original receiver object, b, within the context of a. The resulting ambiguity of this is referred to as object schizophrenia

Translating the implicit this into an explicit parameter, the call (in B, with a a delegate) a.foo() translates to A.foo(b), using the type of a for method resolution, but the delegating object b for the this argument.

Why would one substitute b as this when called from b.a is beyond me, seriously.