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

The Road to Rust 1.0

blog.rust-lang.org

Post reply on HN
Print view View original

121–130 of 248 posts

Re: The Road to Rust 1.0

#121

Post by hit8run »

tomdale wrote: post #53

We've been using Rust in production for Skylight ( https://www.skylight.io ) for many months now, and we've been very happy with it. Being one of the first to deploy a new programming language into production is scary, and keeping up with the rapid changes was painful at times, but I'm extremely impressed with the Rust team's dedication to simplifying the language. It's much easier to pick up today than it was 6 mont…

Hey Tom, did you also consider googles golang? Currently I'm building my backends with golang and I am pretty satisfied with the performance and the whole flow. Maybe it is sometimes a bit cumbersome to check on errors like a paranoid but in the long term it helps to predict what happens in error cases. How about rust? Is the workflow comparable to golang? Is there an equivalent to gofmt and some ide support for code completion? Thx and regards Bijan

Re: The Road to Rust 1.0

#122

Post by burntsushi »

MichaelGG wrote: post #116
burntsushi wrote: post #89

Earlier quoted context omitted.

Rust will do type inference on lambdas for you. :-) fn fubar(x: uint) { let times = |n| x * n; println!("{} * 5 = {}", x, times(5)); } Rust only enforces type annotations on top-level functions. > Does the compiler gain a large benefit from not having to include this feature? Who loses by allowing users to do what they want? FWIW, I feel precisely the opposite as you. I'd rather have an ecosystem of code where top le…

Oh if nested functions don't need annotation, then I suppose that saves most of the problem. Can top-level definitions be of the lambda form? If not, what's the reason to have separate ways?

There are `fn` types---which are just function pointers---and there are `||` types, which are closures that correspond to a pointer to a function and an environment.

You can actually define `fn`'s within other `fn`'s, but their types are not inferred. Closures cannot be defined at the top level, presumably because there is no global environment to capture. (Rust does have global "static" constants, though, which are available everywhere in the enclosing module I think.)

I can probably hazard a few guesses at why there is a split here (probably relating to lifetimes), but I don't know for sure. Perhaps someone else will chime in.

Re: The Road to Rust 1.0

#123

Post by pmahoney »

steveklabnik wrote: post #83
pmahoney wrote: post #77

Earlier quoted context omitted.

I would probably make the same decision, but I hope in the end Caro is easy to wrap with Nix, which is a breath of fresh air particularly when needing to mix dependencies that cross language boundaries and share those build recipes with a team. Previously, I wrote shell scripts and worried whether everyone on the team had rsync installed, or xmlstarlet, or some other less common tool. Now I wrap those scripts in a Ni…

Cargo has the second, and there's a plan for the first. That said, the reason that you want it to do the installation is that a lockfile is supposed to represent the way to do a build successfully. Without building everything, you can't actually be sure that the lockfile is correct. In theory, it should be...

> reason that you want it to do the installation is that a lockfile is supposed to represent the way to do a build successfully

Sure, and I'd like to do that build within Nix (and someone else might want to do it with another packager), which gives a stronger guarantee than Bundler since it incorporates C library dependencies and more. Anyway, the specifics aren't relevant to this discussion, and it seems you have a grasp of the issues, so carry on!

Re: The Road to Rust 1.0

#124

Post by BruceIV »

hadoukenio wrote: post #43

Still sitting on the fence as to which language I should pick up on next - the only contenders are C++11 and Rust. How does Rust compare with C++11 as a language? C++11 seems to (in some ways) have caught up with what Rust has to offer (compared to older C++ versions) e.g. smart pointers, concurrency and regexes part of the standard library

C++11 is still C++ though. I've been writing pretty much exclusively C++11 for the last year, and, while they've added a lot of very nice features and I find it painful to go back to C++03, it's still a huge language with lots of hoary edge cases and everything and the kitchen sink built in (now with rvalue reference and move semantics for extra verbosity!).

I haven't touched Rust since 0.7 (where I abandoned it after filing two bugs on the project before I even got argument parsing working), but it's the most promising of the new batch of languages in my mind, and I have some side projects in mind I'd like to try when 1.0 comes out.

Re: The Road to Rust 1.0

#125

Post by shadowmint »

hit8run wrote: post #121
tomdale wrote: post #53

We've been using Rust in production for Skylight ( https://www.skylight.io ) for many months now, and we've been very happy with it. Being one of the first to deploy a new programming language into production is scary, and keeping up with the rapid changes was painful at times, but I'm extremely impressed with the Rust team's dedication to simplifying the language. It's much easier to pick up today than it was 6 mont…

Hey Tom, did you also consider googles golang? Currently I'm building my backends with golang and I am pretty satisfied with the performance and the whole flow. Maybe it is sometimes a bit cumbersome to check on errors like a paranoid but in the long term it helps to predict what happens in error cases. How about rust? Is the workflow comparable to golang? Is there an equivalent to gofmt and some ide support for code…

There are some work-in-progress code completion tools https://github.com/phildawes/racer).

No format tool yet, but its often talked about and Id be surprised if it doesnt happen.

The biggest infrastructure difference to go at the moment is that its tricky to cross compile binaries in rust.

Re: The Road to Rust 1.0

#126

Post by dbaupp »

hit8run wrote: post #121
tomdale wrote: post #53

We've been using Rust in production for Skylight ( https://www.skylight.io ) for many months now, and we've been very happy with it. Being one of the first to deploy a new programming language into production is scary, and keeping up with the rapid changes was painful at times, but I'm extremely impressed with the Rust team's dedication to simplifying the language. It's much easier to pick up today than it was 6 mont…

Hey Tom, did you also consider googles golang? Currently I'm building my backends with golang and I am pretty satisfied with the performance and the whole flow. Maybe it is sometimes a bit cumbersome to check on errors like a paranoid but in the long term it helps to predict what happens in error cases. How about rust? Is the workflow comparable to golang? Is there an equivalent to gofmt and some ide support for code…

I don't speak for tomdale/wycats, but embedding a language with a GC (Go) inside another GC'd language (Ruby) only leads to worlds of pain, especially when trying to efficiently transfer data between them.

In languages without compulsory GCs (like Rust, which doesn't have one at all) this works because it's easy to have complete control about when memory is freed, but a GC'd language may free memory that was passed back into Ruby since the GC can no longer find any references to it.

I'm sure there's ways around this (e.g. using unsafe/raw pointers), but this control is the default in Rust, and there are a pile of language mechanisms (ownership, in particular) that make making this safe much easier.

(Also, AIUI, Go's FFI story is relatively inefficient, and, has some rather bad bugs; apparently https://code.google.com/p/go/issues/detail?id=7978 is the Go GC trying to free FFI memory.)

Re: The Road to Rust 1.0

#127

Post by pbsd »

dbaupp wrote: post #97
ranran876 wrote: post #65

Earlier quoted context omitted.

I'd definitely pick C++11 unless you need to use Rust. Rust is inherently memory safe - however in practical terms this isn't important for most applications. If you are writing security critical applications Rust will provide you with some very important guarantees (ie. there are certain mistakes which are inherently not possible in the language). C++ doesn't really guarantee anything and if you're an idiot you can…

There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time figh…

Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy.

On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return?

    pub fn f(x: uint) -> uint { x >> 32 }
Honestly, I loved the idea of Rust. I was sold a memory-safe C++, and that sounded awesome. But what I got instead was an ML with better low-level support; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language.

Re: The Road to Rust 1.0

#128

Post by dbaupp »

pbsd wrote: post #127
dbaupp wrote: post #97

Earlier quoted context omitted.

There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time figh…

Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) ->…

Overlong shifts are currently not handled correctly, yes, but they will not be undefined behaviour; they will possibly be implementation-defined but will not lead to memory unsafety.

> use-after-move [...] ---references outlasting their owner---

Not really, e.g.

  std::unique_ptr x(1);
  foo(std::move(x));
  std::cout
Unless you mean something other than `&` references.

> Honestly, I loved the idea of Rust. I was sold a memory-safe C++, and that sounded awesome. But what I got instead was an ML with some low-level extensions; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language.

Something in this sentence has to be wrong, since people are clearly interested in Rust: either people are interested in YAFL or Rust isn't what you seem to think it is.

Anyway, that just sounds like a 'problem' with your background/expectations and/or whoever sold it to you. Rust is a C++ competitor (i.e. targets the similar low-level space) but it is not definitely trying to just be a C++ rewrite fixing the holes. I don't think there's any official marketing implying the latter.

Re: The Road to Rust 1.0

#129

Post by CMCDragonkai »

adrusi wrote: post #56
pjmlp wrote: post #49

Earlier quoted context omitted.

> Disappointing to see yet another language-specific package management system (Cargo), though So what is the solution to have portable packages for: - RPM systems - Debian systems - tarball systems - Pkg systems - MSI systems - Mainframe OS - Embedded OS - Aix/HP-UX/Solaris package systems - ...

The goal of the [nix]( http://nixos.org/ ) project is to solve this, and every time anyone brings up a package manager on HN, someone has to mention nix. The reality is that nix is really nice, but isn't any better than making a new package manager until it has wide adoption, so no one is using it.

Nix is much more than just a package manager though.

Re: The Road to Rust 1.0

#130

Post by bjz_ »

pbsd wrote: post #127
dbaupp wrote: post #97

Earlier quoted context omitted.

There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time figh…

Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) ->…

> But what I got instead was an ML with some low-level extensions; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language.

Rust is not functional. It may draw heavy inspiration from statically typed FP, and closures, ADTs, pattern matching, and and expression-heavy programming style might give that impression, but it is at its heart a procedural systems language. As stated in the blog post, most of Rust's core features map directly to underlying machine instructions, and there is always the opportunity to cede control from the type system if you absolutely have to. Indeed, core library types like `Box` and `Vec` are at their fundamentally built on `unsafe` code.

Post reply on HN