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

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

#101

Post by ilovecaching » Tue, Oct 23, 2018, 3:56 AM UTC

weberc2 wrote: post #97

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 imagine the learning curve is a lot more manageable when you have an office full of full time Rust developers. If you’re on your own you become painfully aware of how often you need to solicit help, and the time it takes to familiarize someone else with your problem over chat or forum post really eats away at one’s motivation.

Well the Rust community is super welcoming, and the meetups have been really positive. They even have the #rust-beginners channel. :)

I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it".

Rust is a language that rewards understanding, and stops you from making mistakes when you don't know how things are actually working. This is a revolutionary plus. At the end of the day, Rust's rules are what other languages enforce through convention and the school of hard knocks.

After all, is that not the point of computing? To have the computer check things for you that a human is prone to error on?

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

#102

Post by ilovecaching » Tue, Oct 23, 2018, 4:00 AM UTC

village-idiot wrote: post #96

bb88 wrote: post #89

Earlier quoted context omitted.

See the thing is that I agree with most of your statements, so you're really not changing my mind with your arguments. > Actually companies are becoming more aware that speed is a feature No. If that were true, Python wouldn't be the fastest growing language, and we'd be hand optimizing everything in assembly and using languages that allowed us to do that (C). That was the entire point I was making. It's why Java won…

Speed matters, it’s just that it’s far from the top priority. All else being held equal, developers and stake holders will choose the faster language, it just makes sense. The trick is that speed is typically seen as diametrically opposed to usability, since quite a few languages achieve speed by turning all the safety rails off or existing way too close to the metal for comfort. If rust could deliver speed without c…

Safety and speed are the big words on the box. Usability is harder, because it's somewhat a matter of opinion. As someone who has professionally worked with the expression based Haskell, Erlang, Elixir, and OCaml, I find Rust to extremely expressive. If you come from that camp and feel that OOP is a bad toolkit of abstraction and that higher order functions, typeclasses, type parameters, and ADTs are much more powerful, then I think yes, Rust ticks all the boxs.

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

#103

Post by relyio » Tue, Oct 23, 2018, 4:00 AM UTC

ilovecaching wrote: post #69

erwan wrote: post #67

I love Rust, but in all honesty I wouldn't use it vs. Golang or C++17 for something that isn't a critical system (e.g a cryptography lib) and even then I'm not sure I wouldn't use something like OCaml instead. The curve to productivity seem way too steep for the payoff.

Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge . It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to…

>First, Go and C++ are vastly different languages.

Yes, the point isn't to say that they are similar. Quite the contrary in fact, they are different enough that they compliment well. If I have to do latency sensitive systems work I would use C++17. It's good enough, has useful constructs, and all-in-all, rather easy to write.

It's nice to have stronger static safety but they usually displace the cost somewhere else. AFAIK, Rust becomes extremely touchy when you start inter-operating with abstractions the borrow-checker is not omniscient about. Wrapping code in unsafe{} everywhere feels clunky. That's not my biggest peeve though. Programming complex systems is an iterative process for me. I prototype, go back, throw it away, rewrite, until requirements are met and so on. I don't feel like I would be productive doing that in Rust. I don't care for safety for as long as the software prototype is complete enough. In that phase of development, what I care about is a compromise between velocity, performance, and safety.

The only thing I really miss in C++ is powerful type-system: GADTs and all. But again, if I find that I need those I would use a language that truly excels at that, OCaml.

For anything else, I found Golang to be a terrific fit.

It is easy to on-board new people and have them get productive and feel empowered enough to push change. The building blocks are easy and compose well.

Yes, I agree the lacks generics of generics can be frustrating, especially when software grows. On the other hand, it can get old really fast to debug templated software.

As for GC, it might not use fancy algorithms but from empirical experience, having worked with a wide-range of different applications with different workloads, I found that GC pauses are short and hardly ever an issue. I wouldn't use to write a RTOS but for most usage it's fine and a net positive in productivity and quality.

>Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits

It rose to popularity because it fills a huge niche. My job is to build robust systems that do their job and deliver business value. It's easy to maintain Go code, it's easy to understand, and provides the right amount of static safety most of the time. I find Golang to be a humble and honest language, a productive C.

Rust is cool but not worth it for me.

>No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++.

If I had a dollar every time I had read that (replace Rust by Haskell/Erlang/Lisp/Whatever language the cool hip kids use).

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

#104

Post by bb88 » Tue, Oct 23, 2018, 4:01 AM UTC

village-idiot wrote: post #96

bb88 wrote: post #89

Earlier quoted context omitted.

See the thing is that I agree with most of your statements, so you're really not changing my mind with your arguments. > Actually companies are becoming more aware that speed is a feature No. If that were true, Python wouldn't be the fastest growing language, and we'd be hand optimizing everything in assembly and using languages that allowed us to do that (C). That was the entire point I was making. It's why Java won…

Speed matters, it’s just that it’s far from the top priority. All else being held equal, developers and stake holders will choose the faster language, it just makes sense. The trick is that speed is typically seen as diametrically opposed to usability, since quite a few languages achieve speed by turning all the safety rails off or existing way too close to the metal for comfort. If rust could deliver speed without c…

> If rust could deliver speed without compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.

It has to be more than safe and fast. It has to be a productive language to use. A dev can't sit for 6 months trying to figure out how to write a website, when he can pick up RoR and do it in a day.

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

#105

Post by ilovecaching » Tue, Oct 23, 2018, 4:03 AM UTC

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.

Rust is based on ADTs, typeclasses, and type parameters. C++s toolkit for abstraction is templates and OOP. They're completely different, and it sounds like you're just trolling anyway.

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

#106

Post by weberc2 » Tue, Oct 23, 2018, 4:08 AM UTC

cdoxsey wrote: post #62

dev_dull wrote: post #57

Earlier quoted context omitted.

How does your team (E.g., the people on the hook for reviewing/supporting/contributing to your project) feel about the change? This is a big difference when moving from Go. A language that nobody calls beautiful, but is very easy for a team to contribute to and support (relative to other languages).

I don't think that's fair. I'm not entirely sure what beautiful means for a programming language, but I've seen many examples of Go programs which exhibited a beautiful simplicity. This project for example: https://github.com/inconshreveable/slt .

I think it’s different kinds of beauty. When I write Go, my good programs are “beautiful” for how simple they are; it’s relatively difficult to over-abstract. It’s the rugged practicality.

The other kind of beauty is a quest for an abstraction that makes everything conceptually simple—once you understand the abstraction. It’s more of a mathematical elegance thing, and it’s just gravy if it happens to solve a real world problem.

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

#107

Post by weberc2 » Tue, Oct 23, 2018, 4:24 AM UTC

ilovecaching wrote: post #69

erwan wrote: post #67

I love Rust, but in all honesty I wouldn't use it vs. Golang or C++17 for something that isn't a critical system (e.g a cryptography lib) and even then I'm not sure I wouldn't use something like OCaml instead. The curve to productivity seem way too steep for the payoff.

Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge . It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to…

> Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap

Man, stating your opinions as fact is one thing, but every other claim you made above is empirically incorrect. Rust is a fantastic language on its own merits; no need to make stuff up about “the competition”.

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

#108

Post by GolDDranks » Tue, Oct 23, 2018, 4:27 AM UTC

hyperpallium wrote: post #71

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…

> "can we have speed, correctness, and expressiveness in one language?" Didn't ocaml already answer that question? Since ocaml hasn't dominated, it seems something more is required... What has rust got beyond that?

Threads and predictable runtime model. (No GC)

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

#109

Post by ilovecaching » Tue, Oct 23, 2018, 4:29 AM UTC

xyzzy_plugh wrote: post #100

ilovecaching wrote: post #69

Earlier quoted context omitted.

Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge . It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to…

> Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stabi…

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

It really bothers me when people say this, because it's just untrue regurgitation from the Go team. It's not a systems language. It's a language that's pretty good for small web services. It has expensive interop (Solomon Hykes commented on this during one of his Gotime interviews) with C (even the Go team says cgo is not Go).

> It's easy to drop into assembly for ultimate optimizations.

You can only drop down into Plan 9 assembler, which is essentially useless. Write me an SGX lib without cgo in x86 and you can make that claim.

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

#110

Post by weberc2 » Tue, Oct 23, 2018, 4:31 AM UTC

tech2 wrote: post #25

vmchale wrote: post #20

Earlier quoted context omitted.

What are you serving? Some of the Rust frameworks for backend should be able to do more than 1000req/s, but it depends what you're doing.

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?