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

41–50 of 305 posts

Re: Rust in 2018: easier to use

#41

Post by pjmlp »

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

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.

Re: Rust in 2018: easier to use

#42

Post by jefftime »

karlding wrote: post #14

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

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

Re: Rust in 2018: easier to use

#43

Post by Yuioup »

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

Just out of curiosity, how many web framework platform are originally written and compiled in C? CPython, udev, node, v8, ... rust?

Re: Rust in 2018: easier to use

#44

Post by pjmlp »

Karliss wrote: post #16
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/…

> value and reference types types (from c or c++)

Applies to other languages as well.

Re: Rust in 2018: easier to use

#45

Post by jgtrosh »

curiousGambler wrote: post #36
grayrest wrote: post #9

I expect a "it's easier to use" evangelism push around the upcoming epoch release. There are a bunch of mostly completed but still feature flagged changes that should remove a lot of the borrow checker toe stubbing. Getting rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part of the push. Aside from the almost completed features in the pipeline, I only see procedural macros (macros 2.0) and wh…

Why anyone would name anything "clippy" again is beyond me.

Clippy is reborn from its ashes into a cultural icon; it made you react, therefore it's a fun name to choose. Kakoune uses a clippy ASCII art for its immediate help, it's nice.

Re: Rust in 2018: easier to use

#46

Post by shadowmint »

banachtarski wrote: post #29
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.

The point isn’t that no one does it, its that its hard to do right.

...and that is flat out the case for c++, unequivocally.

In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at.

Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services.

Its definitely a good goal for the year~

Re: Rust in 2018: easier to use

#47

Post by timClicks »

nafizh wrote: post #3

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

Hopefully I am not overstepping bounds by mentioning my book, but I encourage you to take a look at Rust in Action by Manning. It's written for current programmers who want to learn Rust as well as enough of the systems programming concepts that seem to sneak into Rust docs and discussion.

Re: Rust in 2018: easier to use

#49

Post by rapsey »

pjmlp wrote: post #41
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

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.

You're comparing a language to an OS and three GUI frameworks.

Re: Rust in 2018: easier to use

#50

Post by eecc »

curiousGambler wrote: post #39
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

I get the impression Go runs the microservice space. It's built for it and is incredibly fast despite the GC. I don't see Rust claiming that position anytime soon.

Where I live and work, golang is only used at one major client (because they’re US based, the decision must have happened elsewhere.)

Everything else is Spring Boot (java), Akka (Scala) or Nodejs. Apparently nobody wants to embrace a language designed for offshoring, so no Meetups, noisy user groups and so on... even Clojure is more popular

Post reply on HN