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

#211

Post by imtringued » Tue, Oct 23, 2018, 12:33 PM UTC

ernst_klim wrote: post #193

GolDDranks wrote: post #108

Earlier quoted context omitted.

Threads and predictable runtime model. (No GC)

Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.

You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a time critical section of code it is not affected by other threads making allocations. This is what a predictable runtime model is.

Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model.

What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust.

[0] https://doc.rust-lang.org/1.1.0/arena/index.html

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

#212

Post by sanderjd » Tue, Oct 23, 2018, 12:48 PM UTC

bb88 wrote: post #117

sanderjd wrote: post #81

Earlier quoted context omitted.

I always found it easier to improve the time waiting for postgres by tuning critical queries than to track down runaway memory usage and tune garbage collection. I also felt like I spent a lot of my wall clock time during active development waiting for apps to start up and run tests or whatever. There are best practices which speak to most of this, but they were hard won.

But that doesn't come for free with Rust. You still have optimize the DB. And then does it really matter which language you use, since the DB is still going consume most of the time generating a web page anyway, right?

My point was that I found the database to be the easier bottleneck to optimize. The other bottlenecks I mentioned, which I found more difficult to optimize - memory usage, GC, and startup time - are things for which Rust has a good story.

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

#213

Post by ernst_klim » Tue, Oct 23, 2018, 12:49 PM UTC

imtringued wrote: post #211

ernst_klim wrote: post #193

Earlier quoted context omitted.

Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.

You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a…

>The unpredictable aspect is the stop the world pause caused by garbage collection.

As well as malloc pauses on deallocation. The only way of using your memory in realtime apps is preallocation, which often can be done in languages with GC too, it would be just very inconvenient.

At the moment custom allocation support in rust is a joke if you compare it with Ada or C++, and Box is not better than GC in this regard.

>Unstable

Besides it's very inconvenient to use. Does Box/Rc/Arc support this arena allocator, as C++'s smart_pointers do?

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

#214

Post by tech2 » Tue, Oct 23, 2018, 12:53 PM UTC

the_duke wrote: post #197

tech2 wrote: post #143

Earlier quoted context omitted.

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…

What web framework are you using? Are you using a database? If so, which one? Are you using a cache like Redis? I agree that a 2x speedup is a terribly low for a Python to Rust rewrite and shows that Python is unlikely to be the relevant bottleneck here.

actix/r2d2 on the Rust side (I haven't worked out bb8 yet), aiohttp/uvloop/asyncpg/gunicorn on the Python side (Postgres for the DB). This kinda _is_ the cache at present, it's a distillation of a lot of other data into a given form. Rust's async story re: databases still looks a little up-in-the-air right now from an outside perspective though, so I guess I'll wait and see how it pans out.

It's definitely a work in progress and I didn't expect this much interest in my offhand "I tried Rust even though I couldn't see myself using it for real, but..." comment.

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

#215

Post by antaviana » Tue, Oct 23, 2018, 1:02 PM UTC

olavk wrote: post #199

iopq wrote: post #173

Earlier quoted context omitted.

Okay, tell me if this is readable to you: fn accumulate (tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> T where T: From + From , this is JUST the function signature yes, every single thing in there is necessary, it can be written in a more gruesome way, but the where clause clarifies it a bit But let me cheat a little bit ( $(#[$attr:meta])* enum $enumer:ident { $($i:ident => $e:tt $( ( $($m:ident),* ) )* ; )* }…

It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.…

This also reminds me that, in Python 2.x, the following code...

for i in range(100000000):

...creates in memory a list with one-hundred million integers.

Expressive yes, but sometimes it can be double-edged for new comers (and not new comers).

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

#216

Post by weberc2 » Tue, Oct 23, 2018, 1:04 PM UTC

ilovecaching wrote: post #115

weberc2 wrote: post #107

Earlier quoted context omitted.

> 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, sta…

> it's performance is closer to Java Go vs Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Go vs C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > pushing outdated concepts like null and raw pointers on to the programmer I mean this is just a fact. Are you disputing nil and *? > it has a runtime with a stop the world GC https://blog.golang.org/ismmkeynote "On the Y axis we hav…

The benchmarks game is just that: a game. Notably, Go programs are prohibited from doing certain optimizations that are permissible for C++ programs. The conventional wisdom is that Go and Java are within the same order of magnitude as C++ though still slower. I’d accept that they are a full order slower, but not multiple orders.

> Do you dispute nil and *

I dispute that Go’s pointer is a “raw pointer” in any meaningful sense of the word. In C++, raw pointers may be uninitialized, they may be cast from any int, they don’t imply any automatic cleanup of the pointee, and they are subject to pointer arithmetic—none of this is possible with Go pointers except via the “unsafe” package. So basically none of the criticism of raw pointers applies to Go pointers.

> Go has a stop the world GC

You are correct here, Go has a stw GC. It’s probably not suitable for RTOS, but its pauses are on the order of microseconds, so most of the conventional GC criticism doesn’t apply.

> Stack vs heap

The language doesn’t have semantics for stack vs heap allocation, but that doesn’t mean it’s hard to control where things are allocated. In particular, the compiler can spit out where its allocating and you can adjust accordingly. It’s far easier to do this in the hot path than to have to specify where every piece of memory is allocated across your program.

> seems like you’re empirically incorrect

Quite the opposite, actually. There’s nothing wrong with not knowing or being mistaken, but there’s no need for overt snarkiness.

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

#217

Post by fiedzia » Tue, Oct 23, 2018, 1:15 PM UTC

solidsnack9000 wrote: post #121

bb88 wrote: post #73

Earlier quoted context omitted.

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

Despite Java's growth, C remains the language of choice for operating systems and C++ for web browsers, desktop applications, games and high performance web services. Rust is really only competing with C/C++, not JavaScript or even Java (or Go).

> Despite Java's growth, C remains the language of choice for operating systems and C++ for web browsers

Does it? Existing project use what they have chosen long time ago, we can only discuss choice for new ones. And new OSes often choose something else. I am not aware of any new webbrowser, so can't say anything about that.

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

#218

Post by bluejekyll » Tue, Oct 23, 2018, 1:50 PM UTC

nevi-me wrote: post #90

bluejekyll wrote: post #55

Earlier quoted context omitted.

The issue isn't exactly that it's not ready for prime time, but that it's not ergonomic at the moment. The biggest issue that you have to get used to is that pretty much everything has to be owned data, and no references passed around when constructing Future types. This can feel like it comes into conflict with the poll(&mut self) interface (in 0.1). Also, I found truly understanding the fact that returning data fro…

One of the challenges I'm having now is with some library that connects to a steaming pubsub server. I found a problem with the library, my use-case differs from what's being tested, and because I'm struggling to use the library the way the author suggests; I'm unable to convince them that being unable to Clone their data structure is causing a problem. I unfortunately am not at the point of "X didn't work, so I wrot…

Sometimes there are good reasons for not cloning, such as underlying resources that can’t be cloned. But I agreed it can be ergonomically easier in many cases. If they truly don’t want it, and you really don’t want to fork, can rewrapping it in an Arc or Arc> get you around the problem?

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

#219

Post by Dowwie » Tue, Oct 23, 2018, 2:04 PM UTC

jayflux wrote: post #158

Dowwie wrote: post #64

Earlier quoted context omitted.

It's web ready. It's very web ready.

Woah, I’m a big fan of rust, but saying it’s web ready is disingenuous. Rocket isn’t stable, most of the libraries rocket depends on aren’t stable either. Making http requests.. are there any stable http libraries yet? Last I checked Hyper was still on a 0 release with no h2 support. Rust has conquered a lot, but it’s web service/API story is not complete yet. Go is ahead in this respect.

Check out actix-web: https://actix.rs

Does my proclamation still seem disingenuous to you? If so, why?

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

#220

Post by crimsonalucard » Tue, Oct 23, 2018, 2:36 PM 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…

C++ itself is not just overly complicated. However, in addition to that, C++ promotes object orientation. Design patterns add an additional layer of complexity for new grads to plow through.