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

71–80 of 305 posts

Re: Rust in 2018: easier to use

#71

Post by stevedonovan »

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

Oh yes - there will be some explicit type like std::vec::Vec in the error and that all-important '&' gets lost in the verbosity. Definitely necessary to learn to see the needle in that haystack. (Some have proposed simplifying the explicit types if no confusion results, but this could always done by a post-processor. I saved some of my sanity when doing C++ this way)

Re: Rust in 2018: easier to use

#72

Post by K0nserv »

eecc wrote: post #50
curiousGambler wrote: post #39

Earlier quoted context omitted.

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

Golang is a language designed for offshoring? It was invented at one of the largest engineering orgs to be used in house

Re: Rust in 2018: easier to use

#73

Post by rapsey »

sho_hn wrote: post #53
rapsey wrote: post #49

Earlier quoted context omitted.

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

I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolki…

Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.

Re: Rust in 2018: easier to use

#74

Post by raverbashing »

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.

Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code

Re: Rust in 2018: easier to use

#75

Post by StavrosK »

vhakulinen wrote: post #51
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.

Writing GUI with rust is totally possible: http://gtk-rs.org/

Yes but "possible" and "pleasant" are very different :(

Re: Rust in 2018: easier to use

#76

Post by StavrosK »

banachtarski wrote: post #63
fauigerzigerk wrote: post #61

Earlier quoted context omitted.

>Maybe I should check into a nearby asylum. If you do, make sure it says "believes in micro-services" on the referral ;-)

I just mentally edit "micro-services" to "services" any time I read it hehe.

What, do you edit the "web" out of "webscale" too? Certifiable.

Re: Rust in 2018: easier to use

#77

Post by QasimK »

ohazi wrote: post #2

Agreed. I've played with Rust on and off since ~v0.8. I tried to get through the Matasano crypto challenges a few years ago and gave up after hitting a few language hiccups. I recently gave it another go, and it's much easier to use now. I must have written around a thousand lines before needing a lifetime annotation, vs. something like 30 lines two years ago.

The Matasano crypto challenges seem interesting and remind me of Project Euler. I used the latter to help learn Python a little, and I think the former would be even better for Rust!

Re: Rust in 2018: easier to use

#78

Post by IshKebab »

rapsey wrote: post #73
sho_hn wrote: post #53

Earlier quoted context omitted.

I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolki…

Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.

There's a project called Limn trying to do this. I doubt it has solved the ergonomics issue though.

Re: Rust in 2018: easier to use

#79

Post by reacharavindh »

Just an idea: I wish there was an official wiki in the lines of Arch Wiki that shows how to do things with Rust with lots and lots of examples.

True there is the Rust Programming Language v2 book and several other learning resources online, but they all carry redundant information and pass it on the user to discover what they want to learn. A legendary wiki which acts like a cookbook of all things Rust could be awesome and anyone can pick what they want to learn about and go at it.

I would happily contribute and do it, but I'm just starting to learn Rust. Perhaps it is easier for other experienced Rustaceans to do it right.

Re: Rust in 2018: easier to use

#80

Post by chillydawg »

reacharavindh wrote: post #79

Just an idea: I wish there was an official wiki in the lines of Arch Wiki that shows how to do things with Rust with lots and lots of examples. True there is the Rust Programming Language v2 book and several other learning resources online, but they all carry redundant information and pass it on the user to discover what they want to learn. A legendary wiki which acts like a cookbook of all things Rust could be aweso…

https://rustbyexample.com/
Post reply on HN