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

71–80 of 161 posts

Re: A 30 minute introduction to Rust

#71

Post by masklinn »

pjmlp wrote: post #69
masklinn wrote: post #61

Earlier quoted context omitted.

Go being mandatorily GC'd I don't think it's relevant to the issue of improving on C/C++ for their existing use cases.

There are still lots of user space applications written in C/C++ nowadays, that could be easily rewriten in Go or any other safer language with native code compilers, without noticeble performance lost for the problem being solved.

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.

Re: A 30 minute introduction to Rust

#72

Post by masklinn »

patrickaljord wrote: post #5

Thanks for the the tutorial! Rust seems a bit too complex to me. Like a C++ on steroid that wants to do and be everything. Nothing wrong with that but not my cup of tea. I'd rather stick to C if I need tight memory management, it is way simpler and straight forward. And if I need concurrency, I'll stick to Golang (or erlang). Really, it's such a pleasure to read some golang after reading this 30 minutes of Rust. Anyw…

> Like a C++ on steroid

Rust most definitely isn't "like a C++ on steroid" from a complexity standpoint. It tries (and — I think — mostly succeed) to be a significantly simpler and more coherent language.

It does make things which are implicit in C or C++ (e.g. ownership) explicit. That's a good thing, you need to know your ownership in C or C++, the language just doesn't help you much.

Re: A 30 minute introduction to Rust

#73

Post by steveklabnik »

masklinn wrote: post #68
steveklabnik wrote: post #44

Earlier quoted context omitted.

Absolutely, I don't want people to think I'm attacking a straw man. Maybe a heap allocated example would be better?

Probably, with a slightly tricky ownership issue leading to use after free (a well known source of exploits http://cwe.mitre.org/data/definitions/416.html ) e.g. allocate to the heap, pass to a function which deallocates it (assuming that it has ownership) and use it after the call, e.g. #include #include void destroyer(int* val) { printf("%d\n", *val); free(val); } int main(int argc, char** argv) { int* v = malloc(s…

Thanks so much. I'll certainly have to use this if this makes it to Rust proper.

Re: A 30 minute introduction to Rust

#74

Post by ChuckMcM »

This is an excellent summary Steve, it also points out one of the challenges of 'System' languages, which is the requirement for 'unsafe.'

One of the first things I did when I started working on Oak (which became Java) was to see about writing an OS in it. The idea being that if you could write an OS in a 'safe' language then you could have a more reliable OS. But we were unable to write it completely in Oak/Java and that lead to some interesting discussions about what might be the minimum set of 'unsafe' actions might be required by a systems language.

Sadly we did not get to explore that very much, although I did pass it on as a possible thesis topic to some interns who came through Sun at the time. I'd be interested in your experience with what actions require 'unsafe' and if you have seen a canonical set that might point toward a process to get to a 'safe' OS.

Re: A 30 minute introduction to Rust

#75

Post by kibwen »

ChuckMcM wrote: post #74

This is an excellent summary Steve, it also points out one of the challenges of 'System' languages, which is the requirement for 'unsafe.' One of the first things I did when I started working on Oak (which became Java) was to see about writing an OS in it. The idea being that if you could write an OS in a 'safe' language then you could have a more reliable OS. But we were unable to write it completely in Oak/Java and…

For reference, the following actions are what are enabled within `unsafe` blocks in Rust:

1. Dereferencing raw pointers (a.k.a. "unsafe" pointers). Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

2. Calling a Rust function that has been marked with the entirely-optional `unsafe` keyword.

3. Calling an external function via the C FFI, all of which are automatically considered unsafe.

Re: A 30 minute introduction to Rust

#76

Post by stusmall »

masklinn wrote: post #71
pjmlp wrote: post #69

Earlier quoted context omitted.

There are still lots of user space applications written in C/C++ nowadays, that could be easily rewriten in Go or any other safer language with native code compilers, without noticeble performance lost for the problem being solved.

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.

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 installs but the GC wouldn't be what is breaking it.

Re: A 30 minute introduction to Rust

#77

Post by Daishiman »

pjmlp wrote: post #56
tptacek wrote: post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

> since every competent C/C++ programmer knows not to do it. They are hard to come by, in this time and age, of cutting down costs everywhere while offshoring components.

They have always been hard to come by because not everyone wants to spend 10 years banging their heads against the wall of memory management errors unnecessarily.

Re: A 30 minute introduction to Rust

#78

Post by pjmlp »

masklinn wrote: post #71
pjmlp wrote: post #69

Earlier quoted context omitted.

There are still lots of user space applications written in C/C++ nowadays, that could be easily rewriten in Go or any other safer language with native code compilers, without noticeble performance lost for the problem being solved.

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.

Re: A 30 minute introduction to Rust

#79

Post by steveklabnik »

ChuckMcM wrote: post #74

This is an excellent summary Steve, it also points out one of the challenges of 'System' languages, which is the requirement for 'unsafe.' One of the first things I did when I started working on Oak (which became Java) was to see about writing an OS in it. The idea being that if you could write an OS in a 'safe' language then you could have a more reliable OS. But we were unable to write it completely in Oak/Java and…

Glad you liked it, Chuck.

Some of my closest friends in college specialized in operating systems, and we (mostly them) worked on http://xomb.org , an exokernel in D. I'd hope that today we'd choose Rust instead.

Julia Evans has been writing _fantastic_ series about a kernel in Rust: http://jvns.ca/blog/categories/kernel/

As she says "This is typical of a lot of Rust code I’m writing – I need to write a lot of unsafe code."

I'll have to give this 'minimum set' idea some thought. I think that safety will be more useful for things like kernel modules than in the kernel itself, though I'm not sure why I think that, exactly. Hmmmmm...

Re: A 30 minute introduction to Rust

#80

Post by pjmlp »

Daishiman wrote: post #77
pjmlp wrote: post #56

Earlier quoted context omitted.

> since every competent C/C++ programmer knows not to do it. They are hard to come by, in this time and age, of cutting down costs everywhere while offshoring components.

They have always been hard to come by because not everyone wants to spend 10 years banging their heads against the wall of memory management errors unnecessarily.

When I start coding, GC enabled languages only existed in very expensive workstations in research places like Xerox PARC.

Somehow I have this memory, maybe false, that on those days the developers had better skills than most of the younger developers I met on the last five years.

Post reply on HN