Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust and the Blub Paradox

jonathanturner.org

Post reply on HN
Print view View original

61–70 of 90 posts

Re: Rust and the Blub Paradox

#61

Post by mst »

steveklabnik wrote: post #28
mst wrote: post #26

Earlier quoted context omitted.

Is that mostly a faster feedback loop and better errors thing? It seems like so long as the generated code doesn't get as far as compiling, it doesn't make that much of a difference? (this could easily be a stupid question; I know I've come across as condescending to you before by mistake and if I've somehow done it again please believe that I meant to come across as genuinely curious :)

Not at all! Yes, to me, it's largely about better errors and such. If th generated code is wrong, it won't compile, so it's not _that_ level of bad. But this can't happen in Rust: http://tgceec.tumblr.com/

Now I want to see an article that compares the error messages from rust and D metaprogramming ... though admittedly, at least half of this is because you could call said article "D missed nosejob day".

Re: Rust and the Blub Paradox

#62

Post by bluejekyll »

mercurial wrote: post #53
bluejekyll wrote: post #17

Earlier quoted context omitted.

Don't forget about how awesome C++'s multiple inheritance is! edit: It's worth the down votes on this. Multiple inheritance is pure evil and confusion. In fact, even in Java I now rely on aggregation over inheritance. http://stackoverflow.com/questions/269496/inheritance-vs-agg...

Unfortunately, in some languages, inheritance of abstract classes is the only way to get the equivalent of interfaces. That said, yeah, the less class inheritance, the better. Ideally, work in a language where interfaces can include default implementations.

Totally, no problem with default implementations as long as they are generic. Java finally supports this, as well as Rust and others.

Re: Rust and the Blub Paradox

#63

Post by mst »

pcwalton wrote: post #31
mst wrote: post #26

Earlier quoted context omitted.

Is that mostly a faster feedback loop and better errors thing? It seems like so long as the generated code doesn't get as far as compiling, it doesn't make that much of a difference? (this could easily be a stupid question; I know I've come across as condescending to you before by mistake and if I've somehow done it again please believe that I meant to come across as genuinely curious :)

There are a number of benefits to concepts: - They make namespacing of functions easier, eliminating the need for C++'s "argument-dependent lookup". The issues here are somewhat subtle and would take a lot of space to explain. But the end result is that we can remove a massive amount of confusion by getting rid of ADL. - Error messages are much better, because the insides of templates never leak to users of the templ…

> Error messages are much better, because the insides of templates never leak to users of the template

This is unequivocally a good thing - I think maybe my disconnect here in how excited I am compared to others is that I'm comparing it to the experience of debugging lisp macros and everybody else is comparing it to the bottomless pit of despair that is C++ template errors ;)

Re: Rust and the Blub Paradox

#64

Post by geofft »

yakcyll wrote: post #57

For a C++ developer, Rust introduces a lot of seemingly arbitrary rules and constraints on how data can be managed, moved around and referenced. In order to develop things that employ a lot of composing, one has to either make the code nigh unreadable with tons of unnecessary chaining (which is unavoidable, since simple dereferencing and assigning a value of a field in a structure to a variable means the structure is…

simple dereferencing and assigning a value of a field in a structure to a variable means the structure is now borrowed and you can't reference the field nor the structure until the variable goes out of scope; please, for the love of all that is holy, prove me wrong!

This is only partially true. If you hold a mutable reference to a field in a structure, you can't get a reference to the entire structure. (Think of a mutable reference as a read-write lock, because that's what it is, just at compile time / type level instead of at runtime.) However, you can get a mutable reference to other fields in the structure. And an immutable reference to a field (analogous to a read-only / shared lock) does not prevent other immutable references, so you can totally get a reference to the structure while a reference to one of its fields is outstanding.

Here's an example of this on play.rust-lang.org: http://is.gd/ySSsex

That compiles and runs with the extra scope around the mutable borrows. If you comment out that scope, then yes, it won't compile.

My experience, coming to Rust from C++ and C, is that a lot of real-world C++ and C code is imprecise about mutability and shared references, and relies on the programmer not doing anything particularly weird. It's true that in this example, nothing would go wrong by omitting the braces because the references g and h aren't actually used. But in larger and legacy codebases, it's very easy to forget the mutability rules that were in the head of the previous programmer. So directly porting C++ code is going to be annoying, but that's mostly because the hard work is figuring out what was implicit in the C++.

Re: Rust and the Blub Paradox

#65

Post by steveklabnik »

yakcyll wrote: post #60
steveklabnik wrote: post #58

Earlier quoted context omitted.

> seemingly arbitrary rules Most of them are about Rust's core guarantee: data race freedom. Some of them are due to a certain conservativeness of any static analysis, and may be relaxed in the future. > for the love of all that is holy, prove me wrong It depends on exactly what you're doing. There are always ways to get around things, but it can depend on knowing Rust and its standard libraries well. As a younger la…

Definitely! I'm just hoping for this 'aha!' moment, since it just feels like black magic for me. I think conservative approach to fundamentals is a great way to build a robust language and the way it's presented to me suggests that's one of the objectives; however, for an outsider with experience in other, more lenient (and, obviously, bug-prone) languages, those constraints might appear too restrictive. I believe it…

Totally. I'm actually re-doing all of the docs on this stuff right now, I hope that the next iteration will maybe make it easier to grok. We'll see!

Re: Rust and the Blub Paradox

#66

Post by pcwalton »

hsivonen wrote: post #38

In his CppCon 2015 keynote, Herb Sutter talked about retrofitting Rust's core concepts (not phrased like that!) onto C++ as a static analysis pass distinct from the actual compile. Unlike Stroustrup, he acknowledged the existence of Rust but said the lifetime annotations are too verbose. Rust has lifetime elision for the common cases, though. It's unclear to me if the criticism was based on a pre-elision version of R…

> Unlike Stroustrup, he acknowledged the existence of Rust but said the lifetime annotations are too verbose.

As far as I can tell, this was an incorrect claim. The ISO Core C++ lifetime elision rules aren't meaningfully more aggressive than Rust's. We could easily add more elision to Rust if it turned out to be necessary, but the cases in which ISO Core C++ has extra lifetime elision rules that Rust doesn't don't come up often enough to make a difference.

Lifetime elision is a double-edged sword anyway. It's somewhat controversial in the Rust community, because it's not reading the lifetime annotations that causes the cognitive overhead: it's the semantics and what the compiler will enforce. Having fewer lifetime annotations can actually make the code a lot more confusing. Based on experience, I would caution C++ to not go overboard with it: being able to show pretty code on slides is not worth confused and frustrated users.

Re: Rust and the Blub Paradox

#67

Post by joncampbelldev »

pekk wrote: post #55
lobster_johnson wrote: post #32

I think articles like these beg the question. It introduces a claim ("many/most people think some languages are too weird") and tries to refute it without first showing that the claim is true. Sure, I see lots of evidence of junior developers living in a happy bubble where they apply language X to everything, when they could expand their horizons a bit by looking into Y and Z. But this also ignores important factors…

The implication that a developer is junior if they mainly use one language is completely absurd.

Everyone has a language they like best and spend a lot of time in (due to current job or side projects or whatever), but a developer who has never branched out to other languages and paradigms even to experiment for a bit (maybe bring back some knowledge to their preferred language) is someone I wouldn't want to work with.

But this is all from my perspective in a small startup where people have very broad responsibilities. I can completely understand a very senior developer working in a specific field (usually it's the low level stuff with C etc) who only works in one language because there's just no opportunity to use anything else.

Or perhaps someone who just sees their job as a 9-5 thing and looks elsewhere in their life for learning and growth.

Re: Rust and the Blub Paradox

#68

Post by dbaupp »

steveklabnik wrote: post #29
pcwalton wrote: post #22

Earlier quoted context omitted.

Rust's error handling is, empirically, not unusable. I use it every day. Even Go's error handling clearly isn't unusable, as controversial as it is, and try! is pretty much just a more sugary version of it. Also, we were well aware of monads when we designed the Rust error handling system and in particular why they do not work very well in languages that have rich, imperative control flow structures. try! is basicall…

I still don't fully understand the break/continue/return argument, at all. I should bug someone to actually write this up.

I wrote a comment a while ago that has some code examples: https://github.com/rust-lang/rfcs/pull/243#issuecomment-8220... (and the following two comments)

Re: Rust and the Blub Paradox

#69

Post by tormeh »

pekk wrote: post #56
draw_down wrote: post #21

This article is a bit all over the place, and the basic premise is not very good. The Andrei guy says that Rust places too much emphasis on "clerical" memory management. This is not like a person who learned PHP from a couple w3schools article deciding that Lisp is "weird". The criticism is not that Rust is "weird" or somehow unintelligible, it's a direct critique of the language designers' choices. This is the dange…

I have a vague question: how can you avoid putting emphasis on memory management, to the extent Rust does, without introducing mandatory garbage collection?

My understanding is that Rust is, to be wildly inaccurate, kind of like a language without a heap. Normal languages manage stack memory without GC. Rust kind of does the same: When deleting a stack frame, Rust deletes the objects created when on that stack frame, except when a reference is returned by the scope corresponding to the frame, in which case the "ownership" of the heap object is passed to the frame under the deleted-to-be frame.

Sort of. Don't cite me.

Re: Rust and the Blub Paradox

#70

Post by eximius »

steveklabnik wrote: post #11
u320 wrote: post #7

Earlier quoted context omitted.

Yes but the Rust type system cannot express monads, so they aren't monads in the type sense (they don't implement a specific Monad trait).

Fun Trivia Fact: Rust's type system was[1] Turing complete. So you could actually have monads. You just wouldn't want to. 1: The program that proved this no longer compiles, so we're not sure if the type system is or is not at the moment.

I would love to see this program. Maybe even spend some time trying to get it to compile.
Post reply on HN