Rust in 2018: easier to use • Hacker News Board

Re: Rust in 2018: easier to use

#21

Post by tetromino_ » Sun, Jan 14, 2018, 8:47 AM UTC

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…

Performance of what code was 30 times less? It would make a great project for someone to investigate in depth why Rust performs particularly poorly (or why Java performs particularly well) in a specific area - if only you could provide the necessary details...

Re: Rust in 2018: easier to use

#22

Post by yen223 » Sun, Jan 14, 2018, 8:47 AM UTC

grayrest wrote: post #17

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.

I've built several toy projects with ReasonML. I found the overall experience fairly positive, so please take this comment kindly.

I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things.

I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward references, a plethora of file types to deal with, no UTF8 strings without bringing in an external lib, and so on).

Re: Rust in 2018: easier to use

#23

Post by papaf » Sun, Jan 14, 2018, 8:51 AM UTC

StreamBright wrote: post #11

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

Re: Rust in 2018: easier to use

#24

Post by eecc » Sun, Jan 14, 2018, 8:54 AM UTC

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018.

http://www.arewewebyet.org

Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position

Re: Rust in 2018: easier to use

#25

Post by dang » Sun, Jan 14, 2018, 8:55 AM UTC

grnadav1 wrote: post #18

A guy w/ 10 weeks Rust experiance and already gave a talk at RustConf?!

Most of the comments you've posted to HN have been unsubstantive. We ban accounts that do that, so could you please read https://news.ycombinator.com/newsguidelines.html and stop doing that?

This one was particularly uninformed.

Re: Rust in 2018: easier to use

#26

Post by readittwice » Sun, Jan 14, 2018, 9:00 AM UTC

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.

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.

Re: Rust in 2018: easier to use

#27

Post by z0ltan » Sun, Jan 14, 2018, 9:03 AM UTC

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…

Agreed.

Re: Rust in 2018: easier to use

#28

Post by karo_ops » Sun, Jan 14, 2018, 9:06 AM UTC

Each time I try to read an article by Julia, I get alienated by the chidlish style of writing (count the exclamation marks and caps).

Which is a shame, because the article is otherwise fine.

Re: Rust in 2018: easier to use

#29

Post by banachtarski » Sun, Jan 14, 2018, 9:07 AM UTC

eecc wrote: post #24

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018. http://www.arewewebyet.org Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position

> Nobody with a sane mind would write C or CPP micro-services

why? I do this all the time. Maybe I should check into a nearby asylum.

Re: Rust in 2018: easier to use

#30

Post by hateduser2 » Sun, Jan 14, 2018, 9:09 AM UTC

exikyut wrote: post #15

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 occ…

I like the idea but Rust has so many issues in front of it I’m not sure it has the energy to invest in something like hay.