Live data from Hacker News

Why I’m dropping Rust

medium.com

111–120 of 164 posts

Re: Why I’m dropping Rust

#111

I don't know anything about Rust itself but I find it amusing that the author thought that six months should have been more than enough time for the community to agree on and implement a nontrivial change in how the language works.

Yeah. As a non-Rust developer I was reading the post with some interest and a little sympathy until I saw his timeline.

"Right, so they've been working on this potential change since 2016, and...wait. 2016?!"

If he'd said 2014 or earlier, I'd consider him to have a point. 2015 is asking for a bit too much, but I can still see his frustration; I'd call that a wash. But 2016? It destroyed his credibility with me, because it's clear he has no idea what he's talking about when it comes to developing a programming language.

I know that sounds harsh but...man. He's leaving Rust because they're taking more than six months to implement a massive change to a core language mechanic? Have fun working with absolutely any other language ever.

Re: Why I’m dropping Rust

#112
post #78

Earlier quoted context omitted.

I am fairly confident "someone" could write a composition-based UI. I know of no fundamental reason why that would be impossible, or even any more difficult than doing one with inheritance. However, that does not solve the problem that all the mature existing UI widget toolkits are based on inheritance, and that causes a serious "impedance mismatch" with languages that don't have inheritance. As I expect more languag…

Granted, current GUI toolkits are huge. On the other hand, I have worked with Qt, and this convinced me most of the complexity there was a blend of avoidable bloat and a long tail of features few people ever use (a bit like offices suites). I'm pretty sure properly written GUI toolkits can be much smaller. As in, satisfying 90% of our needs in a couple thousand lines of code. (The remaining 10% might require heaps an…

Well, I guess I ought to put this in here, rather than rewrite it :) : https://news.ycombinator.com/item?id=12410471

The "long tail" is like the long tail of Excel or Word; yeah, everybody only uses 5% of it but everybody uses a different 5%.

Re: Why I’m dropping Rust

#113

I've picked it up and put it down a few times now. It is super humbling to feel like I've been reset to total newb status after decades of work with software, including OO, imperative (with and without GC), declarative and functional languages. I'm still interested and motivated to learn more. I hope to get a chance to spend time on it at work because a free hour here and there isn't enough for me to absorb this stuf…

My thoughts exactly. My confession: I've fought the borrow checker and lost a few times, and just scaled back what I wanted to do, so far. Maybe someday I'll know what I'm doing :-) but I do like it so far, certainly more than C++.

Just keep plugging away and finish something. It took me three projects to get to the point where the cognitive load of what I no longer had to worry about exceeded what I had to worry about.

It's hard to describe, and to say "if it compiles, it works" is not 100% accurate, but I would say "if it compiles, it works, and if it doesn't work, then I know it's my own logic error". It's like Rust guides you into the space of correct solutions and cleaner code when compared to other languages.

The other thing: there are huge dividends you reap from spending time in Rust that are realized when you go back to other languages. If you've spent your life in managed runtimes or more loosely-typed languages, you come away better for the time spent in Rust.

Re: Why I’m dropping Rust

#115
post #4

Rust seems to be a poor match for the way the author wishes to solve this particular problem. That doesn't mean that their design is wrong, or that Rust is wrong, but it does mean that mixing the two would require rethinking parts of the design. > So a trait can define abstract functions, but can't access any underlying fields. In Rust, a trait is a purely abstract interface to a type. It explains how you can use tha…

The solution is to implement guis with composition and delegation rather than inheritance. It requires some ree-thinking and elbow grease, rather than just copying stale designs from 30 years ago, which may be why so many people avoid it, though.

Re: Why I’m dropping Rust

#116
post #94
post #75

Earlier quoted context omitted.

> Given that Rust was designed by a group known for writing web browsers, how does that work out in practice, given that the DOM is a deep bidirectional graph? I believe that the JS engine has ownership over the DOM, and pointers into the DOM are GC'd by the JS engine. This is part of the motivation for adding hooks for GC's in Rust. These posts [1][2] discusses this, although I think there is a more recent one. Edit…

Meh. Using Weak Types for this would be circumventing the ownership system to say what you mean and maintain it by hand. Indeed I believe the Rust Language is essentially stating that you can't manage these things by hand but a computer can. The road to hell is paved with good intentions, and I know myself and my cohort well enough that I appreciate the Rust sentiment on this subject. It was the main feature that dre…

Each component could have it's environment passed in when called, rather than needing a back pointer. This also simplifies unit testing!

Re: Why I’m dropping Rust

#117
post #111

I don't know anything about Rust itself but I find it amusing that the author thought that six months should have been more than enough time for the community to agree on and implement a nontrivial change in how the language works.

Yeah. As a non-Rust developer I was reading the post with some interest and a little sympathy until I saw his timeline. "Right, so they've been working on this potential change since 2016, and...wait. 2016?!" If he'd said 2014 or earlier, I'd consider him to have a point. 2015 is asking for a bit too much, but I can still see his frustration; I'd call that a wash. But 2016? It destroyed his credibility with me, becau…

Yeah, most of criticisms I've seen of Rust (ergonomic issues, benchmarks, compile time, even integer overflow) will be dealt with in time. 1.0 means that Rust is stable but lacking features.

Re: Why I’m dropping Rust

#118
post #111

I don't know anything about Rust itself but I find it amusing that the author thought that six months should have been more than enough time for the community to agree on and implement a nontrivial change in how the language works.

Yeah. As a non-Rust developer I was reading the post with some interest and a little sympathy until I saw his timeline. "Right, so they've been working on this potential change since 2016, and...wait. 2016?!" If he'd said 2014 or earlier, I'd consider him to have a point. 2015 is asking for a bit too much, but I can still see his frustration; I'd call that a wash. But 2016? It destroyed his credibility with me, becau…

> Traits as a concept have been part of the language for numerous years. It's currently September 2016.

Reads to me like he is disappointed that they didn't start the process sooner and have just recently started to discuss a solution.

Re: Why I’m dropping Rust

#119
post #32

Earlier quoted context omitted.

> > What IS the idiomatic Rust way to do a cyclical directed graph? > Unfortunately, the correct idiomatic way is that you try very hard to avoid doing so. Rust is all about clear ownership, and it doesn't like circular references. > The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code. The point about C++ is important. Cyclic graphs are hard in any…

The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code. That indicates a fundamental design flaw in the language.

No it doesn't.

It indicates that idiomatic Rust doesn't like cyclic references and thus you must step outside safe, idiomatic Rust to do that, it really just means that every language has an idiomatic way to do things to stay on that idiomatic road and not every way of doing things fits the idioms - they're still possible but not idiomatic. Given how the ownership system works, it makes sense

You may say that that indicates a flaw in the ownership system, but it doesn't. The ownership system can do certain things, but not all of them - it's designed to prevent the majority of common memory safety violations, but if it can't prove everything. That doesn't indicate a design flaw, it indicates a system limitation, same way a GC pause it's not a design flaw, but rather a limitation of a well deigned system.

Re: Why I’m dropping Rust

#120
post #5

The author seems to be confusing typeclass composition with OOP. They are only topically similar. (Personal opinion; typeclass composition is more principled than OOP, but a bit more rigid, which he is running into.) There are several good ways to do this with type classes/traits. One way is to write a function font_size : Widget t => t -> FontSize And then in the widget definition have the "internal" font size defin…

> The author seems to be confusing typeclass composition with OOP. I agree and would like to expound on that idea. One of my biggest frustrations with inheritance in traditional statically typed languages (I program in C++ for a living) is that inheritance is performing two functions at once: code reuse and typing. Confusing the two seems to cause a lot of pain. Inheritance as a type system is describing the kinds of…

This sounds like a failure of the Rust documentation.
Post reply on HN