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

81–90 of 90 posts

Re: Rust and the Blub Paradox

#81

Post by dbaupp »

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…

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

It might be a direct critique, but it's a critique of an incomplete picture of Rust: the rules that allow Rust to avoid a GC offer benefits far beyond just that, such as being a core component of Rust's concurrency story[1], and avoiding problems such as iterator invalidation (not generally a memory safety problem in a GC'd language, but still a semantic one, e.g. Java's ConcurrentModificationException).

(The "Weird feature #3" part of the article is exactly this point, although I think it doesn't go far enough in calling out the incomplete picture of Rust implied by the original quote.)

[1]: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

Re: Rust and the Blub Paradox

#82

Post by Manishearth »

dbaupp wrote: post #80
Manishearth wrote: post #75

Earlier quoted context omitted.

> Most of them are about Rust's core guarantee: data race freedom IMO this is just a part of it (and I think you agree, based on previous conversations). The actual thing is that the rules enforce a discipline about data, similar to the discipline in functional languages (except here it's allowing sharing XOR mutation instead of forbidding mutation entirely). This discipline gets us many things -- memory safety, safe…

I strongly disagree: the goal with Rust is to offer safe, low-level programming, not to be a test-bed (or whatever) for some programming paradigm. The "discipline" is just a tool to reach the goal. You can see this in the evolution of Rust: the goal hasn't changed, but the tool used to (try to) reach it has. (I know that you mention ignoring the chronology, but ignoring the intent doesn't make sense.) Put another way…

You misunderstand me: I don't disagree that Rust is all about safe systems programming. I disagree that "data race freedom" is Rust's (only) core guarantee, and I disagree that the "seemingly arbitrary rules" are about "data race freedom". They're about so much more, since the same rules get us memory safety as well, among other things.

I don't think that Rust is trying to test out a programming paradigm or whatever, I'm saying that these "seemingly arbitrary rules" get us a lot of things, by proxy of a certain paradigm, and reducing it to "data race freedom" (when it's so much more) is something we should avoid.

(My comment seems to focus on the discipline, I was just using it as a proxy for all of the things it gets us)

Re: Rust and the Blub Paradox

#83

Post by mpweiher »

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.

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

Re: Rust and the Blub Paradox

#85

Post by lobster_johnson »

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.

I don't see how you could interpret my comment that way.

A junior dev might use a single language because they apply what they know and don't go outside their comfort zone. A senior dev might use a single language for every other reason.

Re: Rust and the Blub Paradox

#86

Post by firebones »

shams93 wrote: post #33

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

Any references/repos to learn from?

Re: Rust and the Blub Paradox

#87

Post by firebones »

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?

At one extreme, this (???): https://en.wikipedia.org/wiki/Stack_machine

Re: Rust and the Blub Paradox

#88

Post by dbaupp »

Manishearth wrote: post #82
dbaupp wrote: post #80

Earlier quoted context omitted.

I strongly disagree: the goal with Rust is to offer safe, low-level programming, not to be a test-bed (or whatever) for some programming paradigm. The "discipline" is just a tool to reach the goal. You can see this in the evolution of Rust: the goal hasn't changed, but the tool used to (try to) reach it has. (I know that you mention ignoring the chronology, but ignoring the intent doesn't make sense.) Put another way…

You misunderstand me: I don't disagree that Rust is all about safe systems programming. I disagree that "data race freedom" is Rust's (only) core guarantee, and I disagree that the "seemingly arbitrary rules" are about "data race freedom". They're about so much more, since the same rules get us memory safety as well, among other things. I don't think that Rust is trying to test out a programming paradigm or whatever,…

As we discussed on IRC, "data race freedom" is equivalent to guaranteeing memory safety, and so, in a kind-of pedantic way, data race freedom is the core guarantee. That said, the original comment would've been better phrased as "one of Rust's core guarantees".

Furthermore, I still think the best phrasing of the rules is for that guarantee: if a rule is removed one can usually construct fairly simple programs that have data races/memory unsafety. Of course, it is definitely true that the arbitrary rules have other benefits, but if there was a simpler scheme that gave the core memory safety without the other things, I think Rust would've adopted it.

Re: Rust and the Blub Paradox

#89

Post by alimw »

nothrabannosir wrote: post #30
alimw wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Rust and the Blub Paradox

#90

Post by steveklabnik »

eximius wrote: post #70
steveklabnik wrote: post #11

Earlier quoted context omitted.

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.

https://www.reddit.com/r/rust/comments/2o6yp8/brainfck_in_ru... was one of them
Post reply on HN