Live data from Hacker News

A 30 minute introduction to Rust

words.steveklabnik.com

81–90 of 161 posts

Re: A 30 minute introduction to Rust

#81

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…

  > I need to write a lot of unsafe code.
To contrast with application-level code, pcwalton has measured that less than 1% of Servo's code is contained within `unsafe` blocks.

Re: A 30 minute introduction to Rust

#82

I like the overall structure, but I'm not sure about throwing so much syntax without explaining it in detail.

I actually liked the amount of detail in explaining the syntax. For the most part, the code samples are very readable and understandable as they are (and I haven't written any Rust).

I think explaining a lot of the syntax would have made this more of a "how to Rust" article, rather than a "why to Rust" article. I really appreciated the "why to Rust" tone of this article, and it provides a great explanation of why the language is different from C / C++ and why I should care.

Re: A 30 minute introduction to Rust

#83
post #33

Earlier quoted context omitted.

I wasn't trying to undermine your argument. Rust is solving real problems. Use after free and double free are still issues in the C world. In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes.

> 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.

Re: A 30 minute introduction to Rust

#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 concerned with issues of performance on the JVM (http://mechanical-sympathy.blogspot.co.uk/) I believe Rust could see a lot of adoption within this community as a "better" Scala -- a modern high-level language that allows dropping down to bit-twiddling when performance is an issue. It needs higher kinded types before it will work for me, but I hear that is on the road-map.

BTW, I've read a few Rust tutorials and they all fail for me in the same way: too much waffle and not enough getting down to the details. I understand the difference between stack allocation, reference counting, and GC, I get why shared mutable state is a bad idea, etc. What I want is a short document laying out the knobs Rust provides (mutable vs immutable, ownership, allocation) and how I can twiddle said knobs.

Re: A 30 minute introduction to Rust

#85
post #80

Earlier quoted context omitted.

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.

Sure, because it was expected that certain features would take a exponentially longer time to develop because many features were not created back then and the market was not as competitive.

If I'm asked to make an image gallery for a GUI you can bet 99% of people will go for an existing solution out of a matter of productivity, and the reality is that even if I was interested in making a gallery of my own or acquiring a deep understanding of how to make a proper piece of code that solves that problem, it is extremely unlikely I could come up with something better in the span of time I've been allocated to solve it.

Similarly, there's not reason to deal with memory management errors unless you cannot avoid it at all costs. None.

This sounds like vinyl DJs complaining that kids nowadays have DJ software that does beat detection and automatic loops n' shit. Sure, but the production value of your average mix has gone up tremendously now that you don't have to spend 30% of your time beat matching and instead you can now add samples and synths.

For the record, I can program in Assembly and I can DJ with vinyl, but it's been years since I've had a necessity to recur to either. At least the vinyl has some aesthetic, subjective vintage value.

Re: A 30 minute introduction to Rust

#86

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.

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?

Re: A 30 minute introduction to Rust

#87

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…

> Really, it's such a pleasure to read some golang after reading this 30 minutes of Rust.

Incidentally, I find reading Go to be much more verbose and even heaver cognitively compared to reading Rust code.

Re: A 30 minute introduction to Rust

#88

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…

I think that's totally true. It's not just so much because of Mozilla, but also because Rust is probably closer to C++ than Java...

The official tutorial contains much of that information.

Re: A 30 minute introduction to Rust

#89

I like the overall structure, but I'm not sure about throwing so much syntax without explaining it in detail.

I actually liked the amount of detail in explaining the syntax. For the most part, the code samples are very readable and understandable as they are (and I haven't written any Rust). I think explaining a lot of the syntax would have made this more of a "how to Rust" article, rather than a "why to Rust" article. I really appreciated the "why to Rust" tone of this article, and it provides a great explanation of why the…

Excellent. Thank you.

It's hard to have a beginner's mindset after you've done something for a year.

Re: A 30 minute introduction to Rust

#90
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…

Salespeople qualify leads by determining if you're ready to buy or not. If you're not, they stop wasting time on you. The general idea for a quick introduction is to qualify your lead. So this isn't a "introduction to Rust's syntax" it's "an introduction to why you should (or should not) care about Rust." > since every competent C/C++ programmer knows not to do it. Everyone knows, yet programs still segfault. The poi…

> I personally have only ever written unsafe when wrapping something with FFI.

Is discussion of unsafe in an introduction article esoterica?

By the way, loved the proposal video [1] you did on docs for rust: it's a pretty solid proposal for any language.

[1] https://air.mozilla.org/rust-meetup-december-2013/

Post reply on HN