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

91–100 of 305 posts

Re: Rust in 2018: easier to use

#91

Post by pjmlp »

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/

It is possible, but far from productive, which I learned exactly by trying to use Gtk-rs to port an old basic Gtkmm demo, that I used for a C/C++ Users Journal article.

Re: Rust in 2018: easier to use

#92

Post by bjz_ »

jgtrosh wrote: post #45
curiousGambler wrote: post #36

Earlier quoted context omitted.

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.

> Kakoune uses a clippy ASCII art for its immediate help, it's nice.

Had to look this up - very cute!

https://github.com/mawww/kakoune#screenshots

https://raw.githubusercontent.com/mawww/kakoune/master/doc/s...

Re: Rust in 2018: easier to use

#93

Post by reacharavindh »

chillydawg wrote: post #80
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/

Thanks for the link.

I thought it was a small effort to show around the language features. Like a live(runnable code) version of the Rust programming language book. Very useful for someone trying learn the language feature by feature.

What I'm writing about is a how-to style wiki. For example,

How to do things with Rust:

How to read from stdin?

How to read and write from a text file?

How to make a REST API call from Rust?

How to parse JSON content in Rust?

How to connect to PostgreSQL in Rust?

How to issue Unix commands to a remote host via SSH using Rust?

How to create threads for parallel work in Rust?

You get the idea..

Re: Rust in 2018: easier to use

#94

Post by baq »

reacharavindh wrote: post #93
chillydawg wrote: post #80

Earlier quoted context omitted.

https://rustbyexample.com/

Thanks for the link. I thought it was a small effort to show around the language features. Like a live(runnable code) version of the Rust programming language book. Very useful for someone trying learn the language feature by feature. What I'm writing about is a how-to style wiki. For example, How to do things with Rust: How to read from stdin? How to read and write from a text file? How to make a REST API call from…

IMHO stack overflow was meant to be exactly this.

Re: Rust in 2018: easier to use

#95

Post by dom96 »

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.

This sounds a lot like Nim to me. Give it a go if you haven't already. It's a systems programming language that primarily uses a garbage collector.

Re: Rust in 2018: easier to use

#96

Post by tomsmeding »

bjz_ wrote: post #92
jgtrosh wrote: post #45

Earlier quoted context omitted.

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.

> Kakoune uses a clippy ASCII art for its immediate help, it's nice. Had to look this up - very cute! https://github.com/mawww/kakoune#screenshots https://raw.githubusercontent.com/mawww/kakoune/master/doc/s...

Their choice of executable name is slightly unfortunate in Dutch, where 'kak' basically means 'shit'.

Re: Rust in 2018: easier to use

#97

Post by bjz_ »

stevedonovan wrote: post #71
Karliss wrote: post #16

Earlier quoted context omitted.

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)

> and that all-important '&' gets lost in the verbosity

Perhaps some console colouring could help as well. I'd really like some type diffs on type mismatch errors (I think Dotty has this?). That could be super handy for quickly diagnosing errors - speaking as a reasonably experienced Rust user here.

Re: Rust in 2018: easier to use

#98

Post by pjmlp »

rapsey wrote: post #49
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.

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

No, I am comparing the selection of a specific programming language, given the existence of tooling for a specific purpose.

I need to fulfil task X, with tool Y, then I choose language Z among those supported by Y.

Not I chose language Z, then try to find some kind of Y, that helps me solve X somehow.

When C++ came into the picture we got Turbo Vision on MS-DOS bundled with Borland compilers, Apple adopted Metrowerks tools and used PowerPlant, OS/2 promoted CSet++, UNIX guys were into Motif.h++.

Then came Windows, Borland pushed forward with OWL followed by VCL. Microsoft created MFC, adopted by Symatec and Zortech compilers.

Apple eventually went Cocoa, and Microsoft UWP as of latest.

And then there is Qt, literally the only game in town for C++ GUIs not related to any OS vendor.

Followed by what in possible in Java and .NET eco-systems.

All with good visual tooling support, allowing for productive workflows between developers and designers.

I am not saying that Rust some day won't catch up, and offer something similar in terms of productivity.

I hope it does, but right now in 2018 it doesn't.

Re: Rust in 2018: easier to use

#99

Post by pjmlp »

viraptor wrote: post #59
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.

> any GC language is a better fit in terms of productivity But that's not the only constraint. If you want to save memory, due to the environment you run on, or your workload, a non-GC runtime can be pretty awesome.

Just because a language has a GC, doesn't mean it doesn't have language features to have more fine grained control over how memory allocation takes place, or even when the GC has to run if at all.

Re: Rust in 2018: easier to use

#100

Post by bjz_ »

reacharavindh wrote: post #93
chillydawg wrote: post #80

Earlier quoted context omitted.

https://rustbyexample.com/

Thanks for the link. I thought it was a small effort to show around the language features. Like a live(runnable code) version of the Rust programming language book. Very useful for someone trying learn the language feature by feature. What I'm writing about is a how-to style wiki. For example, How to do things with Rust: How to read from stdin? How to read and write from a text file? How to make a REST API call from…

The Rust Cookbook has made a start on this too! https://rust-lang-nursery.github.io/rust-cookbook/
Post reply on HN