8 ms·

Rust and the Blub Paradox

87 points by filsmick 11y ago

eximius 11y ago
"No, you don't have to learn monads." Ha! This is ironic because a present discussion over some syntactic sugar (maybe more) to make Rust error handling feel more part of the language and more ergonamic may be ad-hoc monads. Not that the programmer needs to know that - it's just something that should happen to play nice in the rest of the Rust type ecosystem
- M2Ys4U 11y ago
  I was under the impression that `Option<T>` and `Result<T, E>` were monads.
  - mafribe 11y ago
    MONSIEUR JOURDAIN: Oh, really? So when I say: "x := x+1" and "throw new Exception” is that monadic? PHILOSOPHY MASTER: Most clearly. MONSIEUR JOURDAIN: Well, what do you know about that! These forty years now I’ve been using monads in programming without knowing it! ------------------------------- With many apologies to Molière, many things are monadic including state and exceptions. Most programming languages introduce them as first-class core concepts rather than as monad instances. Hence you can use them innocently, without realising that they are monadic.
  - u320 11y ago
    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).
    - steveklabnik 11y ago
      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.
      - eximius 11y ago
        I would love to see this program. Maybe even spend some time trying to get it to compile.
        steveklabnik 11y ago
        https://www.reddit.com/r/rust/comments/2o6yp8/brainfck_in_rusts_type_system_aka_type_system_is/cmkrjz2 https://www.reddit.com/r/rust/comments/2o6yp8/brainfck_in_ru... was one of them
    - Manishearth 11y ago
      I think this is still possible with associated types. You can imitate higher kinded types with associated types, just that you wouldn't want to. I recall someone posting a Monad or Collection HKT example when associated types were proposed.
  - saurik 11y ago
    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, which is why identifying something as a monad ends up becoming so interesting in Haskell as opposed to many other languages.
    - pcwalton 11y ago
      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.
      - ngrilly 11y ago
        I've never heard this argument before. Very interesting.
jbandela1 11y ago
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 Parent - Inheritance is the Base Class of Evil - https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjDxbLRp8DKAhVB9R4KHRW7A2sQtwIIIzAB&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DbIhUE5uUFOA&usg=AFQjCNHGTLJ5VCeo9fzZD7foEiT0q4lLhw&sig2=KFJ3vZoxQNbRb4CBpOjS-A https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c... Herb Sutter - You don't know const and mutable - http://herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/ http://herbsutter.com/2013/01/01/video-you-dont-know-const-a... Andrei Alexandrescu - Systematic error handling in C++ - https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012... Herb Sutter - Writing Good C++ by Default - https://www.youtube.com/watch?v=hEx5DNLWGgA https://www.youtube.com/watch?v=hEx5DNLWGgA Andrew Sutton - Generic Programming with Concepts Lite - https://www.youtube.com/watch?v=qwXq5MqY2ZA https://www.youtube.com/watch?v=qwXq5MqY2ZA One of the things that helps with avoiding "Blubness" in C++ is the significant interest in languages such as Haskel (which is not considered a Blub language by anyone except Agda programmers) and in applying the techniques and insights where possible to C++ whether through writing new libraries (see for example Fit by Paul Fultz II -https://github.com/pfultz2/Fit https://github.com/pfultz2/Fit) or through new language features (see this post by David Sankel - http://davidsankel.com/uncategorized/c-language-support-for-pattern-matching-and-variants/ http://davidsankel.com/uncategorized/c-language-support-for-...) Finally, is also interesting that Paul Graham's blub paradox is being brought up in regards to Rust, C++, and D. The Paul Graham article is in large part talking about the power of meta-programming. In this regard, D and C++ are significantly more powerful in that regard. Features like higher kinded types (template templates), variadics, and non-type template parameters help in this matter. When you can write a function that can generically work with a tuple with any number and type of parameters, you can do some pretty neat stuff. For some examples take a look at Boost.Hana by Louis Dionne (http://boostorg.github.io/hana/ http://boostorg.github.io/hana/). In this regards, Rust is actually the Blub compared to D and C++.
chao- 11y ago
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 ("Value: (x: 7)" and "Value: (x: 5, y: 10)"). The addition of that goal might lead the programmer to treat the C++ version of print_me as something more abstract, accepting a string and having class Foo and class Bar simply return their own string representations. I acknowledge that the premise was "a beginner C++ developer", getting hyped up about inheritance and using it as the only tool in their toolbelt, but how many people are learning C++ as a first language these days? It used to be the norm, back in the OO-will-save-us-all heydey, but has anyone run into it lately?
- bluejekyll 11y ago
  Don't forget about how awesome C++'s multiple inheritance is! <sarcasm/> 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-aggregation http://stackoverflow.com/questions/269496/inheritance-vs-agg...
  - mercurial 11y ago
    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.
    - bluejekyll 11y ago
      Totally, no problem with default implementations as long as they are generic. Java finally supports this, as well as Rust and others.
  - GFK_of_xmaspast 11y ago
saurik 11y ago
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 the entire idea of relational databases really just hate MySQL, its limitations, and the attitude of its ecosystem). I feel one of the reasons I have been as productive as I have been over the years is that I have spent a lot of time studying error handling and even now have a sort of "theory of errors" that I will sometimes draw out for people on a blackboard. From my perspective, Rust is currently "unusable", though very compelling and will hopefully fix this problem. As much as I agree with other things it has built, and as much as I agree that my attempts to simulate those things in other languages have disappointing holes, after having spent a lot of time studying languages like Erlang and Haskell (and even as someone who teaches a class at a college on programming languages at the college level), not having exceptions or anything better than try! is a deal breaker for me, and while this person jokes about monads and how learning them might not be important, they would be well served learning why monads are interesting. One could even argue the entire section about error handling and how this developer is happy about how "straightforward" Rust is in comparison to monads is the "blub" issue rearing its head, but between Rust and Haskell. (The use of the word "straightforward" is always particularly concerning to me, as it is the general argument one uses for programming in C or Java instead of anything that hides intent.)
- tome 11y ago
  > I have spent a lot of time studying error handling and even now have a sort of "theory of errors" that I will sometimes draw out for people on a blackboard I would be very interested in a blog post on this.
  - deleted 11y ago
    [deleted]
- steveklabnik 11y ago
  Have you seen https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243 ? What do you think of it?
bluejekyll 11y ago
> 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.
- alimw 11y ago
  > 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????
  - nothrabannosir 11y ago
    $ g++ test.cpp $ ./a.out EDIT---answer removed to let others guess first.
    - eximius 11y ago
      Aw. As a user on my phone you make me sad.
      - nothrabannosir 11y ago
        Sorry about that. http://pastebin.com/T8fBtUnk http://pastebin.com/T8fBtUnk
    - alimw 11y ago
      Or Windows. Anyway my point was, why force your readers to find and use a compiler when you could just give the answer below? Not sure why I got downvoted.
- mpweiher 11y ago
  Of course, this has nothing to do with OO, and everything with C++. "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind" -- Alan Kay
draw_down 11y ago
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.
- pekk 11y ago
  I have a vague question: how can you avoid putting emphasis on memory management, to the extent Rust does, without introducing mandatory garbage collection?
  - tormeh 11y ago
    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.
  - firebones 11y ago
    At one extreme, this (???): https://en.wikipedia.org/wiki/Stack_machine https://en.wikipedia.org/wiki/Stack_machine
lobster_johnson 11y ago
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 such as: * Convenience — if you've highly proficient in X, there's a low barrier to entry for anything you want to accomplish. * Private ecosystem — if all your code is in X, you have potentially tons of reusable modules as part of your own stack. * Public ecosystem — lots of libraries and community support. * Mature documentation * Stability * Ease of hiring and so on. Also, not least: The journey of every developer is to broaden one's horizons gradually. As a junior you'll likely slog through a few fad languages until you reach a point where every technology out there, no matter how advanced, will suddenly become approachable. The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer. Sticking to one tool for many years probably says a lot about your ability to develop your skills, of course. In short, I think Blub is a red herring, and I think it's a condescending one, a product of survivorship bias — you're not superior because you succeeded using a certain set of tools. You're probably successful for other reasons (which may correlate with your ability to choose the right tools, or not). Graham's observation that "[languages] dictate the way [developers] think about programs" is the more important lesson to draw from his essay, though it's not exactly a new idea.
- danieldk 11y ago
  The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer. In fact, I think the original essay makes quite some unwarranted assumptions: But if you work for a startup that doesn't have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match. The median language will probably have a very good ecosystem that allows a small team of developers to quickly leverage. (Of course, someone who is not stuck in a Blub language has the same opportunity.) I think that there are very many counter-examples to the 'blub paradox'. Facebook was written in PHP, Paypal was written in Java, Dropbox was written in Python (which was a Blub language by 2007). Graham's observation that "[languages] dictate the way [developers] think about programs" is the more important lesson to draw from his essay, though it's not exactly a new idea. Indeed, this is a very important lesson, but not foreign to anyone who learnt LISP in the 70ies or Prolog in the 80ies ;).
shams93 11y ago
I'm slowly learning rust. Ive worked with c and jni in android for sound apps but now Im ignoring my reactions over the weird parts of rust so i can use it to builda killer music application for raspberry pi
- kitd 11y ago
  If it helps, I've called Rust over JNI. Fairly easy in fact though I recommend judicious examination of examples on the web first. Cargo is also very helpful in this regard.
- firebones 11y ago
  Any references/repos to learn from?
hsivonen 11y ago
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 Rust. In some talk, Andrei Alexandrescu said D is pursuing GC removal. It'll be interesting to see if D and C++ with lifetime annotations can achieve useful results with less syntax for the cases where Rust's elision doen't work and you need explicit lifetime annotations in Rust. I have doubts, but of course both Alexandrescu and Sutter are working on Rust's competitors, so one would expect them not to say that Rust's more awesome than their languages.
- steveklabnik 11y ago
  The CPP Core Guidelines are simlilar, but different. For example, Herb also said that data race prevention is a non-goal, and they still don't have any idea of how to handle concurrency. That doesn't make them bad, just different! I welcome any effort to make C++ more safe, there's a lot of code out there that could benefit.
- pcwalton 11y ago
  > 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.
  - 11y ago
pklausler 11y ago
Some programmers can write BASIC in any language. But on the up side, some programmers can write Haskell in any language.
sago 11y ago
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.
yakcyll 11y ago
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.
- steveklabnik 11y ago
  > 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. :)
  - yakcyll 11y ago
    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.
    - 11y ago

87 points by filsmick 11y ago

"No, you don't have to learn monads." Ha! This is ironic because a present discussion over some syntactic sugar (maybe more) to make Rust error handling feel more part of the language and more ergonamic may be ad-hoc monads. Not that the programmer needs to know that - it's just something that should happen to play nice in the rest of the Rust type ecosystem

M2Ys4U 11y ago
I was under the impression that `Option<T>` and `Result<T, E>` were monads.
- mafribe 11y ago
  MONSIEUR JOURDAIN: Oh, really? So when I say: "x := x+1" and "throw new Exception” is that monadic? PHILOSOPHY MASTER: Most clearly. MONSIEUR JOURDAIN: Well, what do you know about that! These forty years now I’ve been using monads in programming without knowing it! ------------------------------- With many apologies to Molière, many things are monadic including state and exceptions. Most programming languages introduce them as first-class core concepts rather than as monad instances. Hence you can use them innocently, without realising that they are monadic.
- u320 11y ago
  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).
  - steveklabnik 11y ago
    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.
    - eximius 11y ago
      I would love to see this program. Maybe even spend some time trying to get it to compile.
      - steveklabnik 11y ago
        https://www.reddit.com/r/rust/comments/2o6yp8/brainfck_in_rusts_type_system_aka_type_system_is/cmkrjz2 https://www.reddit.com/r/rust/comments/2o6yp8/brainfck_in_ru... was one of them
  - Manishearth 11y ago
    I think this is still possible with associated types. You can imitate higher kinded types with associated types, just that you wouldn't want to. I recall someone posting a Monad or Collection HKT example when associated types were proposed.
- saurik 11y ago
  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, which is why identifying something as a monad ends up becoming so interesting in Haskell as opposed to many other languages.
  - pcwalton 11y ago
    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.
    - ngrilly 11y ago
      I've never heard this argument before. Very interesting.

jbandela1 11y ago

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 Parent - Inheritance is the Base Class of Evil - https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjDxbLRp8DKAhVB9R4KHRW7A2sQtwIIIzAB&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DbIhUE5uUFOA&usg=AFQjCNHGTLJ5VCeo9fzZD7foEiT0q4lLhw&sig2=KFJ3vZoxQNbRb4CBpOjS-A https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c... Herb Sutter - You don't know const and mutable - http://herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/ http://herbsutter.com/2013/01/01/video-you-dont-know-const-a... Andrei Alexandrescu - Systematic error handling in C++ - https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012... Herb Sutter - Writing Good C++ by Default - https://www.youtube.com/watch?v=hEx5DNLWGgA https://www.youtube.com/watch?v=hEx5DNLWGgA Andrew Sutton - Generic Programming with Concepts Lite - https://www.youtube.com/watch?v=qwXq5MqY2ZA https://www.youtube.com/watch?v=qwXq5MqY2ZA One of the things that helps with avoiding "Blubness" in C++ is the significant interest in languages such as Haskel (which is not considered a Blub language by anyone except Agda programmers) and in applying the techniques and insights where possible to C++ whether through writing new libraries (see for example Fit by Paul Fultz II -https://github.com/pfultz2/Fit https://github.com/pfultz2/Fit) or through new language features (see this post by David Sankel - http://davidsankel.com/uncategorized/c-language-support-for-pattern-matching-and-variants/ http://davidsankel.com/uncategorized/c-language-support-for-...) Finally, is also interesting that Paul Graham's blub paradox is being brought up in regards to Rust, C++, and D. The Paul Graham article is in large part talking about the power of meta-programming. In this regard, D and C++ are significantly more powerful in that regard. Features like higher kinded types (template templates), variadics, and non-type template parameters help in this matter. When you can write a function that can generically work with a tuple with any number and type of parameters, you can do some pretty neat stuff. For some examples take a look at Boost.Hana by Louis Dionne (http://boostorg.github.io/hana/ http://boostorg.github.io/hana/). In this regards, Rust is actually the Blub compared to D and C++.

chao- 11y ago

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 ("Value: (x: 7)" and "Value: (x: 5, y: 10)"). The addition of that goal might lead the programmer to treat the C++ version of print_me as something more abstract, accepting a string and having class Foo and class Bar simply return their own string representations. I acknowledge that the premise was "a beginner C++ developer", getting hyped up about inheritance and using it as the only tool in their toolbelt, but how many people are learning C++ as a first language these days? It used to be the norm, back in the OO-will-save-us-all heydey, but has anyone run into it lately?

bluejekyll 11y ago
Don't forget about how awesome C++'s multiple inheritance is! <sarcasm/> 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-aggregation http://stackoverflow.com/questions/269496/inheritance-vs-agg...
- mercurial 11y ago
  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.
  - bluejekyll 11y ago
    Totally, no problem with default implementations as long as they are generic. Java finally supports this, as well as Rust and others.
- GFK_of_xmaspast 11y ago

saurik 11y ago

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 the entire idea of relational databases really just hate MySQL, its limitations, and the attitude of its ecosystem). I feel one of the reasons I have been as productive as I have been over the years is that I have spent a lot of time studying error handling and even now have a sort of "theory of errors" that I will sometimes draw out for people on a blackboard. From my perspective, Rust is currently "unusable", though very compelling and will hopefully fix this problem. As much as I agree with other things it has built, and as much as I agree that my attempts to simulate those things in other languages have disappointing holes, after having spent a lot of time studying languages like Erlang and Haskell (and even as someone who teaches a class at a college on programming languages at the college level), not having exceptions or anything better than try! is a deal breaker for me, and while this person jokes about monads and how learning them might not be important, they would be well served learning why monads are interesting. One could even argue the entire section about error handling and how this developer is happy about how "straightforward" Rust is in comparison to monads is the "blub" issue rearing its head, but between Rust and Haskell. (The use of the word "straightforward" is always particularly concerning to me, as it is the general argument one uses for programming in C or Java instead of anything that hides intent.)

tome 11y ago
> I have spent a lot of time studying error handling and even now have a sort of "theory of errors" that I will sometimes draw out for people on a blackboard I would be very interested in a blog post on this.
- deleted 11y ago
  [deleted]
steveklabnik 11y ago
Have you seen https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243 ? What do you think of it?

bluejekyll 11y ago

> 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.

alimw 11y ago
> 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????
- nothrabannosir 11y ago
  $ g++ test.cpp $ ./a.out EDIT---answer removed to let others guess first.
  - eximius 11y ago
    Aw. As a user on my phone you make me sad.
    - nothrabannosir 11y ago
      Sorry about that. http://pastebin.com/T8fBtUnk http://pastebin.com/T8fBtUnk
  - alimw 11y ago
    Or Windows. Anyway my point was, why force your readers to find and use a compiler when you could just give the answer below? Not sure why I got downvoted.
mpweiher 11y ago
Of course, this has nothing to do with OO, and everything with C++. "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind" -- Alan Kay

draw_down 11y ago

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.

pekk 11y ago
I have a vague question: how can you avoid putting emphasis on memory management, to the extent Rust does, without introducing mandatory garbage collection?
- tormeh 11y ago
  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.
- firebones 11y ago
  At one extreme, this (???): https://en.wikipedia.org/wiki/Stack_machine https://en.wikipedia.org/wiki/Stack_machine

lobster_johnson 11y ago

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 such as: * Convenience — if you've highly proficient in X, there's a low barrier to entry for anything you want to accomplish. * Private ecosystem — if all your code is in X, you have potentially tons of reusable modules as part of your own stack. * Public ecosystem — lots of libraries and community support. * Mature documentation * Stability * Ease of hiring and so on. Also, not least: The journey of every developer is to broaden one's horizons gradually. As a junior you'll likely slog through a few fad languages until you reach a point where every technology out there, no matter how advanced, will suddenly become approachable. The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer. Sticking to one tool for many years probably says a lot about your ability to develop your skills, of course. In short, I think Blub is a red herring, and I think it's a condescending one, a product of survivorship bias — you're not superior because you succeeded using a certain set of tools. You're probably successful for other reasons (which may correlate with your ability to choose the right tools, or not). Graham's observation that "[languages] dictate the way [developers] think about programs" is the more important lesson to draw from his essay, though it's not exactly a new idea.

danieldk 11y ago
The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer. In fact, I think the original essay makes quite some unwarranted assumptions: But if you work for a startup that doesn't have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match. The median language will probably have a very good ecosystem that allows a small team of developers to quickly leverage. (Of course, someone who is not stuck in a Blub language has the same opportunity.) I think that there are very many counter-examples to the 'blub paradox'. Facebook was written in PHP, Paypal was written in Java, Dropbox was written in Python (which was a Blub language by 2007). Graham's observation that "[languages] dictate the way [developers] think about programs" is the more important lesson to draw from his essay, though it's not exactly a new idea. Indeed, this is a very important lesson, but not foreign to anyone who learnt LISP in the 70ies or Prolog in the 80ies ;).

shams93 11y ago

I'm slowly learning rust. Ive worked with c and jni in android for sound apps but now Im ignoring my reactions over the weird parts of rust so i can use it to builda killer music application for raspberry pi

kitd 11y ago
If it helps, I've called Rust over JNI. Fairly easy in fact though I recommend judicious examination of examples on the web first. Cargo is also very helpful in this regard.
firebones 11y ago
Any references/repos to learn from?

hsivonen 11y ago

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 Rust. In some talk, Andrei Alexandrescu said D is pursuing GC removal. It'll be interesting to see if D and C++ with lifetime annotations can achieve useful results with less syntax for the cases where Rust's elision doen't work and you need explicit lifetime annotations in Rust. I have doubts, but of course both Alexandrescu and Sutter are working on Rust's competitors, so one would expect them not to say that Rust's more awesome than their languages.

steveklabnik 11y ago
The CPP Core Guidelines are simlilar, but different. For example, Herb also said that data race prevention is a non-goal, and they still don't have any idea of how to handle concurrency. That doesn't make them bad, just different! I welcome any effort to make C++ more safe, there's a lot of code out there that could benefit.
pcwalton 11y ago
> 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.
- 11y ago

pklausler 11y ago

Some programmers can write BASIC in any language. But on the up side, some programmers can write Haskell in any language.

sago 11y ago

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.

yakcyll 11y ago

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.

steveklabnik 11y ago
> 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. :)
- yakcyll 11y ago
  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.
  - 11y ago