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

Rust in 2018: easier to use

jvns.ca

Post reply on HN
Print view View original

171–180 of 305 posts

Re: Rust in 2018: easier to use

#171

Post by masoodusmani »

papaf wrote: post #23
StreamBright wrote: post #11

Earlier quoted context omitted.

Depends what is your goal. Learning a language with decent type system? Learning a language with lower level access to operating system features? I would suggest to learn OCaml because it got really popular in 2017 thanks to Facebook & Bloomberg, it has an amazing type system and you can use it to build CLI tools and web pages (Reason/Bucklescript) with an insanely good tooling (utop, jbuilder, merlin) and the commun…

I used OCaml a few years ago and I thought it was an excellent language. Despite being powerful it was really easy to learn. One thing that put me off in the end was that it didn't support native OS threads (I have the same problem with Racket). Has threading support improved over the years?

Are you sure Racket doesn't support native threads? I thought it had something called "places" for that.

Re: Rust in 2018: easier to use

#172

Post by cesarb »

shmerl wrote: post #163

> like – maybe Rust is not for people who are already C++ experts and who are happy with C++? I don’t know! I think Rust is very good for C++ experts. Some key concepts like ownership / RAII and etc. are well known in C++, and they should be easy to understand.

Yeah, people with C++ experience have an advantage when learning Rust, since they're used to these concepts, and the Rust compiler enforces things they already know to be careful with (like not mutating a container while there's a live iterator to it). On the other hand, Rust lacks some things C++ has like being generic over values instead of just over types, so for instance implementing a trait for every fixed-size array of a type is currently AFAIK not possible (the usual solution is to use a macro to manually implement the trait for every size up to 32).

Re: Rust in 2018: easier to use

#173

Post by pjmlp »

chmln wrote: post #158
pjmlp wrote: post #41

Earlier quoted context omitted.

Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.

> Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity There is nothing in Rust that makes it inherently unfit for APIs or the web. To dismiss the entire language is simply lazy. Having GC also doesn't necessarily make one language superior to another. While http ecosystem is still in active development, if there was really a choice between Rust and JS for e.g. writin…

The thing is, the choice isn't between Rust and JavaScript, rather between Rust and a list of other languages.

Having a GC means having easier ergonomics to write data structures and distributed algorithms.

I do like a lot Rust's type system, just the ergonimcs aren't quite there yet.

Re: Rust in 2018: easier to use

#174

Post by pjmlp »

seanmcdirmid wrote: post #159
littlestymaar wrote: post #114

Earlier quoted context omitted.

In that case it's no different from Rust, Rust has a GC option (ref counting). It's limited and opt-in then you still carry the cognitive burden of memory management, you have to think when to use it. But if you need that level of control, you'll need to think about memory anyway. And in my experience, it's way easier to reason about allocations in Rust that it is in Java (automatic type erasure if you want to use ge…

UWP has ref counting, garbage collection (via C#), and stack allocation. It does native compilation to boot, unfortunately it isn’t quite universal.

And is built on an improved COM, thus requiring first class support for it, by any language targeting UWP.

Re: Rust in 2018: easier to use

#175

Post by shmerl »

cesarb wrote: post #172
shmerl wrote: post #163

> like – maybe Rust is not for people who are already C++ experts and who are happy with C++? I don’t know! I think Rust is very good for C++ experts. Some key concepts like ownership / RAII and etc. are well known in C++, and they should be easy to understand.

Yeah, people with C++ experience have an advantage when learning Rust, since they're used to these concepts, and the Rust compiler enforces things they already know to be careful with (like not mutating a container while there's a live iterator to it). On the other hand, Rust lacks some things C++ has like being generic over values instead of just over types, so for instance implementing a trait for every fixed-size…

Sure, there are differences as well, and there is no point in always mimicking C++ approaches in Rust 1:1. But I think overall, coming from C++ to Rust should be one of the easiest transitions.

Re: Rust in 2018: easier to use

#176

Post by StreamBright »

xfer wrote: post #145
StreamBright wrote: post #126

Earlier quoted context omitted.

Hyper is not good enough Tokio is WIP.

You do realize hyper depends on the tokio/future framework?

https://github.com/tokio-rs/tokio

A work-in-progress rearchitecting of the tokio-core crate in line with tokio-rs/tokio-rfcs#3

Re: Rust in 2018: easier to use

#177

Post by kazagistar »

yen223 wrote: 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 would like to see a different GC rust... an ability to integrate into an external GC system that it is embedded in, like Javascript or Java or whatever else. In other words, `Gc` would mean "owned by the other runtime". I think there was a proposal like this, though I am not sure what happened to it.

Re: Rust in 2018: easier to use

#178

Post by seanmcdirmid »

pjmlp wrote: post #174
seanmcdirmid wrote: post #159

Earlier quoted context omitted.

UWP has ref counting, garbage collection (via C#), and stack allocation. It does native compilation to boot, unfortunately it isn’t quite universal.

And is built on an improved COM, thus requiring first class support for it, by any language targeting UWP.

Ya, that’s right. But I think this is only C++ and C# at the moment.

Re: Rust in 2018: easier to use

#179

Post by rcthompson »

stevedonovan wrote: post #5

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…

I've seen at least a few articles to the effect of "I wrote the code I wanted, then kept running rustc and changing whatever it told me to until it finally compiled, and it worked."

Re: Rust in 2018: easier to use

#180

Post by quotemstr »

red75prime wrote: post #101
jefftime wrote: post #42

Earlier quoted context omitted.

I tried exploring no_std Rust recently, and found it to be quite frustrating. After just using a Result type I was getting errors of things like `eh_unwind_resume` being undefined. Toggling LTO rectified my problems but didn't give me much confidence in reliably using no_std

`-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.
Post reply on HN