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

Four years with Rust

words.steveklabnik.com

Post reply on HN
Print view View original

161–170 of 199 posts

Re: Four years with Rust

#161

Post by olauzon »

bjz_ wrote: post #139
olauzon wrote: post #78

Earlier quoted context omitted.

I've been using Rust to process fairly large amounts of streaming financial data. I am using Protocol Buffers (and evaluating Cap'n Proto) for network serialization and Kafka for buffering/queuing, and overall the library support is quite good. Previously I was using JVM languages for this purpose, but grew weary of the resource footprint, and especially the unpredictable GC pauses. I am aware of the Azul JVM which r…

How easy is it to get Kafka and Rust working together?

Fairly straightforward overall using https://crates.io/crates/kafka. The client doesn't automatically handle Kafka node failures, so that's the responsibility of your application code.

I haven't had the chance to try https://github.com/fede1024/rust-rdkafka yet, but it looks promising and partially wraps the C/C++ library https://github.com/edenhill/librdkafka.

Re: Four years with Rust

#162

Post by mikekchar »

cyphar wrote: post #77
wyldfire wrote: post #27

Earlier quoted context omitted.

> So yeah. Rust definitely has problems for beginners. IMO Rust has the challenges that are very similar to all other languages have. But if you are trying to make the leap from a GC'd language like Java or Python to Rust without ever having written C/C++, you should expect to have to learn not only new language concepts but new programming concepts.

I'm a programmer that has been using C for at least 8 years, and I've been developing in Go for the past 4 (as well as a couple of years of Python here and there). The point is that I have experience in quite a few programming languages, and I am familiar with the programming concepts you're referring to. I do not agree that Rust's challenges are the same challenges with other programming languages. Because Rust will…

I had a similar problem with the type system in Haskell. I'd look at Haskell code and it was obtuse to me. Even reading books, it was hard for me to understand some stuff until I started writing code... but writing code was difficult because I didn't understand it.

For me the key was just doing toy problems over and over again. Without understanding the idioms, it's hard to dive in and write something real. I think Rust is approachable if you take it like that (or at least it was when I looked at it about 2 years ago).

Re: Four years with Rust

#163

Post by [deleted] »

ivoras wrote: post #26

There was a new Hurd version announcement a few days ago and somehow Rust reminds me of Hurd, but from a different direction: it seems to me that Rust simply changes way too much to be currently widely accepted at any scale, and has a high rate of attrition because of that. Statements such as "But as of Rust 1.15, this restriction will be lifted, and one of the largest blockers of people using stable Rust will be eli…

[deleted]

Re: Four years with Rust

#164

Post by Annatar »

In today’s Rust, this would be an error, you need to write (e.f)(); At least the error tells you exactly what to do!

If the programmer knows what the error is, and how to correct it, then their program should automatically do so, rather than molesting the user, as the purpose of computers is to speed up and automate. Why should the user have to foot the designers' bills?

Another cardinal sin and a sign of lack of thinking things through is breaking backward compatibility, like the example above: imagine you were an early Rust adopter, and wrote a non-trivial application in Rust; now imagine that the newest Rust compiler has several major performance and efficiency gains. It is understandable why one would want to re-compile one's application with the newest compiler, only to be thwarted by the authors' lack of understanding of just how important not breaking users' applications is. That is one of the core differences between engineering and hacking. What other land mines await potential Rust adopters from programmers who do not have any respect for their users' time?

Re: Four years with Rust

#165

Post by gedrap »

prewett wrote: post #134
losvedir wrote: post #116

Wow, four years already. Maybe you can help settle this question I've had. I'm a rubyist (like you were/are, and wycats, and a bunch of rustaceans), and I think that sort of drove my interest in rust. But after 4-5 years of ruby the dynamism which initially was super cool, has grown a little frustrating and I long for a more sophisticated type system and a compile step, since frustrating bugs crop up from time to tim…

Are you talking about strong typing or static typing? I've been using statically typed languages for 20 years (C++, Java, Objective-C) and I haven't gotten tired of it yet. Especially when working in a large code-base I didn't write, Python is rough. What's a "session"? Who knows, guess I'd better put `print type(session)` and figure out how to get that function executed. Although, the thing that bothers me about Pyt…

> until you execute that line of code to make sure there wasn't a misspelled variable name or something

But isn't it the purpose of tools such as IDEs? PyCharm is pretty damn good at it. Of course, it's not always possible or convenient firing up an IDE. But I suppose editors such as vim should be fully capable of doing this via plugins as well.

Re: Four years with Rust

#166

Post by MaulingMonkey »

raphlinus wrote: post #137
Manishearth wrote: post #130

Earlier quoted context omitted.

Note that you don't need a GC to do that; the allocator can do it for you. A lot of folks think that optimizations like having allocation arenas and spreading out deallocation pauses are unique to garbage collectors, but they're completely orthogonal to GC. You can have GCs with these optimizations, and GCs without. You can have regular allocators with these optimizations, and regular allocators without. Jemalloc doe…

An exception (large complicated Rc-trees) is the rope in xi-editor. If you load a very large file, the operation of letting go of the last reference is potentially a large enough pause to have an effect on UI responsiveness. I've considered adding a mechanism that moves the object into a deallocation thread (or a deallocation task running in a thread pool) for this reason, although I'm not sure how important it is in…

> I've considered adding a mechanism that moves the object into a deallocation thread (or a deallocation task running in a thread pool) for this reason, although I'm not sure how important it is in the grand scheme of things.

The one time I've done this in C++, delayed deallocation actually made major loads/unloads worse for us on mass batch operations - more cache thrashing perhaps? Since this involved GPU resources, perhaps some bad interaction with the driver? I did keep around the "optimization" conditionally for smaller operations as this let us get rid of some hitching.

> In a GC'ed language such as Go, this would not be a problem.

In C# this traditionally manifested as lengthy GC pauses you had to jump through hoops to workaround. Modern GCs are much better these days, but it's not 100% solved.

Re: Four years with Rust

#167

Post by sowhatquestion »

I'm highly curious about Rust as a potential introduction to systems programming. One thing that bothers me is the lack of proper classes. This seems to have become a trend among newer languages, as though traditional OOP is an outdated paradigm.

I have yet to be convinced that this is a good move. The attempted justifications I've seen hand-wave about problems with OOP, "composition over inheritance," etc. Meanwhile, in the real world, 99% of production code is OO and the paradigm continues to do its basic job--helping programmers model domain objects. Older languages like JavaScript and PHP have made their OO constructs more robust over time, which suggests to me that in the end a critical mass of developers will always clamor for this easily understandable and productivity-enhancing paradigm over some theoretically pure alternative.

Re: Four years with Rust

#168

Post by kinghajj »

Annatar wrote: post #164

In today’s Rust, this would be an error, you need to write (e.f)(); At least the error tells you exactly what to do! If the programmer knows what the error is, and how to correct it, then their program should automatically do so, rather than molesting the user, as the purpose of computers is to speed up and automate. Why should the user have to foot the designers' bills? Another cardinal sin and a sign of lack of thi…

> If the programmer knows what the error is, and how to correct it, then their program should automatically do so, rather than molesting the user

But then the meaning of that syntactic construct differs contextually. Even if it could be parsed efficiently, it still goes against Rust's principal of favoring explicitness over convenience.

> Another cardinal sin and a sign of lack of thinking things through is breaking backward compatibility,

The examples Steve cited span throughout Rust's history, way before any commitment was made to backwards-compatibility. These sort of changes won't happen anymore (it'd require a "Rust 2.0").

Re: Four years with Rust

#169

Post by oblio »

steveklabnik wrote: post #22
Lev1a wrote: post #18

Earlier quoted context omitted.

There is also the possibility that a Rust 2.0 could fragment the community much like with Python2.7 Python3.x, which would be "undesirable" at best.

Yes, a split like this would be undesirable to say the least. Not to mention that systems people are used to near-total backwards compatibility; any sort of near-term timeframe for such a thing would destroy a lot of our credibility, in my personal opinion. I'm on team "never 2.0". We still have some desire to indicate "epochs" of Rust development, as undoubtedly, things like idioms will change over time, new librari…

Maybe compiler profiles? So that a project can say -rust2018 and disallow bad practices from pre-2018?

Re: Four years with Rust

#170

Post by pka »

sowhatquestion wrote: post #167

I'm highly curious about Rust as a potential introduction to systems programming. One thing that bothers me is the lack of proper classes. This seems to have become a trend among newer languages, as though traditional OOP is an outdated paradigm. I have yet to be convinced that this is a good move. The attempted justifications I've seen hand-wave about problems with OOP, "composition over inheritance," etc. Meanwhile…

So what is it that you need classes for that dearly?
Post reply on HN