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

Some notes on Rust

lambda-the-ultimate.org

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Some notes on Rust

#101

Post by NotableAlamode »

steveklabnik wrote: post #54
NotableAlamode wrote: post #51

Earlier quoted context omitted.

Is anybody actively working on this? I suspect that doing this well is non-trivial. Neither Tofte/Talpin nor Cyclone, both of which heavily inspired Rust's lifetimes, have HKTs as far as I'm aware.

Everything is focused on shipping a good 1.0, so no.

I understand that 1.0 was / is a priority. But I wonder what the state of discussions about HKTs in Rust is: is this addition believed to be an easy problem in the sense that it may be a lot of work, but no major roadblocks are expected? Or are there open questions that require substantial research?

Re: Some notes on Rust

#102

Post by NotableAlamode »

Animats wrote: post #69
NotableAlamode wrote: post #64

Earlier quoted context omitted.

Just a historical note: Rust's ownership system has much historical pedigree, such as the Cyclone language and the work on ML compilers with region inference, following Tofte and Talpin's pioneering work. The Wikipedia article ( https://en.wikipedia.org/wiki/Region-based_memory_management... ) has a good overview.

I know, I wrote one of the early papers: Strict Mode for C++ (2001): http://animats.com/papers/languages/cppstrictpointers.html Further back, Ada has region-based memory allocation. Around 2002, when there was concern about computer-related terrorism, I suggested that the C++ standards committee's unwillingness to deal with memory safety constituted material support of terrorism. They were angry, and terrified. That…

I had no idea that Ada has regions. The Wikipedia article doesn't mention it. Maybe somebody who knows about it wants to edit the article?

Re: Some notes on Rust

#103

Post by ajanuary »

deathanatos wrote: post #100
ajanuary wrote: post #93

Earlier quoted context omitted.

The issue is it makes it difficult to notice that a function might return when scanning through a function. Especially as it's in places that are looking for a value (e.g. assignment). At the moment it's just return and try!, but people look to the standard library for what is acceptable. When the standard library contains a macro that can return, people will write their own macros that return. It could potentially b…

> The issue is it makes it difficult to notice that a function might return when scanning through a function. What other solutions are there? The only other approach to error handling I've seen is exceptions (e.g., C++, Java, C#, JS…), and if you don't like `try!` because it is a "hidden return", you certainly won't like exceptions. At least with Rust's macros, I know that in the absence of one, there is no return; i…

It's a trade off. For the trouble of exceptions I get nice benefits like stack traces (though there are proposals to add stack traces to Rusts error handling). There are times when I really like exceptions, and times (such as trying to trace through an execution path) that I'm irritated by them.

What other solutions are there? Well, you could make the return explicit:

    let z = try!(x / y, onerror = return)
There are obvious downsides, such as added verbosity, and the need to figure out keyword arguments in macros, and do you allow access to the error value etc. but at least I can grep for/highlight "return". It also makes the meaning of the slightly confusingly named "try" more obvious (again, I'm vaguely aware of proposals that would change the name).

I think ultimately try! is a good thing, but I don't think it's trivially "a very appropriate use of macros". It's a considered use given some difficult trade-offs.

Re: Some notes on Rust

#104

Post by steveklabnik »

NotableAlamode wrote: post #101
steveklabnik wrote: post #54

Earlier quoted context omitted.

Everything is focused on shipping a good 1.0, so no.

I understand that 1.0 was / is a priority. But I wonder what the state of discussions about HKTs in Rust is: is this addition believed to be an easy problem in the sense that it may be a lot of work, but no major roadblocks are expected? Or are there open questions that require substantial research?

The state is, "this should be backwards compatible, therefore, we don't need to think about it more until after 1.0." That's pretty much it. There isn't an active discussion, because we're actively discussing the things needed to ship 1.0.

Re: Some notes on Rust

#105

Post by steveklabnik »

steveklabnik wrote: post #92
drbawb wrote: post #71

Earlier quoted context omitted.

The default types for bare literals is described in RFC #212 ( https://github.com/rust-lang/rfcs/pull/212 ) To summarize: bare FP literals default to f64, bare integral literals default to isize. (NOTE: isize is recently renamed from int. It is a pointer-sized integer.) (EDIT: The default for integer literals may be superseded by a later RFC. I seem to recall that the default is actually i32 now, but I can't find a P…

You are right that this changed, but I can't find it in the RFCs either. https://github.com/rust-lang/rust/pull/20189 implemented it. And it is what everyone agreed upon.... hmm

Found it! https://github.com/rust-lang/rfcs/pull/452

Re: Some notes on Rust

#106

Post by amelius »

frou_dh wrote: post #46

> There's a macro called "try!(e)", which, if e returns a None value, returns from the enclosing function via a return you can't see in the source code. Such hidden returns are troubling. Strikes me as simply a very appropriate use of macros. Get tired of writing the same syntactic fragment again and again? Write a macro. Want to see what some macro is "hiding"? Look it up or expand it.

Why aren't exceptions used here?

Is this because the behavior is sort of "exceptional" but not so exceptional that the (supposedly inefficient) exception-mechanism is warranted?

In that case, I think the compiler should handle this case still. Using profiling, it could determine which exceptions are really exceptions and which ones are not.

Re: Some notes on Rust

#107

Post by steveklabnik »

amelius wrote: post #106
frou_dh wrote: post #46

> There's a macro called "try!(e)", which, if e returns a None value, returns from the enclosing function via a return you can't see in the source code. Such hidden returns are troubling. Strikes me as simply a very appropriate use of macros. Get tired of writing the same syntactic fragment again and again? Write a macro. Want to see what some macro is "hiding"? Look it up or expand it.

Why aren't exceptions used here? Is this because the behavior is sort of "exceptional" but not so exceptional that the (supposedly inefficient) exception-mechanism is warranted? In that case, I think the compiler should handle this case still. Using profiling, it could determine which exceptions are really exceptions and which ones are not.

Rust doesn't have exceptions.

Re: Some notes on Rust

#108

Post by mike_hearn »

deathanatos wrote: post #100
ajanuary wrote: post #93

Earlier quoted context omitted.

The issue is it makes it difficult to notice that a function might return when scanning through a function. Especially as it's in places that are looking for a value (e.g. assignment). At the moment it's just return and try!, but people look to the standard library for what is acceptable. When the standard library contains a macro that can return, people will write their own macros that return. It could potentially b…

> The issue is it makes it difficult to notice that a function might return when scanning through a function. What other solutions are there? The only other approach to error handling I've seen is exceptions (e.g., C++, Java, C#, JS…), and if you don't like `try!` because it is a "hidden return", you certainly won't like exceptions. At least with Rust's macros, I know that in the absence of one, there is no return; i…

Kotlin has a notion of function inlining with the return statement being inlined too. This means you can do, e.g.:

list.forEach { if (it == something) return; }

and you aren't returning from the code block, but the enclosing function. Yet behind the scenes forEach is being expanded by the compiler into a regular imperative for loop, in a macro-like way.

Re: Some notes on Rust

#109

Post by amelius »

steveklabnik wrote: post #107
amelius wrote: post #106

Earlier quoted context omitted.

Why aren't exceptions used here? Is this because the behavior is sort of "exceptional" but not so exceptional that the (supposedly inefficient) exception-mechanism is warranted? In that case, I think the compiler should handle this case still. Using profiling, it could determine which exceptions are really exceptions and which ones are not.

Rust doesn't have exceptions.

Interesting. This is certainly new for me :)

Re: Some notes on Rust

#110

Post by Gurkenmaster »

pcwalton wrote: post #79
falcolas wrote: post #43

Earlier quoted context omitted.

So I should use `return` except when I shouldn't? This is the cognitive overhead problem I'm talking about. The original context of my concern is the instance where the match statement makes up the last statement in the function (frequently the only statement in the function's immediate scope). Since the individual cases are not terminating the function early, to get a value out of a match statement you simply leave…

> This is the cognitive overhead problem I'm talking about. The cognitive overhead of having the value of a function be the last expression in it is incredibly minor; lots of languages have this feature. Even JavaScript and C# have this with their arrow functions. > …is an error. The only time you get an error is if you tried to do something that you couldn't do in C++ at all (returning a value without typing return)…

>The cognitive overhead of having the value of a function be the last expression in it is incredibly minor; lots of languages have this feature.

This can cause performance problems in Coffescript because for loops are also expressions.

Post reply on HN