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

121–130 of 305 posts

Re: Rust in 2018: easier to use

#121

Post by foldr »

amelius wrote: post #119
foldr wrote: post #115

Earlier quoted context omitted.

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.

There is no mature GUI library for Rust that I'm aware of. I believe the servo project is focused on writing a browser rendering engine, not a browser GUI. It certainly has not so far yielded a GUI toolkit that can be straightforwardly used in other projects.

Re: Rust in 2018: easier to use

#122

Post by StreamBright »

papaf wrote: post #23
StreamBright wrote: post #11

Earlier quoted context omitted.

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?

I am not sure what exactly you are missing, isn't this a native OS thread either POSIX or Win32?

http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.htm...

Re: Rust in 2018: easier to use

#123

Post by singhrac »

pjmlp wrote: post #104
K0nserv wrote: 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…

Software is more than just language features. Rob undoubtedly meant that he wanted it to be quick to be understood by a vast majority of Googlers, so that they can focus on writing good software.

Re: Rust in 2018: easier to use

#124

Post by K0nserv »

littlestymaar wrote: post #117
Manishearth wrote: post #34

Earlier quoted context omitted.

This sounds like Swift :) (ARC, not tracing GC, but still.)

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

I dunno if I agree, the borrow checker in Rust requires a lot more active thinking and intervention to get memory right. Objective-C and Swift ARC is really straightforward and there are few gotchas. Kinda like GC.

Re: Rust in 2018: easier to use

#125

Post by StreamBright »

papaf wrote: post #20
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…

pls provide a decent async io / http library before we even get started what else can be done in Rust I have found Rust library coverage to be really good for my requirements. Hyper ( https://hyper.rs/guides/client/basic/ ) provides an async HTTP client although I have never needed it. Personally, if I had an application that was heavily using HTTP I would choose a different language -- Java, Scala and Go would be go…

Again what is your use case. Ours was to have a high performance compiled code that can be slower than Java by a factor of 10. Unfortunately Rust could cut it.

Re: Rust in 2018: easier to use

#126

Post by StreamBright »

pingiun wrote: post #19
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…

> It is new, it is shiny but lets wait its 10th birthday before it can be taken seriously and pls provide a decent async io / http library before we even get started what else can be done in Rust. Have you not looked at it for a while or don't you think tokio/hyper is good?

Hyper is not good enough Tokio is WIP.

Re: Rust in 2018: easier to use

#127

Post by StreamBright »

tetromino_ wrote: post #21
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...

Yeah I wanted to. I reached out to my Rust devs and everybody said that my code is perfectly fine. It means I have to dig into the library code but does not have enough knowledge about Rust performance and what tooling I am supposed to do or what are the knobs that I need to adjust for higher performance.

Re: Rust in 2018: easier to use

#128

Post by red75prime »

jefftime wrote: post #109
red75prime wrote: post #101

Earlier quoted context omitted.

`-C panic=abort` compiler option should have fixed the problem. If you want to be able to intercept panics, you need to provide implementations for `eh_unwind_resume` and `eh_personality`.

Perhaps it's just an issue of me not being educated enough with this kind of low-level Rust. Setting panic to abort in the cargo config did indeed fix `eh_personality` being undefined, but `eh_unwind_resume` still seems finnicky. Building in release will work, but building in debug will still complain

I'm a little rusty on the topic, but it seems ([0]) that adding `#[no_mangle]` before `panic_fmt` should fix it.

[0] https://github.com/rust-lang/rust/issues/38281

Re: Rust in 2018: easier to use

#129

Post by lima »

amelius wrote: post #110
pjmlp wrote: 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.

Rust was invented for low-level parsing/rendering code. The high level GUI in Firefox is not implemented in Rust for all I know.
Post reply on HN