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

A 30 minute introduction to Rust

words.steveklabnik.com

Post reply on HN
Print view View original

101–110 of 161 posts

Re: A 30 minute introduction to Rust

#101

Post by masklinn »

pjmlp wrote: post #78
masklinn wrote: post #71

Earlier quoted context omitted.

Sure but if a GC'd language is acceptable for the application, the problem "was solved" years ago, the tooling not being the issue anymore.

The main issue with that, is that although there are lots of GC enabled languages to choose from, not all of them have mainstream AOT compilers available. Shipping a VM with the product is not always possible/desireable.

Even with that constraint, OCaml's 15 years old, so's SML/MLTon, D's 12 years old (D2 is 6 years old), Eiffel's nearly 30 (and moved under ECMA in 2005), Common Lisp can be compiled to native via CMUCL, SBCL or CCL and Scheme via Chicken Scheme or Chez Scheme.

And these are off the top of my head, I'm sure there are others.

Re: A 30 minute introduction to Rust

#102

Post by steveklabnik »

bsaul wrote: post #100

Is rust borrowing any kind of code from what is used for objective C ARC technology relative to detecting the lifetime of a variable and automaticaly freeing the resource ? Is it a common known algorithm ?

Everything is written in Rust, so we're not borrowing the code.

Reference counting is very common: http://en.wikipedia.org/wiki/Reference_counting

Re: A 30 minute introduction to Rust

#103

Post by kps »

steveklabnik wrote: post #53
samth wrote: post #43

I think the emphasis on "unsafe" isn't helpful. As far as I can tell, the only thing that "unsafe" is enabling is that Arc and RWArc are written in Rust rather than in C in the runtime (the way they'd be in Go, or Erlang, or Haskell). The things that make Rust able to do what it does are ownership and tasks and lifetimes and affine types -- all the things the post covers before talking about "unsafe". Also, it gives…

> Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use. Right, this is my point. I should find a way to make it a bit more clear. I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. After all, there's a reason you want that low-level control in the first…

I think that's a necessary approach. The first time I encountered Rust, in a treatment that covered unique and managed but not unsafe/raw pointers, my impression was: ‘You promised GC was optional, but I can't even write a DAG’.

Re: A 30 minute introduction to Rust

#104

Post by acqq »

"Rust does not have the concept of null."

How can I have the pointer to something that is maybe allocated or maybe present? Do I have to have additional booleans for such uses? Isn't that a waste?

How can I effectively build complex data structures like graphs, tries etc then?

I'd like to see that covered too.

Re: A 30 minute introduction to Rust

#105

Post by stusmall »

Jhsto wrote: post #86
stusmall wrote: post #76

Earlier quoted context omitted.

Sometimes these applications are written in C for the extreme portability rather than performance. I have a couple open source projects in mind that support a huge selection of OSes and hardware configurations that would not be possible with some of the other current higher level language but almost every platform supports C to some degree. I don't know how well Go supports weird configurations like MMU-less uClinux…

I don't really understand concepts of low level languages, but I've had a perception that if I'd wrote a program in Go using the standard libary and compiled it with go build it would run on all imaginable platforms. Now, as far as I've understood your comment suggests that I'm wrong. Lets suppose that some corporation would download the binaries of my project and use it on an embedded system, would it run?

It depends on how "embedded" embedded means to you. I've talked to some people who call a CPE Linux/Atom box embedded and I know some people who don't consider anything with an OS embedded. I won't even touch that argument. :)

But I used MMU-less uClinux as an example because it breaks a lot of assumptions that are made in a lot of code. No dynamic linking(which if I remember go doesn't support by default, or does it even support at all? I haven't written any in a year or two), no protected memory, and no real fork (vfork instead) crosses a lot of code off the list on what you can run. I don't know if go can support it, but I know that the current offical toolchains don't. There may be a feature go has that prevents them running on a platform like this, but it won't be GC. There are some GC'd languages that will run on this platform.

C is great in that is makes very few assumptions and if written carefully can be extremely portable. The base language doesn't even assume there is an OS present. I've only run into one platform that had very little C support. It was a small 8 bit uC that had a very strange execution stack that made C as everyone uses it hard to efficiently implement.

Re: A 30 minute introduction to Rust

#106

Post by samth »

steveklabnik wrote: post #53
samth wrote: post #43

I think the emphasis on "unsafe" isn't helpful. As far as I can tell, the only thing that "unsafe" is enabling is that Arc and RWArc are written in Rust rather than in C in the runtime (the way they'd be in Go, or Erlang, or Haskell). The things that make Rust able to do what it does are ownership and tasks and lifetimes and affine types -- all the things the post covers before talking about "unsafe". Also, it gives…

> Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use. Right, this is my point. I should find a way to make it a bit more clear. I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. After all, there's a reason you want that low-level control in the first…

> I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best.

Well, the best way to combat that would be demonstrate that cool things can be done safely in Rust, but that probably requires a lot more than fits in your introduction.

I think you could allay that fear by addressing it directly, rather than saying that Rust's secret sauce is unsafety.

Re: A 30 minute introduction to Rust

#107

Post by kibwen »

acqq wrote: post #104

"Rust does not have the concept of null." How can I have the pointer to something that is maybe allocated or maybe present? Do I have to have additional booleans for such uses? Isn't that a waste? How can I effectively build complex data structures like graphs, tries etc then? I'd like to see that covered too.

Rust uses the `Option` type for that (name taken from Scala and ML, it's called `Maybe` in Haskell).

http://static.rust-lang.org/doc/master/std/option/index.html

What's neat is that if you stuff a pointer inside an `Option`, then not only is it guaranteed to be memory-safe but it also compiles down to a plain old nullable pointer at runtime, so there's no extra overhead while still retaining safety.

Re: A 30 minute introduction to Rust

#108

Post by Aloisius »

noelwelsh wrote: post #84

The focus on C++ as point of comparison is understandable given Mozilla's background, but in Internet land most systems software runs on the JVM, and is written in Java, or increasingly, Scala (see LinkedIn and Twitter, for example). The issues of memory layout and the like come up here, and unlike Rust the JVM doesn't give much control of this aspect. See Martin Thompson's blog for an example of someone very concern…

but in Internet land most systems software runs on the JVM, and is written in Java

[[Citation needed]].

The Internet land I've lived in mostly lives in C with a smattering of non-JVM scripting languages (Python, Ruby, PHP, etc) on top.

Re: A 30 minute introduction to Rust

#109

Post by dbaupp »

steveklabnik wrote: post #28
ash wrote: post #24

Earlier quoted context omitted.

I still don't get it... And the previous sentence is now confusing for me too :) First you showed two examples: Arc (to share immutable data) and RWArc (to share mutable data with enforced mutexes around closures). Then you talked about `unsafe`. Seems easy, one needs a "backdoor" to implement RWArc in Rust (at first I thought it was implemented in C/C++). But (quoted) sentences between Arc/RWArc part and `unsafe` pa…

Ha! Bummer, maybe I will just need to re-write this paragraph. A RWArc is shared mutable state: you can have two references to the Arc in two different tasks. Yet I said that Rust throws a compiler error for shared mutable state. > (at first I thought it was implemented in C/C++). There's very little C++ in Rust anymore. :) > Seems easy, one needs a "backdoor" to implement RWArc in Rust Yup, this is exactly the point…

> There's very little C++ in Rust anymore.

I think we've now got none, except for LLVM in the compiler, which means any binaries built using the stdlib don't need any C++ libraries (to be clear, libraries without the stdlib have never needed any).

Re: A 30 minute introduction to Rust

#110

Post by [deleted] »

alexk7 wrote: post #83
pcwalton wrote: post #37

Earlier quoted context omitted.

> In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes. Those aren't safe. There are many ways to cause use-after-free with unique_ptr: for example, placing a uniquely-owned object in a vector and clearing the vector in a method call on that object.

What's wrong with this use-case? The object will be destroyed and no pointer to it will exist after the clear.

[deleted]
Post reply on HN