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

11–20 of 305 posts

Re: Rust in 2018: easier to use

#11

Post by StreamBright »

nafizh wrote: post #3

Anyone has suggestions on learning rust for a python programmer who is also not strong on systems concepts?

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 community is probably the best community of software engineers I have encountered recently. If you are interested in lower level coding there is Mirage as well.

https://discuss.ocaml.org/

Re: Rust in 2018: easier to use

#12

Post by yen223 »

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.

Re: Rust in 2018: easier to use

#13

Post by trumpsamerica »

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.

Garbage collected allocation is coming. There's even an rfc I think. Manishearth is working gon it

Re: Rust in 2018: easier to use

#14

Post by karlding »

Out of curiosity, how is the embedded story (for both bare-metal and RTOS) in Rust nowadays? I took a look early last year, and I remember feeling that the ecosystem still wasn't as mature as I liked.

There's svd2rust [0] and dslite2svd [1], which is basically "bindgen for hardware". Please do correct me if I'm wrong, but from what I understood [2], most SVD files leave out a lot of information so a lot of what svd2rust generates is unsafe. Seems like the only way around that is to patch the SVD files. Is this still the case?

In addition, what about compiling with no stdlib? And how does that interop with existing Crates (ie. do new "embedded-specific" Crates need to be created?)

Super excited to see Rust gain traction! I'll definitely take another shot in my free time and see how the ecosystem has matured.

[0] https://github.com/japaric/svd2rust

[1] https://github.com/m-labs/dslite2svd

[2] https://www.reddit.com/r/rust/comments/687b3l/embedded_in_ru...

Re: Rust in 2018: easier to use

#15

Post by exikyut »

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…

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

Not-crazy suggestion: add a `--why` option to rustc that doesn't just shout (helpful) error messages at you but actually explains the architectural theory of why the error is occurring and provides documentation links that help outline the canonical "right way" to do whatever it is you're trying to do.

The idea being that rustc applies a ton of heuristics and intelligence (perhaps by analyzing nearby code) to guess what your high-level goal is.

There have been a couple of "programming helper" AI-type apps float past here recentlyish; that's what I'm getting at.

The reasons I think this would be a good idea is that

a) this would be really really hard to get right, but AI R&D is pretty much at the point where you could put something like this together and build it into the compiler and pull it off really well

b) rust seems to have a ton of energy behind it so if any language was going to implement this, it looks like rust has a fighting chance to actually get it done

c) rust hasn't stabilized yet so _now_ is exactly the time to fold something like this in. it would need to be integrated as early as possible as a bolt-on afterthought would never work the same way

Re: Rust in 2018: easier to use

#16

Post by Karliss »

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…

Having some understanding of difference between value and reference types types (from c or c++) and reading documentation a bit might be necessary. Error messages sometimes also contain links to documentation in case you have no understanding of the topic. The most common problems I had so for was due to incorrect level of indirection. In such cases the cause is quite clear function returned/expected reference/value/Option/Option and you tried to assign it to something else. Suggestions help learning how standard library API behaves without opening API reference. In case of unwrapping Option or limiting borrows lifetime the code may get a bit messy. In such case I recommend reading documentation/searching internet as there might language or standard library feature (sometimes even in the link given by error message but not message itself) that helps writing it cleaner without brute forcing the code. Due to type checking it is difficult to mess up worse than making ugly code or moving away object you didn't want(which will be pointed out by compiler if you try to use it afterwards).

Re: Rust in 2018: easier to use

#17

Post by grayrest »

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.

> Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly.

I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.

Re: Rust in 2018: easier to use

#19

Post by pingiun »

StreamBright wrote: post #10

Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…

> It is new, it is shiny but lets wait its 10th birthday before it can be taken seriously and pls provide a decent async io / http library before we even get started what else can be done in Rust.

Have you not looked at it for a while or don't you think tokio/hyper is good?

Re: Rust in 2018: easier to use

#20

Post by papaf »

StreamBright wrote: post #10

Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…

pls provide a decent async io / http library before we even get started what else can be done in Rust

I have found Rust library coverage to be really good for my requirements. Hyper (https://hyper.rs/guides/client/basic/) provides an async HTTP client although I have never needed it.

Personally, if I had an application that was heavily using HTTP I would choose a different language -- Java, Scala and Go would be good choices.

Post reply on HN