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

91–100 of 248 posts

Re: The Road to Rust 1.0

#91

Post by dragonwriter »

MichaelGG wrote: post #62
pestaa wrote: post #17

Earlier quoted context omitted.

Fully typed function signatures form a kind of contract you can program against. Haskell and other extremely strongly typed languages can infer the types of function parameters, yet the community still agrees it is good practice to annotate your work.

Would Haskell be better off if the compiler enforced this community agreement, instead of letting users decide? Also, the type annotations can be added on later. While you work and play with ideas, leave everything unannotated. After it's cemented and perhaps refactored a bit, add the "contract". In Rust, even while working things out, the user has to figure out and jot down the types.

Haskell compilers can, and its probably better for production code to have them do it.

OTOH, it can be better for exploratory coding in some circusmtances not to. (For one thing, it can be a tool to find cases where you accidentally write something that is more general than the types you were thinking of, but perfectly valid for the more general type -- which, at least as someone fairly new to Haskell, I find myself doing a lot.)

Re: The Road to Rust 1.0

#92

Post by dbaupp »

JoshTriplett wrote: post #8

I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…

As others have said, having a package management system that deeply understands the language and tooling is awesome. Examples:

- Rust has a distributed-by-default documentation generator (rustdoc), cargo knows this and provides `cargo doc` to render a library's docs with it.

- rustdoc can run code examples in the documentation as tests, to check that everything is up-to-date, `cargo test` does this (along with running the in-source unit tests and any external tests).

- the Rust compiler allows for plugins, which are dynamic libraries loaded into the compiler and can be used for things like custom macros (aka procedural macros aka syntax extensions) and custom compiler warnings. cargo understands these, allows them to be 'imported' via the normal dependency mechanism, and specifying `plugin = true` in a package makes cargo do the right thing, e.g. building as a dynamic library (static libraries are the default) and compiling for the correct target when cross-compiling.

I'm sure all of this is possible with other systems, but it seems unlikely to be so nice to use.

Re: The Road to Rust 1.0

#93

Post by [deleted] »

steveklabnik wrote: post #59
adrusi wrote: post #56

Earlier quoted context omitted.

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 was brought up during the discussion that led to Cargo, but no Windows support is a deal breaker.

[deleted]

Re: The Road to Rust 1.0

#94

Post by jroesch »

steveklabnik wrote: post #86
spott wrote: post #74

Earlier quoted context omitted.

There isn't an RFC for them, at least that I could find. Have they just not gotten that far in terms of thought?

That's right, there hasn't even been enough work for an RFC.

I think one of the core challenges is how traits play with HKTs. You can only allow for the defining of HKed type parameters and type arguments so many ways, but it becomes more complicated when dealing with the resolution of traits around HKTs. In Haskell for ex. there is no `Self` so the type class can easily be dispatched on a higher kinded type without needing a receiver type. In Rust `Self` must currently be fully applied as it is resolved from a value directly: `value.trait_method` and we pick our instance based on value's type. If we want to implement Functor (Mappable or w/e) we need to come up with another approach. I've thought about a few but they seem to play best with multi-dispatch + associated types + where clauses. I'm hoping to finish the RFC once all these features land and I can actually hack a prototype, instead of scribbling on paper.

Re: The Road to Rust 1.0

#95

Post by pjmlp »

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.

It seems to be only for GNU/Linux systems, what about all other OSs out there?

Re: The Road to Rust 1.0

#96

Post by djur »

wycats wrote: post #44
steveklabnik wrote: post #27

Earlier quoted context omitted.

> Especially the possibility for Rust code to be called from foreign languages such as C very easily. The second production deployment of Rust is a Ruby gem, written in C, that calls out to Rust. It's used in skylight.io, if you're curious. > BTW is there an RFC on dynamically sized types? IIRC, DST was before the RFC process even existed, it's just taken forever to implement. The Duke Nukem Forever of Rust. :) http:…

> The second production deployment of Rust is a Ruby gem, written in C, that calls out to Rust. It's used in skylight.io, if you're curious. Yep! I'm one of the authors of that project. The fact that Rust provides automatic memory cleanup and the attendant safety without runtime overhead (even ARC has non-trivial runtime overhead) was a huge win for us, as was the transparent FFI. We were looking for a way to write f…

Are there any open source libraries spun off from the Skylight agent? It would be nice to see some examples of production-quality Rust code.

Re: The Road to Rust 1.0

#97

Post by dbaupp »

ranran876 wrote: post #65
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

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 fighting the compiler, but a lot less time fighting the debugger and a lot less time trying to reproduce heisenbugs caused by data races/undefined behaviour.

Of course, the library/tool support is indisputably in C++'s favour.

> if you're an idiot you can shoot yourself in the face

If you're a human you will shoot yourself in the face. It just takes far too much brain power to write correct C++ always (a single mistake leads to brokenness), especially in a team where there can be implicit knowledge about how an API works/should work that may not be correctly transferred between people.

Re: The Road to Rust 1.0

#98

Post by djur »

DennisP wrote: post #88
smacktoward wrote: post #35

Earlier quoted context omitted.

The other justification is generally a clash of cultures: the people who maintain distro/OS package managers generally come out of the culture of sysadmins, who value stability over feature-richness, while the people working the language communities generally come out of the culture of developers, whose priorities are the exact opposite. When languages try to hook into existing OS-level systems, the people on the lan…

Maybe OS-level package managers should default to stable, but let the user check a box to get the latest and greatest. Developers want a stable system like everyone else, but for the stuff we're hacking on, we have a legitimate need to get the most recent, so our software isn't obsolete by the time we finish it.

Most OS-level package managers also aren't designed to install more than one version of a package at a time. They don't tend to integrate with build systems as well, either.

Re: The Road to Rust 1.0

#99

Post by alelefant »

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…

I've never built a Rails app, so perhaps there's something simple that I'm missing (I'm mostly a C# guy), but how would I use Skylight to monitor my on-premise application? The pricing makes it seems like a hosted service. I would have expected some sort of profiler to be needed on the server and then perhaps a centralized location for the data to be pushed to for display.

The design of the site is great and I'm mostly curious because it sounds like something I wish was available in the .NET world!

Re: The Road to Rust 1.0

#100

Post by burntsushi »

austinz wrote: post #68

Congratulations to the Rust team! Can't wait to start learning the language and building stuff using it. I'm looking to learn about how Rust's refcounting memory management works (and how it differs from how, e.g. Objective-C or Swift's runtime-based reference counting works), mostly for personal edification. Can anyone point me to any good resources?

Steve already told you that refcounting isn't reached for by default, and I wanted to share an anecdote to emphasize that.

I've written a regex library, CSV parser, command line arg parser, elastic tabs and quickcheck in Rust. Behold:

    $ find ./ -type f -name '*.rs' -print0 | xargs -0 grep Rc
    $
I've definitely reached for it a few times as an escape hatch, but I've always ended up finding a cleaner approach to persist without it.

Of course, there are plenty of legitimate uses of refcounting. I just haven't hit them yet. :-)

Post reply on HN