Live data from Hacker News

Rust in 2018: easier to use

jvns.ca

221–230 of 305 posts

Re: Rust in 2018: easier to use

#221

Earlier quoted context omitted.

This sounds like Swift :) (ARC, not tracing GC, but still.)

If Arc counts, then it juste sounds like Rust actually ;).

Small note: Swift's ARC and Rust's Arc are different: Rust's Arc is atomic reference counting, while Swift's is automatic reference counting.

Re: Rust in 2018: easier to use

#222

The error messages are indeed _mostly_ marvelous (and there's an ongoing effort to make them even more marvelous). Often working with `rustc` feels like pair programming for introverts. But here's a question: `rustc` often gives _actionable_ advice - how far can can you get just following that advice? You can make `rustc` happy by following suggestions, but may end up puzzled as to the reasons for the changes it sugg…

https://github.com/killercup/rustfix is an experiment in exactly this.

Re: Rust in 2018: easier to use

#223
post #12

This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus on performance, and great tooling (cargo + rustup = OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.

I have a similar desire. OCaml and others push heap-allocated reference types by default (limiting your options for controlling allocations), and many have weak tooling and library support. F# looks neat, but it seems to have a lot of baggage relating to C# interop. F# also doesn't compile static binaries yet. I think I decided the best shot is to build a language that compiles to Go, since it has the right semantics, great libraries and tooling, and a world-class runtime (GC, painless async IO, lightweight thread scheduler for real parallelism). Obviously this is still a huge effort and probably a pipe dream, but its the path of least resistance to get a "Rust with GC".

Re: Rust in 2018: easier to use

#224
post #189

Earlier quoted context omitted.

Except that number is completely made up. Why do believe it takes ten times as long?

What Rust framework replace Java spring or equivalent, none of them so you have to write everything yourself. Rust doesn't have any ecosystem to write service side services so you're going to spend time by just re implementing a framework.

While Rust doesn't have many full-stack frameworks, many ecosystems don't favor full-stack frameworks. Rust has tons (arguably too many!) microframeworks/libraries.

I do agree that there are holes, and that's part of being a young ecosystem, but I think you're being a bit too pessimistic. I understand this deeply, as I was once too! As things have evolved, my opinions have changed, though.

Re: Rust in 2018: easier to use

#225

Earlier quoted context omitted.

`-C panic=abort` compiler option should have fixed the problem. If you want to be able to intercept panics, you need to provide implementations for `eh_unwind_resume` and `eh_personality`.

For low level code, do you really want to abort on panic? Rust error handling is easily my least favorite part of the language, combining the disadvantages of exceptions and return codes.

Many do, yes. Panics are non-recoverable errors, and aborting produces leaner code, which is important on embedded.

Re: Rust in 2018: easier to use

#226

Earlier quoted context omitted.

Perhaps it's just an issue of me not being educated enough with this kind of low-level Rust. Setting panic to abort in the cargo config did indeed fix `eh_personality` being undefined, but `eh_unwind_resume` still seems finnicky. Building in release will work, but building in debug will still complain

I'm a little rusty on the topic, but it seems ([0]) that adding `#[no_mangle]` before `panic_fmt` should fix it. [0] https://github.com/rust-lang/rust/issues/38281

See also https://doc.rust-lang.org/nightly/unstable-book/language-fea...

Re: Rust in 2018: easier to use

#227
post #148

Earlier quoted context omitted.

Looks like incremental compilation has been enabled in nightly: https://github.com/rust-lang/cargo/pull/4817

That's a welcome improvement from last time I looked at it. Does anyone know a ballpack figure for how many LoC/s you can expect on a beefy workstation?

It really depends. That is, thanks to monormorphization, 1 LOC in your source doesn't necessarily mean 1 LOC compiled by the compiler.

Furthermore, this is the start of incremental: we have more stuff coming down the pipeline.

Re: Rust in 2018: easier to use

#228
post #12

This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus on performance, and great tooling (cargo + rustup = OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.

Yep, that's exactly what I would also like to see. AFAIK there is some work on a GC in Rust, but it doesn't take away the borrow checker like you wished ;) So you will still need to use `.borrow()` and `.borrow_mut()`. A language similar to Rust but with GC (and no borrow checker) could be quite useful for a lot of applications out there. Basically Go but a more "modern" language.

Just seeing this. You might be interested in my previous comment here: https://news.ycombinator.com/item?id=16145940

Re: Rust in 2018: easier to use

#229
post #141
post #138

Earlier quoted context omitted.

Are you really saying that Rob Pike is part of some kind of conspiracy to offshore all the coding that's currently being done at Google SF? Golang has been around for a while now, and there's no sign of that happening.

No, I am just stating that the goals of having the language designed for such target audience, can have that as side effect. Just like it happened with Java.

Your responses to K0nserv and singhrac suggested that you were defending the claim that golang was "designed for" outsourcing.

If you're making the weaker claim that Go's design "can" have the effect of triggering outsourcing, then that's speculative and consequently rather difficult to refute. But you haven't provided a single piece of evidence that this has actually occurred, so far as I can see.

Re: Rust in 2018: easier to use

#230

Earlier quoted context omitted.

You summarized it so well ! It was also a huge source of confusion for me in the beginning. Would you mind if I made a pull request to the Rust book adding your explaination to the lifetime chapter ?

I wouldn't. Feel free to use it. But I have the impression that the Rust book contains something to that effect. "Descriptive and not prescriptive" part probably comes from stackoverflow. I don't remember exactly.

I'm not sure where I heard it, but I certainly repeat it. It's not literally in the book though, I'll also reply to your parent about this.
Post reply on HN