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

141–150 of 282 posts

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

#141

Post by piano »

rqs wrote: post #136
steveklabnik wrote: post #92

Earlier quoted context omitted.

Traits for interop are a prime consideration for std, even if we try to keep it small. But we can only add things when they’re ready; that’s part of the stability you desire. Look at the Future trait, as an example. And rust has had the equivalent of io.{Reader, Writer} since 1.0.

I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`. In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I…

> In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down).

Well there's stuff like error-chain to take care of the boilerplate...

Also, I believe you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object). It could be used much the same way as in Go with the additional benefit of Result being a sum type. I'm personally not a big fan of this approach but I guess it might work...

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

#142

Post by olavk »

village-idiot wrote: post #99
dbcurtis wrote: post #85

Earlier quoted context omitted.

> Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My biggest gripe is that they left out readability. I like the semantics of Rust, and appreciate the performance and the transparent memory model. I am extremely excited to try Rust on an embedded project. Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance…

Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window. Also, it makes autoindent in Emacs worse.

PEP-8 (more than 15 years old) recommend spaces, so unless you are deliberately looking for a fight, the question is settled.

Autoindent is a solution to a problem that doesn't exist in Python in the first place. Having two independent representations for blocks, one for human readers (indent) and one for compilers (braces), leads to nasty bugs when they get out of sync. Autoindent is a tool to keep them in sync. In Python there is a single representation, so nothing can get out of sync.

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

#143

Post by tech2 »

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?

I suspect the reason it's not faster is one of the following:

  1. backend DB at its query limit
  2. this is basically my first rust program and I've done something stupid
  3. ab/wrk aren't scaling properly either (I know, not likely, but worth considering) when I'm testing it
  4. bandwidth/IO limits on the AWS instance types I'm running this on
There are other possibilities too I guess. I was mostly doing this as a means to learn Rust though, I'd only go live with it once I had decent tests and everything else.

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

#144

Post by tech2 »

emptysea wrote: post #33
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.

Any reason you didn't scale up horizontally with more python instances?

I have multiple instances to keep the latency down overall (and for security should we lose an availability zone or whatever else). But, as others have mentioned, instances cost, I'd like to be able to reduce that to the minimum if possible.

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

#145

Post by rqs »

piano wrote: post #141
rqs wrote: post #136

Earlier quoted context omitted.

I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`. In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I…

> In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down). Well there's stuff like error-chain to take care of the boilerplate... Also, I b…

> you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object).

I know this basically how Go's error handling works (Put error data on heap and pass the reference), but I'm not fan of it (the put data on heap part of it) too :(

I will try out the error-chain, thank you for reminding me that.

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

#146

Post by piano »

bb88 wrote: post #73
ilovecaching wrote: post #58

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust…

> I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good. I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Looking at this thread there are plenty of examples of "I love…

> But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way.

Yes, I agree, but that's not the full picture. People want a language in which they can be productive quickly, but once they master it, they, or at least some of them, will then look into quality and performance. Languages like JavaScript or Python (and even Go to some extent) are popular and easy to pick up, but there's not much room for further progress. JavaScript is already stretched to its absolute limits when it comes to performance and it's still not performing very well. And when it comes to quality, well, TypeScript is a thing for a reason.

I don't believe Rust will ever be as much of a language for the masses as JS, but it has a good chance to become a niche language for those who need or want more performance and/or quality than they can get with langs like JS or Python.

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

#147

Post by zlynx »

MarkovUnchained wrote: post #93
ilovecaching wrote: post #58

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust…

The failures of Rust are the same failures of C++. Leaky abstractions making it impossible to separate representation details, making the abstraction consume a disproportionate mental load. Given that Rust doesn't actually solve any of the actual problems C++ programmers have, there is no motivation to switch.

Actual problems like:

- sending dangling references to thread functions. Lambdas with automatic reference capture creating threads from inside functions that exit are terrible here.

- returning a pointer or reference to an invalidated iterator

- returning a pointer or reference to the contents of a temporary

Yes indeed, C++ programmers never actually have these problems, they are purely imaginary. /sarc

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

#148

Post by olavk »

bb88 wrote: post #73
ilovecaching wrote: post #58

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust…

> I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good. I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Looking at this thread there are plenty of examples of "I love…

Comparing Haskell to JavaScript is silly - JavaScript is popular because it is the only option in the browser. It has noting to do with the quality of the language itself. If VBScript had won, everyone would be using that. If Netscape had decided to use Scheme or Haskell as the scripting language, this is what everyone would be using.

Rust is competing in the space of C and C++, it is not competing against Java or Python. People are not gong to write operating systems in Python because it feels more productive. For simpler desktop applications you may have a point, but heavyweights like Word or Photoshop are written in C++ and Rust may be a realistic migration. JavaScript or Python is not.

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

#149

Post by [deleted] »

fiedzia wrote: post #137
mwcampbell wrote: post #84

Earlier quoted context omitted.

IMO it's not really web ready until there's one web framework that has a clear majority of mindshare, like Rails for Ruby or Django for Python.

What's the point of this requirement? Python doesn't have "the one" either, does it mean its not web ready?

[deleted]

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

#150

Post by olavk »

rqs wrote: post #78
ilovecaching wrote: post #58

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust…

I think the learning curve thing is depends on what's the language that you are compare it with. C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit). Rust on the other hand, is like climbing a cliff: You're exposed to everything as soon as you start learning. That's all the Rust things (memory safety model and borrow etc) plus the rest of the knowledge that you need to lea…

Good point about the learning curve. I don't think Rust is especially difficult overall, but you need to understand a lot before you get anywhere. Haskell kind of have the same problem, where you need to understand advanced features like monads before you can even write hello world.
Post reply on HN