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

#91

Post by MaulingMonkey » Tue, Oct 23, 2018, 3:32 AM UTC

dxhdr wrote: post #82

user111233 wrote: post #79

Earlier quoted context omitted.

I have never felt a typed language slows me down. In a dynamic language you still have to mentally understand what the type of a function is. You can't just throw any data in to it and have it work.

> In a dynamic language you still have to mentally understand what the type of a function is. You can't just throw any data in to it and have it work. JavaScript would like a word with you.

If you could just throw any data into JavaScript functions and have it work, we wouldn't need TypeScript.

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

#92

Post by steveklabnik » Tue, Oct 23, 2018, 3:33 AM UTC

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…

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.

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

#93

Post by MarkovUnchained » Tue, Oct 23, 2018, 3:35 AM UTC

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.

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

#94

Post by coder543 » Tue, Oct 23, 2018, 3:37 AM UTC

charliesome wrote: post #77

coder543 wrote: post #10

Earlier quoted context omitted.

Rocket requires the nightly Rust compiler, which isn't something I find acceptable for production applications, and it's synchronous, so it's really slow. I have been rather disappointed by what I perceive as the author's unwillingness to work towards stable Rust. They have a GitHub issue where they track all of their dependencies on nightly, and kind of just say they aren't going to do anything about it -- it's up t…

> and it's synchronous, so it's really slow. > it's asynchronous (so it's really fast) Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.

I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow.

Suppose you have a synchronous web server with 4 threads, synchronous naturally means that each thread can only handle one request at a time. Each request can take dozens or hundreds of milliseconds to complete, just by being bottlenecked on latency. If it takes 100ms to complete each request, that server can only handle 40 requests per second.

If that server were asynchronous, each thread could handle thousands of simultaneous connections, making the performance literally thousands of times better at a minimum.

If you suggest spinning up an unlimited number of OS threads, that's quickly going to run into problems because most OSes can only handle a couple of thousand threads before you start running into OS limits that you have to adjust, knobs for which aren't always easy to find, and even then, each thread takes a significant amount of time to start and stop, as well as much larger amounts of RAM.

An alternative solution is green threading, which Go calls Goroutines, for example. In such a system, the asynchronous operations are handled by the underlying runtime and your code can treat them as synchronous and just spawn new "threads".

If you disagree, I would love to hear a more detailed response, because I can't see how your claim could be true.

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

#95

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

bb88 wrote: post #89

ilovecaching wrote: post #80

Earlier quoted context omitted.

> I don't mean to burst your bubble here. You won't. > 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. This is relative. Rust is far easier to learn than C++. It has a compiler that will even enforce that you don't shoot yourself in the foot. It also has nice tooling to get you up and running quickly. It has good document…

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…

Python is growing because it's a good scripting language, and there's a need in the ML community for a standard language to write scripts in. The ML community is growing like crazy, thus Python grows. Even though Python is secretly calling Fortran for scipy, or Tensorflow (C++), or PyTorch (also C++), all of which would make good candidates for Rust replacements. So obviously speed is necessary to enable what people are doing in Python.

I make the distinction between script and what we software engineers do, because I had the misfortune of spending half a decade in research doing ML, and those guys are not writing production programs. They're hacking out Jupyter notebooks and writing precariously balanced code that barely works.

That doesn't make Python suitable for large applications. It doesn't diminish the fact that CUDA is growing, SGX is growing, embedded is growing, that we're now unlocking 100G fiber, that we've reached the limits of single core performance, that intel is rolling out 8+ core consumer CPUs. Python is not going to shine for any of these things, but Rust will.

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

#96

Post by village-idiot » Tue, Oct 23, 2018, 3:46 AM UTC

bb88 wrote: post #89

ilovecaching wrote: post #80

Earlier quoted context omitted.

> I don't mean to burst your bubble here. You won't. > 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. This is relative. Rust is far easier to learn than C++. It has a compiler that will even enforce that you don't shoot yourself in the foot. It also has nice tooling to get you up and running quickly. It has good document…

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 compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.

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

#97

Post by weberc2 » Tue, Oct 23, 2018, 3:46 AM UTC

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.

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

#98

Post by bb88 » Tue, Oct 23, 2018, 3:47 AM UTC

steveklabnik wrote: post #88

dman wrote: post #83

Earlier quoted context omitted.

I think Rust should stop looking at C++ as the becnhmark / comparison point for complexity. The expectations that developers have from languages has increased over time, and Rust itself has contributed to raising that bar.

We don’t generally consider other languages as a measure of what complexity is “okay” or something, and are extremely aware of Rust’s complexity. Rust has a lot of requirements that directly lead to a lot of that complexity. But it’s neccesary , not incidental. Or that’s the hope, at least. Rust is also not perfect.

A lot of (but not all) complexity is solved in C/Python/Java by throwing a data structure at the problem. But is it a fair statement to say that not all data structures will work in Rust? Or is it better to say that some data structures work better in Rust than others?

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

#99

Post by village-idiot » Tue, Oct 23, 2018, 3:48 AM UTC

dbcurtis wrote: post #85

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…

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

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

#100

Post by xyzzy_plugh » Tue, Oct 23, 2018, 3:50 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…

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

> Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.

I think that was very much the intent. 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.

Go is a _systems_ language at heart. It focuses on maintainability and literacy, and that's where it leads the pack in my eyes. It's possible to squeeze pretty phenomenal performance out of such a simple language. It's easy to drop into assembly for ultimate optimizations.

Perhaps generality is a mistake? I don't miss it. I've never found joy in debugging someone else's generalized metaprogramming.

Building software at serious scale has led me to appreciate the wisdom buried within Go. It's boring and I love it.

I've written a bit of Rust (and a lot of C++) which I find enjoyable enough, but they're tools I rarely find myself reaching for.