Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust can be difficult to learn and frustrating, but it's also very exciting

influxdata.com

Post reply on HN
Print view View original

271–280 of 282 posts

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#271

Post by throwaway487548 »

UK-Al05 wrote: post #191
throwaway487548 wrote: post #134

It seems that the main problem with Rust is that it has been grown up not from the CS and PL theory fundamentals , like ML, or Scheme or Erlang or even Go, and it is obviously not a small, clean language everyone loves and appreciates as being beautiful. In other words it is just little better than C++, which is a crap. If a language could be grown from ML (Ocaml) roots (like Scala) instead of C++, it could be much s…

Rust is ML like. It can do pattern matching and has adt type system. It uses expressions rather statements If you remove gc from ocaml, and added in compensating alternatives it would end up looking something like rust. I think a lot of the adversting around rust in a "better c++" but its actually ocaml like but not mentioned to avoid scaring away traditional systems devs.

Rust did a lot of things nice, but it is over cluttered with all these particularities everywhere, which could be hidden by better default conventions.

For example, everything should be a reference by default, and use of explicit & is stylistically bad.

Or why in let mut iter = a.iter(); iter is mut? It should be a simple closure which follows a protocol. In what sense it is mutable?

And such small warts are literally everywhere, together resulting in a clutter.

A functional language uniform defaults (everything is an expression, everything is a binding which implies everything s reference) are much better.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#272

Post by steveklabnik »

throwaway487548 wrote: post #271
UK-Al05 wrote: post #191

Earlier quoted context omitted.

Rust is ML like. It can do pattern matching and has adt type system. It uses expressions rather statements If you remove gc from ocaml, and added in compensating alternatives it would end up looking something like rust. I think a lot of the adversting around rust in a "better c++" but its actually ocaml like but not mentioned to avoid scaring away traditional systems devs.

Rust did a lot of things nice, but it is over cluttered with all these particularities everywhere, which could be hidden by better default conventions. For example, everything should be a reference by default, and use of explicit & is stylistically bad. Or why in let mut iter = a.iter(); iter is mut? It should be a simple closure which follows a protocol. In what sense it is mutable? And such small warts are literall…

Iterators contain internal state that gets mutated as you iterate. So it needs to be mutable.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#273

Post by steveklabnik »

bb88 wrote: post #267
steveklabnik wrote: post #258

Earlier quoted context omitted.

As with all performance questions, the answer is “it depends.” For a look into this question, see http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

Hey thanks for the response. I'm happy that rust has a good set of performant data structures, but on the other I feel like it's too soon to say Rust is the big winner here as the author does. I've been very skeptical on fantastical claims by language promoters. But taking the pain out of making common data structures is a good start.

I think if you'll look into the author's credentials he is far from a "language promoter."

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#274

Post by throwaway487548 »

steveklabnik wrote: post #272
throwaway487548 wrote: post #271

Earlier quoted context omitted.

Rust did a lot of things nice, but it is over cluttered with all these particularities everywhere, which could be hidden by better default conventions. For example, everything should be a reference by default, and use of explicit & is stylistically bad. Or why in let mut iter = a.iter(); iter is mut? It should be a simple closure which follows a protocol. In what sense it is mutable? And such small warts are literall…

Iterators contain internal state that gets mutated as you iterate. So it needs to be mutable.

But the whole idea is that once a closure implements an interface its internal state is strongly isolated behind the abstraction barrier of the interface and no one knows or cares whatever state it has, if any. It is very CS 101.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#275

Post by steveklabnik »

throwaway487548 wrote: post #274
steveklabnik wrote: post #272

Earlier quoted context omitted.

Iterators contain internal state that gets mutated as you iterate. So it needs to be mutable.

But the whole idea is that once a closure implements an interface its internal state is strongly isolated behind the abstraction barrier of the interface and no one knows or cares whatever state it has, if any. It is very CS 101.

Well, first of all, it's not a closure, it's a struct, though closures are syntax sugar for structs.

Second, what you said is true, but also not really relevant; mutability is part of the API in Rust, and so that is part of the interface.

To make it more concrete, https://doc.rust-lang.org/stable/std/iter/trait.Iterator.htm..., the protocol, takes &mut self. So it must be mutable. It's following the principle you're talking about.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#276

Post by igouy »

thethirdone wrote: post #266
igouy wrote: post #260

Earlier quoted context omitted.

"The basic advice regarding response times has been about the same for thirty years : 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result." https://www.nngroup.com/articles/response-times-3-important-...

Originally you asked "is 54.55 ms perceptable?", I say yes. I can tell the difference between 25 ms and 1 ms in my terminal. That said, I don't think it is worth trying to reduce your startup time to the point where you can't tell the computer took time. Getting "the user [to] feel that the system is reacting instantaneously" is a different and more important goal.

> I can tell the difference between 25 ms and 1 ms

Maybe you are fooling yourself.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#277

Post by igouy »

thethirdone wrote: post #265
igouy wrote: post #261

Earlier quoted context omitted.

> Real java projects … Can take much longer, and are engineered so that users don't experience a delay. The users interact with a system that is already launched and up-to-speed. So much for Hello world!

I was just trying to come up with a real situation where there is a 2 order of magnitude difference. Obviously in many situations you can mitigate the startup time. However, it does lock Java out of being a good replacement for git or other quick command line tools.

Not if jgit is already launched and sitting around waiting for commands.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#278

Post by vkjv »

weberc2 wrote: post #110
tech2 wrote: post #25

Earlier quoted context omitted.

The system's peak _usage_ is 60kreq/min (avg 1k/s), the Python code it's written in can handle maybe 850/s per instance at 100% CPU. Rust is fine, rust is managing almost 2k/s on the same hardware. And this is when I know practically nothing about Rust, I expect I'm likely able to do better given time. It's acting as a simple filter and cache over JSON data on Postgres.

I’m shocked that Rust only gave you a 2X improvement over Python (I’ve rewritten a handful of Python services to Go and typically see 100-1000X improvement). What is the bottleneck? Was scaling horizontally an option?

Interestingly, I was able to get an amazing speed improvement without going completely to Rust.

I didn't want to port APM code as well, so I kept node.js/express for routing. Very simple middleware that immediately passed the request and body buffer to Rust for handling. Rust returned a buffer back to express for sending the response.

It's easily able to hit 100k RPM on a single instance before hitting a CPU bottleneck in the Rust code (validating an RSA signature). It only needs to handle 90k RPM total.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#279

Post by igouy »

weberc2 wrote: post #269
igouy wrote: post #262

Earlier quoted context omitted.

Where did you get the idea that 10 tiny tiny programs could tell you about a programming language’s average performance? Who in this discussion has made any such a claim? You repeatedly put up a straw man.

Im not sure why you’re confused. ilovecaching made claims about the relative performance of programming languages based on the benchmark game.

ilovecaching responded to your claim that — [Go's] performance is closer to Java — by posting links to pages on the benchmarks game website.

ilovecaching pointed to the performance of specific Go and Java programs

Now you have put up a straw man — "a programming language’s average or percentile performance or even its peak performance."

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#280

Post by erwan »

pjmlp wrote: post #133
ilovecaching wrote: post #109

Earlier quoted context omitted.

> There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together. Plan 9 is an operating system. If you're referring to goroutines, CSP is completely unrelated to any of the work done at Bell Labs. That was Hoare. Go also kept a ton of terrible ideas, like nil, void (interface{}), and default mutability. > Go is a _systems_ language…

People are doing OS research in Go, and Fuchsia core components like the TCP/IP stack are written in it, regardless of what the HN crowd thinks where Go should be used. https://github.com/mit-pdos/biscuit https://github.com/ycoroneos/G.E.R.T Last version of Plan 9 was actually Inferno, which HNers keep forgetting about, which used Limbo for userspace code. Limbo uses the channel syntax later adopted by Go.

+1 for Biscuit and Fuchsia
Post reply on HN