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

21–30 of 90 posts

Re: Rust and the Blub Paradox

#21

Post by draw_down »

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 danger of using rules like the Blub paradox, you have to be careful or everyone who doesn't agree with you or doesn't like what you like is a Blub-programming dullard.

I actually do think there is something to the paradox, I would even say I have occupied different parts of that "ladder" myself. (That is, I'd like to think I'm higher on it now than I used to be.) But maybe JS programmers aren't interested in type-checking in their JS precisely because they prefer JS for its dynamically-typed nature. This is as opposed to someone coming to JS from a different language and bringing their preference for strong typing with them.

Then the author goes on to talk about a bunch of stuff that does nothing to explain Rust's apparent emphasis on memory. It's pretty much just a list of why Rust is cooler and better than C++. That's fine but none of it addresses the point made at the outset.

Re: Rust and the Blub Paradox

#22

Post by pcwalton »

saurik wrote: post #14

I think "blub" is relative. I look at people who think that cluttering code with boilerplate for error handling, and even those who think that boilerplate is sufficient is sufficiently papered over using macros, have yet to understand why exceptions are interesting or (often) how to use them correctly (as many uses of exceptions that people like to poke at are entrenched wrongness, much like how many people who hate…

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 basically just monads for imperative languages. To see this, work through what happens if you try to add break/continue/return to Haskell's system.

Re: Rust and the Blub Paradox

#23

Post by pcwalton »

jbandela1 wrote: post #3

Wow, this is the first post I have ever read that even kind of implied that Andrei Alexandrescu was a Blub programmer. Part of being a Blub programmer is that you don't even think about the issues. In regards to the weird features brought up, the underlying issues behind these features have been in the C++ consciousness for some time. Below are some talks and resources covering at least some of these issues. Sean Par…

C++'s templates are untyped. Rust's templates are typed. Most people aren't aware of the difference, and they naturally think that templates "have to work" like the ones in their favorite language (dynamically typed if coming from C++ and D, and statically typed if coming from Java, C#, or most other languages). But the fact that Rust and C++/D picked different sides of the tradeoff is the key source of the differences between them.

C++ and D programmers, like you (and Andrei), look down on Rust generics and give examples of all the things that you can't do with Rust generics that are easy to do with C++ templates. But there's an equally strong counterargument, in that Rust generics never give errors at template expansion time and are guaranteed to expand to valid code. This makes code easier to understand, improves the experience for users of your generics, and also simplifies the implementation, leading to potentially better compile times (since you typecheck once instead of after every template expansion). Of course, this is a tradeoff: it's more work for us to implement the features necessary to do the kinds of sophisticated metaprogramming you see in C++ and D, and there will always be some things you can't do in Rust that are easy in C++ and D. But that isn't a slam-dunk argument for untyped templates vs. typed generics any more than easy reflection is a slam-dunk argument for dynamic typing like Python vs. static typing like Java.

Re: Rust and the Blub Paradox

#24

Post by pcwalton »

saurik wrote: post #18
M2Ys4U wrote: post #4

Earlier quoted context omitted.

I was under the impression that `Option ` and `Result ` were monads.

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.

Re: Rust and the Blub Paradox

#25

Post by pcwalton »

jbandela1 wrote: post #8
steveklabnik wrote: post #6

Earlier quoted context omitted.

> In this regards, Rust is actually the Blub I'm not so sure. We are aware of the features that they have; we just prefer the strongly-typed versions to the stringly-typed[1] versions. We do desire more meta-programming features, and they will happen. Like all decisions, we don't want to rush into them. 1: This is not _entirely_ accurate, but I'm slightly at a loss for how to exactly characterize this at this particu…

The last statement was more in regards to the Blub definition implied by the article. Of course, people who are immersed in programming language theory are not Blub programmers - they are aware of what is possible, but are also aware of the inherent tradeoffs. With regards to Rust, do you have any idea when more meta-programming features like variadics and non-type template parameters might be available in the langua…

> My test for the power of a language's type manipulation is how easy is it to write an implementation of apply(Function f, Tuple t) which will call f with the values of t. I would be most interested to see how Rust will implement this kind of metaprogramming.

That's kind of a weird litmus test of the power of the language's type manipulation: it only applies to languages where functions take multiple arguments, it's a pretty niche use case (since the workaround in Rust is straightforward), and there's nothing particularly sophisticated about variadic generics (what you need to solve the problem). I could equally say that my litmus test of a language's generics system is whether the compiler prevents errors during template expansion.

Anyway, to answer your question: that's really easy in Rust, as long as you're on nightly. The FnMut trait (and friends) allow you to call functions with tuples as arguments. https://doc.rust-lang.org/std/ops/trait.FnMut.html

Re: Rust and the Blub Paradox

#26

Post by mst »

steveklabnik wrote: post #6
jbandela1 wrote: post #3

Wow, this is the first post I have ever read that even kind of implied that Andrei Alexandrescu was a Blub programmer. Part of being a Blub programmer is that you don't even think about the issues. In regards to the weird features brought up, the underlying issues behind these features have been in the C++ consciousness for some time. Below are some talks and resources covering at least some of these issues. Sean Par…

> In this regards, Rust is actually the Blub I'm not so sure. We are aware of the features that they have; we just prefer the strongly-typed versions to the stringly-typed[1] versions. We do desire more meta-programming features, and they will happen. Like all decisions, we don't want to rush into them. 1: This is not _entirely_ accurate, but I'm slightly at a loss for how to exactly characterize this at this particu…

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 :)

Re: Rust and the Blub Paradox

#27

Post by alimw »

bluejekyll wrote: post #15

> What does the C++ code print? And there it is. I programmed in C++ long enough to "know" this, but I still remember more jr. Engineers and even arguments with more sr. Engineers around this type of question. Rust has removed this kind of question almost entirely from the language. Personally, I have no intention of ever going back to C/C++ for any new project I work on.

> What does the C++ code print? If you guessed wrong, don't worry. You're in good company. If you guessed right, congrats!

How do I knowwww????

Re: Rust and the Blub Paradox

#28

Post by steveklabnik »

mst wrote: post #26
steveklabnik wrote: post #6

Earlier quoted context omitted.

> In this regards, Rust is actually the Blub I'm not so sure. We are aware of the features that they have; we just prefer the strongly-typed versions to the stringly-typed[1] versions. We do desire more meta-programming features, and they will happen. Like all decisions, we don't want to rush into them. 1: This is not _entirely_ accurate, but I'm slightly at a loss for how to exactly characterize this at this particu…

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/

Re: Rust and the Blub Paradox

#29

Post by steveklabnik »

pcwalton wrote: post #22
saurik wrote: post #14

I think "blub" is relative. I look at people who think that cluttering code with boilerplate for error handling, and even those who think that boilerplate is sufficient is sufficiently papered over using macros, have yet to understand why exceptions are interesting or (often) how to use them correctly (as many uses of exceptions that people like to poke at are entrenched wrongness, much like how many people who hate…

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.

Re: Rust and the Blub Paradox

#30

Post by nothrabannosir »

alimw wrote: post #27
bluejekyll wrote: post #15

> What does the C++ code print? And there it is. I programmed in C++ long enough to "know" this, but I still remember more jr. Engineers and even arguments with more sr. Engineers around this type of question. Rust has removed this kind of question almost entirely from the language. Personally, I have no intention of ever going back to C/C++ for any new project I work on.

> What does the C++ code print? If you guessed wrong, don't worry. You're in good company. If you guessed right, congrats! How do I knowwww????

    $ g++ test.cpp
    $ ./a.out
    EDIT---answer removed to let others guess first.
Post reply on HN