Rust in 2018: easier to use

Re:Rust in 2018: easier to use by StreamBright on Sunday January 14, 2018 @03:13AM (#16143299)

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

[ Parent | on HN ]

Re:Rust in 2018: easier to use by papaf on Sunday January 14, 2018 @03:45AM (#16143359)

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

[ Parent | on HN ]

Re:Rust in 2018: easier to use by StreamBright on Sunday January 14, 2018 @07:50AM (#16144051)

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.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by fafhrd91 on Sunday January 14, 2018 @08:03AM (#16144088)

Good client library https://github.com/seanmonstar/reqwest Could be used as async or as sync.

Http/2 client and server https://github.com/carllerche/h2

Web framework https://github.com/actix/actix-web

All of them has good quality and performance

[ Parent | on HN ]

Re:Rust in 2018: easier to use by FridgeSeal on Sunday January 14, 2018 @05:02PM (#16146761)

Commenting to vouch for Reqwest.

Using it at the moment and it's been great to use: documentation was good, API was straightforward, everything so far has worked practically first time.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by tetromino_ on Sunday January 14, 2018 @03:47AM (#16143365)

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

[ Parent | on HN ]

Re:Rust in 2018: easier to use by StreamBright on Sunday January 14, 2018 @07:52AM (#16144054)

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.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by pingiun on Sunday January 14, 2018 @03:40AM (#16143353)

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

[ Parent | on HN ]

Re:Rust in 2018: easier to use by StreamBright on Sunday January 14, 2018 @07:50AM (#16144052)

Hyper is not good enough Tokio is WIP.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by xfer on Sunday January 14, 2018 @08:46AM (#16144221)

You do realize hyper depends on the tokio/future framework?

[ Parent | on HN ]

Re:Rust in 2018: easier to use by StreamBright on Sunday January 14, 2018 @10:57AM (#16144757)

https://github.com/tokio-rs/tokio

A work-in-progress rearchitecting of the tokio-core crate in line with tokio-rs/tokio-rfcs#3

[ Parent | on HN ]

Re:Rust in 2018: easier to use by setzer22 on Sunday January 14, 2018 @10:16AM (#16144556)

So if a language can't do HTTP and async I/O (with state-of-the-art performance) then we shouldn't consider any other possible application for it? Rust is not Java, you have better languages to build webservers with.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by kod on Sunday January 14, 2018 @11:38AM (#16144916)

Yes, if a language can't easily do async IO and HTTP in 2018, it is in deep shit with regard to long term adoption. The Rust devs realize this, otherwise they would be putting less effort into tokio.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by StreamBright on Monday January 15, 2018 @04:47AM (#16149561)

So if a language cannot do our business need then we shouldn't consider any other possible application for it?

[ Parent | on HN ]

Re:Rust in 2018: easier to use by Dowwie on Sunday January 14, 2018 @06:00PM (#16147049)

Looks like we found the javatarian!

I had to look up on Wikipedia when Rust was conceived: 2010. It took me another moment to realize that it's already been 8 years.

We should be flying in spaceships programmed with Rust by now. This is ridiculous.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by steveklabnik on Sunday January 14, 2018 @06:55PM (#16147342)

It was changing on a near-daily basis until May of 2015. It was extremely hard to build big projects in it until that point.

[ Parent | on HN ]

[dead]

Re:Rust in 2018: easier to use by Dowwie on Monday January 15, 2018 @06:16AM (#16149848)

It was an ad hominem. I'm sorry. Good luck with your endeavors. Erlang is a wise choice, if you can find the people to support it.

[ Parent | on HN ]

Re:Rust in 2018: easier to use by z0ltan on Sunday January 14, 2018 @04:03AM (#16143411)

Agreed.

[ Parent | on HN ]