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

51–60 of 90 posts

Re: Rust and the Blub Paradox

#51

Post by pcwalton »

pka wrote: post #47
pcwalton wrote: post #40

Earlier quoted context omitted.

do is only really good if you use it for the whole function, or at least have some way to get the error out of the do block to the code that's supposed to handle it. But if break isn't allowed inside a do block, then if you need to break you have to split up your do blocks into blocks before the break and after the break. Now if there's an error thrown by one of the statements in one of those do blocks, then you have…

Can't break be simulated by something like MaybeT? And forWithBreakM :: [a] -> (a -> m (Maybe b)) -> m [b] that stops when f yields Nothing? (isn't this actually sequence . forM?)

Yeah, there are transformations that we could apply to the code to make it work. But those transformations aren't trivial in the general case: how about breaking out of multiple loops or returns out of the function from inside loops? At some point, the transformations that we'd have to do would get so complex they'd hinder the programmer's mental model of what code will get generated. We'd also have to do a fair bit of work to make sure the optimizer can figure out what we're encoding so as to not lose performance.

Re: Rust and the Blub Paradox

#52

Post by sago »

How very patronizing. There's a tendency we all have to assume that someone would agree with us, if they weren't so ignorant/stupid/naive. None of us want to feel that we'd agree with them if only we understood.

Seems this is the programming equivalent. Programmer X turns their nose up at my pet language Y. It can't be because of me, it has to be their naivitee/ignorance/lack of experience/bias, etc, etc.

That the article was a big "you're ignorant" to Andrei Alexandrescu, of all people, was telling.

Re: Rust and the Blub Paradox

#53

Post by mercurial »

bluejekyll wrote: post #17
chao- wrote: post #12

I haven't written C++ with any significance in a few years, and done little with Rust at all. So while I don't feel qualified to speak to the comparison at the core of the blog post, I did find the first example to be disingenuous. It rests entirely on assuming the C++ programmer will rely on inheritance to achieve polymorphism, simply because they can? Additionally, the C++ example doesn't produce the same output ("…

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.

Re: Rust and the Blub Paradox

#54

Post by steveklabnik »

pcwalton wrote: post #49
steveklabnik wrote: post #42

Earlier quoted context omitted.

The usual implementation of the Either/Option monads already does this though: instance Monad Maybe where return x = Just x Nothing >>= f = Nothing Just x >>= f = f x fail _ = Nothing and instance (Error e) => Monad (Either e) where return x = Right x Right x >>= f = f x Left err >>= f = Left err fail msg = Left (strMsg msg) The end result is still a value of that type. You get the short-circuting behavior as soon as…

It only short-circuits to the end of the do block. But once you leave the do block the error isn't propagated anymore.

Right. Maybe this is because I tend to write small functions, but the amount of things that end in `Ok(())` especially with IO still makes me think it would be useful.

Re: Rust and the Blub Paradox

#55

Post by pekk »

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.

Re: Rust and the Blub Paradox

#56

Post by pekk »

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?

Re: Rust and the Blub Paradox

#57

Post by yakcyll »

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 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!) or the entire data model has to be rethought with those rules in mind. Not sure about others, but I sure as hell still have a lot of trouble wrapping my head around boxes, mutability and lifetimes; maybe I'm making some fundamentally flawed assumptions trying to draw similarities between C++ and Rust, but those issues are showstoppers for me for now.

Re: Rust and the Blub Paradox

#58

Post by steveklabnik »

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…

  > 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 language, some patterns are still being developed, and aren't always as obvious as they could be. We'll get there...

Rust is certainly a different language, and if you try to port C++ code directly over, you may have problems. Such is life. :)

Re: Rust and the Blub Paradox

#59

Post by ngrilly »

pcwalton wrote: post #24
saurik wrote: post #18

Earlier quoted context omitted.

What makes monads in Haskell interesting is that someone identified them as a pattern, generalized their usage, and then syntax was added to the language that lets you compose them in a natural manner. Sequential execution itself "is a monad", but in most languages we express that using something as simple as ";" or "\n": Haskell effectively generalized the idea of statements to support anything that is monadic, whic…

And Haskell gave up rich control flow (break, continue, early return) by doing so. If you trace through what having those statements means for monads as a first-class concept, you find that the situation becomes very much not that simple.

I've never heard this argument before. Very interesting.

Re: Rust and the Blub Paradox

#60

Post by yakcyll »

steveklabnik wrote: post #58
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…

> 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's a transitional feeling though, hence calling them 'seemingly' arbitrary.

Post reply on HN