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

131–140 of 305 posts

Re: Rust in 2018: easier to use

#131

Post by pjmlp »

foldr wrote: post #120
pjmlp wrote: post #104

Earlier quoted context omitted.

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.

I do enterprise consulting, in projects which happen to always have some kind of offshoring involved.

Projects where the languages are easy to pick up and anyone can do it, are always the first on the pipeline to give away.

Re: Rust in 2018: easier to use

#132

Post by pjmlp »

singhrac wrote: post #123
pjmlp wrote: post #104

Earlier quoted context omitted.

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.

Yet Google is known for having one of the hardest hiring processes, where they even give the candidates CS subjects to study before the interview.

Re: Rust in 2018: easier to use

#133

Post by littlestymaar »

K0nserv wrote: post #124
littlestymaar wrote: post #117

Earlier quoted context omitted.

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.

If you use Arc everywhere you just end up with the same behavior than Swift (except for closures I guess).

Re: Rust in 2018: easier to use

#134

Post by fafhrd91 »

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…

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

Re: Rust in 2018: easier to use

#135

Post by red75prime »

littlestymaar wrote: post #118
red75prime wrote: post #7

Earlier quoted context omitted.

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 ?

I wouldn't. Feel free to use it. But I have the impression that the Rust book contains something to that effect.

"Descriptive and not prescriptive" part probably comes from stackoverflow. I don't remember exactly.

Re: Rust in 2018: easier to use

#136

Post by pjmlp »

littlestymaar wrote: post #114
pjmlp wrote: post #99

Earlier quoted context omitted.

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

Java and Go are just two examples, and surely not those that I had in mind.

Rather languages in the Oberon and Modula family, D, Nim, Eiffel, C# as of 7.2, Common Lisp, and a few MLs.

If you do RC everywhere, using library types, it is slower than a tracing GC, and still not as productive.

Re: Rust in 2018: easier to use

#137

Post by devit »

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.

The problem is that it turns out that cyclic garbage collection is essentially useless, except for running existing code that expects a garbage collector to be present (e.g. JavaScript code if you are writing a web browser).

Since it's useless, not having it is great since you no longer have to worry about it and the problems it causes like random pauses, sawtooth-shaped and excessive memory usage and inability to use swap properly (although you have to worry about heap fragmentation, but usually that's not as terrible).

Also you'd need lifetimes and borrowed references anyway to have static guarantees like that there are no remaining references to mutex-protected data after you unlock the mutex, so having a GC as well actually increases complexity.

Re: Rust in 2018: easier to use

#138

Post by foldr »

pjmlp wrote: post #131
foldr wrote: post #120

Earlier quoted context omitted.

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.

I do enterprise consulting, in projects which happen to always have some kind of offshoring involved. Projects where the languages are easy to pick up and anyone can do it, are always the first on the pipeline to give away.

Are you really saying that Rob Pike is part of some kind of conspiracy to offshore all the coding that's currently being done at Google SF? Golang has been around for a while now, and there's no sign of that happening.

Re: Rust in 2018: easier to use

#140

Post by gus_massa »

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…

Perhaps this is not exactly what you are looking for, and I don't know if the examples are idiomatic, but you can check http://rosettacode.org/wiki/Category:Rust (follow the links in the section 'Pages in category "Rust"', there are almost 400 examples)
Post reply on HN