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

71–80 of 113 posts

Re: Some notes on Rust

#71

Post by drbawb »

falcolas wrote: post #62
pcwalton wrote: post #12

Earlier quoted context omitted.

> Except where they can't, and those locations aren't terribly consistent. Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute). > The Rust designers have publicly announced their preference…

> Why aren't they consistent? So, I went back to do a bit of research, and it's gotten better since this first bothered me, my apologies. My beef was with the `let x = vet::Vector::New:: ()` vs `let x: Vec = vec::Vec::New()`. Perhaps not the best way to word it, so consider this objection retracted. :) > the idea that we intentionally made the type inference less powerful than it could have been is totally false Exce…

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 PR to back up that claim.)

So you could easily get a Vec3 like so:

    let mut s = Vec3 { x: 0.0,  y: 0.0, z: 0.0, w: 0.0 };
    let mut t = Vec3 { x: 0f64, y: 0.0, z: 0.0, w: 0.0 };
The key here is that integral literals and floating point literals are distinct.

A bare literal of the form `0` is an unconstrained integral literal.

Whereas a literal of the form `0.0` or `.0` is an unconstrained float literal.

In practice it is very rare for me to annotate my numeric literals. If the variable escapes the stack frame it will be constrained by the signature of the function anyways. If not I constrain the type inline (`let x: T = ...`) and use the appropriate bare literals.

Re: Some notes on Rust

#72

Post by solipsism »

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…

Although as a long-time C++ programmer I'm the first to criticize it when it deserves it, that's a pretty assholish thing to suggest. As if we needed more decisions being made by fear instead of logic around that time.

Re: Some notes on Rust

#73

Post by MichaelGG »

Animats wrote: post #58

Wow. I wrote that article on LtU last night, after going over there to see what the language theorists were saying about Rust. (And after, for the third time in three weeks, having my Rust code fail to compile because the Rust crowd changed the language again, after the "alpha release" and its claims of stability: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html ) I wasn't expecting it to be picked up on Hacker…

Not easier than C++? I dunno, C++ looks like a clusterfuck of complicatedness. I'm mostly coming from F#, with some C. Rust's ownership system just makes sense and seems to perfectly answer the questions I have when using C APIs. Rust, for me, looks a lot like what I've wanted when writing performance F#. I'd commit atrocities to have optional ownership in F#.

Every time I've fought with the borrow checker, it's because I've had a serious design or conceptual flaw. (Well, apart from syntax/compiler questions). Since you can derive most of the rules just by thinking about it, I find it grows on you quickly. I'll be very saddened if the borrow checker actually ends up being hurtful for adoption overall. Though I agree if you cannot handle pointers or think about memory, Rust will be difficult. So yeah, scripting only devs will have trouble. But! It's better than them writing the code in C.

Rust overall seems like that. There's less random stuff and things work mostly by thinking about safe, zero overhead abstractions, and what falls out from those mandates. Mostly.

Now, maybe if I was a modern C++ programmer, I'd find the effort about the same. OTOH, C++ systems don't end up as safe as Rust ones, so I'm not sure there's a perfect comparison to be had. Maybe that'll change as C++ has started catching up feature wise, but someone I doubt it.

Re: Some notes on Rust

#74

Post by MichaelGG »

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…

> memory safety constituted material support of terrorism.

I love this. Not the terrorism charge per-se, but the general idea. Using unsafe code should be shunned, in general. After Rust 1.0 or so, any new C projects, especially for people not heavily invested in C, should be met with questioning.

I'm looking at this one project, mostly PHP. But they need some socket and packet handling, and they wrote it in C. Complete with lines like:

  thing = malloc(somesize); // gets memory
  ...
  free(thing); // give memory back
And network-connected string parsing galore. Or a million line project, used in many networks, compete with its own hacked up XML processor, that has never issued a security advisory. I'm looking forward to a time when the choice to use C here would be questioned and viewed with a doubtful eye by everyone.

Propaganda similar to "loose lips sink ships", aimed at memory unsafe code, might help achieve that goal.

Re: Some notes on Rust

#75

Post by jml7c5 »

hurin wrote: post #70

I tried to learn a bit of rust and I couldn't shake the feeling that rust is a very ugly language, like uglier than c ugly.

What makes you say this? And what is your prior language experience?

Re: Some notes on Rust

#76

Post by [deleted] »

Animats wrote: post #58

Wow. I wrote that article on LtU last night, after going over there to see what the language theorists were saying about Rust. (And after, for the third time in three weeks, having my Rust code fail to compile because the Rust crowd changed the language again, after the "alpha release" and its claims of stability: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html ) I wasn't expecting it to be picked up on Hacker…

[deleted]

Re: Some notes on Rust

#77

Post by dmix »

hurin wrote: post #70

I tried to learn a bit of rust and I couldn't shake the feeling that rust is a very ugly language, like uglier than c ugly.

People said this about Clojure and I never fully understood why. I've dabbled in Rust and while I've always loved Ruby for it's aesthetic I never had a problem with Rust. It suits the language. Feels like you're writing serious code in a serious language. Which is appropriate.

Re: Some notes on Rust

#78

Post by jeorgun »

stebalien wrote: post #6

I don't have an account there so I'll comment here: > In particular, allocating a new object and returning a reference to it it from a function is common in C++ but difficult in Rust, because the function doing the allocation doesn't know the expected lifetime of what it returns. This is what boxes are for. A Box is a unique pointer to a value on the heap and can be used without knowing compile-time lifetimes. Refere…

>Unlike C++, 1. Macros from one crate aren't imported into another unless > the user explicitly requests that they be. 2. Macro invocations are > clearly macro invocations. You never have to wonder if something is a > function or a macro.

Given the reference to Boost, the author is almost certainly talking about template metaprogramming, not C macros. TMP is obviously a lot more limited in scope than Rust macros, but it could hardly be called dangerous; I doubt anyone's ever invoked it by accident.

Re: Some notes on Rust

#79

Post by pcwalton »

falcolas wrote: post #43
burntsushi wrote: post #35

Earlier quoted context omitted.

Yes. Which is what I said. "Using a `return` as the last line of a function works" is not the same as "don't use explicit returns."

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). I don't see how that would confuse C++ programmers. C++ programmers who write Rust using explicit returns everywhere will have their programs work exactly as they expect.

Re: Some notes on Rust

#80

Post by Animats »

jml7c5 wrote: post #75
hurin wrote: post #70

I tried to learn a bit of rust and I couldn't shake the feeling that rust is a very ugly language, like uglier than c ugly.

What makes you say this? And what is your prior language experience?

I tried to learn a bit of rust and I couldn't shake the feeling that rust is a very ugly language, like uglier than c ugly.

What makes you say this? And what is your prior language experience?

Right there is the problem. There are many programmers for whom it's their day job. Others depend on their code doing something useful and important. But they're not theoreticians, don't have advanced degrees in CS, and haven't written in a dozen languages. A new language has to be usable by them to get traction.

The Rust community, at this point, is mostly people who know several programming languages and want to try a new one. Look at the comments above from people who compare type systems in different languages and are aware of the strengths and weaknesses of different approaches. Note the references to obscure languages and research papers most programmers have never heard of, let alone used or read. This is not the target market for a new language, if it is to be a success. It has to be used by people who don't debate language theory issues while the Super Bowl is on.

Post reply on HN