Live data from Hacker News

Rust in 2018: easier to use

jvns.ca

111–120 of 305 posts

Re: Rust in 2018: easier to use

#111
post #45

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.

It was an abortive piece of crap, like most of Microsoft's offerings, when they weren't killing competitors and seeding people into government jobs to further instill their crap.

Fuck you.

Re: Rust in 2018: easier to use

#112
post #107
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.

Isn't Rust perfect for severless? Since cloud providers do all the plumbing, Rust would only have to deliver a tiny Linux binary for the function.

I do not think it will be tiny after including all the required and atm non existent SDKs

Re: Rust in 2018: easier to use

#113
post #100

Earlier quoted context omitted.

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/

Thanks for posting the link. Precisely what I was talking about! They are very useful to play around with the language ecosystem.

If I learn something new, I'll try to add to their repo.

Re: Rust in 2018: easier to use

#114
post #99

Earlier quoted context omitted.

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

In that case it's no different from Rust, Rust has a GC option (ref counting). It's limited and opt-in then you still carry the cognitive burden of memory management, you have to think when to use it. But if you need that level of control, you'll need to think about memory anyway.

And in my experience, it's way easier to reason about allocations in Rust that it is in Java (automatic type erasure if you want to use generic code) or Go (how will escape analysis behave in that case ?) for example. Rust traits are way better than C++ interfaces in that regard also.

Re: Rust in 2018: easier to use

#115
post #91

Earlier quoted context omitted.

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.

Wasn't Rust invented to write a GUI? A webbrowser can be regarded as a kind of GUI.

There aren't any good GUI libraries available for Rust at the moment. GUI libraries are huge and take an enormous amount of work to get right. It's typically only the most popular three or four languages at any given point in time that have satisfactory GUI libraries. Rust has the additional burden that it is far from trivial to wrap Gtk, Qt or other C/C++ toolkits in a safe manner.

Re: Rust in 2018: easier to use

#116
post #84

Earlier quoted context omitted.

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

Anyone pinning hope on limn should take a look at the activity on the project since start of December.

You're talking about just over a month. I think it's a little unfair to expect people to maintain hobby projects every week of every year. Particularly over Christmas and the new year when our lives are often busier than usual.

To use a personal example, an open source project I actively maintain only yesterday saw it's first commits since the end of November. But I am still very much committed to that project.

Re: Rust in 2018: easier to use

#117
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 like Swift :) (ARC, not tracing GC, but still.)

If Arc counts, then it juste sounds like Rust actually ;).

Re: Rust in 2018: easier to use

#118
post #3

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

Read the books, write code. When you'll encounter lifetimes, it's good to remember that lifetime annotations are descriptive and not prescriptive. You can't change lifetime of a variable by adding lifetime annotations. For example, local variables of a function get destroyed on function exit no matter what and you can't prevent it by adding lifetime annotation to a local variable reference you are trying to return. T…

You summarized it so well ! It was also a huge source of confusion for me in the beginning.

Would you mind if I made a pull request to the Rust book adding your explaination to the lifetime chapter ?

Re: Rust in 2018: easier to use

#119
post #115

Earlier quoted context omitted.

Wasn't Rust invented to write a GUI? A webbrowser can be regarded as a kind of GUI.

There aren't any good GUI libraries available for Rust at the moment. GUI libraries are huge and take an enormous amount of work to get right. It's typically only the most popular three or four languages at any given point in time that have satisfactory GUI libraries. Rust has the additional burden that it is far from trivial to wrap Gtk, Qt or other C/C++ toolkits in a safe manner.

Didn't Mozilla write a GUI library before they wrote Firefox? It would strike me as odd if they didn't.

Re: Rust in 2018: easier to use

#120
post #104
post #72

Earlier quoted context omitted.

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

In the words of Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to…

I don't see what that has to do with offshoring. Developers of the kind Rob Pike is referring to exist everywhere in the world.
Post reply on HN