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

Why I’m dropping Rust

medium.com

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Why I’m dropping Rust

#141

Post by exadeci »

skywhopper wrote: post #10

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.

Add to that, that the author is an Electrical Engineer.

Not that it's a bad thing but if he does programming as a hobby it means that he only used it a few hours a day for 6 months.

I don't quite understand why HackerNews gave so much importance to some random developer opinion on Rust.

Re: Why I’m dropping Rust

#142

Post by solidsnack9000 »

> However, a trait has no knowledge of the underlying implementation. So a trait can define abstract functions, but can't access any underlying fields. > ... > Let that sink into you. My first reaction to this was "Sorry, what?!". While there are valid criticisms against OOP, to offer this as a solution is just silly.

This is a misunderstanding of what traits do. Interfaces in Java have no knowledge of the underlying implementation, either. And more generally, neither does an ABC: you can't use fields you don't declare in the ABC in methods declared in the ABC.

It is sad that Rust traits can declare only functions, not fields; so you must redeclare your fields as methods if you want to be able to use them as part of a default implementation (I think). Later the author explores this option -- but notes the "field methods" must be public along with the real interface of the trait. I am not sure what options Rust provides for making them private. For example, it might be possible to split the trait into a public and a private half. (But maybe not: https://github.com/rust-lang/rfcs/blob/master/text/0136-no-p...)

I do question the wisdom of the author's design at a higher level, because the author is using a trait for provide an implementation, not just an interface. If the implementation really applies to everything that matches the trait, it should probably be provided with a generic. If not, it is at worst tedious, but hardly limiting, to recycle a generic definition by calling it in an implementation.

Re: Why I’m dropping Rust

#143

Post by mercurial »

loup-vaillant wrote: post #62
mcguire wrote: post #54

Earlier quoted context omitted.

Ocaml has a GC and supports class based inheritance, right?

> Ocaml has a GC Yes, but the language is immutable and eager by default. That makes circular references a chore. > and supports class based inheritance Yes, but hardly anybody uses that part of the language. We tend to stick with modules and variations over them.

Actually, I think most of the OCaml GUI libraries (lambda-term, for instance) do use objects and classes, because it makes sense in that context.

Re: Why I’m dropping Rust

#144

Post by cfallin »

firebones wrote: post #113
chris_st wrote: post #96

Earlier quoted context omitted.

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…

> the cognitive load of what I no longer had to worry about exceeded what I had to worry about.

Yup, this has been my experience too. I started using Rust for my primary project last March and was worried a little at first about the risk of wasting too much time, but at this point I'm ~1.5x to 2x as productive as in C++11:

* essentially no more "head-scratching action-at-a-distance bugs" (I've spent N years in C++ and I still sometimes invalidate an iterator) -- as you say, any errors that still exist are higher-level logic errors, which are (in my experience) much more straightforward to track down.

* enums and match/destructuring and all the builtin types (e.g. Option, Result) have me thinking in a much more strongly-typed and principled way. So even logic errors tend to be less frequent because I break down the problem the 'right' way immediately. Algebraic datatypes let one describe a state space really succinctly.

Rust is one of those languages that really, strongly wants you to be idiomatic, but it pays off!

Re: Why I’m dropping Rust

#145

Post by shadowmint »

loup-vaillant wrote: post #140
shadowmint wrote: post #123

Earlier quoted context omitted.

I'm pretty sure properly written GUI toolkits can be much smaller... Given that as far as I know, there are no examples of tiny fully-featured GUI libraries (it's all either trivial like cgui or a massive bloated mammoth like qt/wpf/android), isn't that a bit of a rich statement? Like, I'm sure you can write a procedural generator in a handful of lines of code that spits out the full works of Shakespeare. It's probab…

vpri.org managed to squeeze a GUI toolkit and a document format and the whole compiler toolchain required for the language (including rasterization) in about 20K lines of code, and it's fast enough to run in a laptop. I'm pretty sure we haven't explored the sheer depth of simplifications that can still be done.

Sounds cool. Got a link?

I can't find anything on their website that seems to be that sort of thing?

Re: Why I’m dropping Rust

#146

Post by leovonl »

I've been observing in some stronger critics about Rust a persistent focus on OO features, usually the ones that programmers tend to rely upon and which they feel to be "lacking" in Rust - usually requiring a different structure or abstraction which the programmer is not familiar with.

The issue about parent/children pointers mentioned in this article seems more a lack of understanding on the concepts of ownership and the traits system, for instance. It's indeed a harder problem to deal with in Rust if trying to apply a OO mentality, but one can find a way out if trying to understand the language first.

I have my personal thoughts about parts is Rust that could be improved; nevertheless, I don't see any issue with us excursions, and consider it an evolutionary step which brings system programming languages to a new level.

Re: Why I’m dropping Rust

#147

Post by topspin »

jblow wrote: post #89
ekidd wrote: post #31

Earlier quoted context omitted.

"Safe" Rust works for almost everything in a typical CS curriculum. But if you want to teach an operating systems course or build cyclic, pointer-based data structures, you'll usually need a modest amount of "unsafe" Rust. Using "unsafe" gives you access to real pointers, which work just like they do in any systems language. It's just that Rust chooses to lock those features away when you don't explicitly ask for the…

Where did you learn CS that they didn't have lots of cyclic data structures? We had those even in our intro class at Berkeley...

It occurs to me that these courses have been teaching what might (should?) be considered a naive view of memory; you show me a traditional cyclic data structure and I'll show you a concurrency bug. I suppose that's fine in 1978 when no one imagined they'd be dealing with multi-core microcontrollers, but today, when you find yourself using a "systems" language for non-toy work and you reach for a tool as sharp as a raw pointer, those naive data structures are frequently (usually?) inadequate.

Re: Why I’m dropping Rust

#148

Post by johncolanduoni »

leovonl wrote: post #146

I've been observing in some stronger critics about Rust a persistent focus on OO features, usually the ones that programmers tend to rely upon and which they feel to be "lacking" in Rust - usually requiring a different structure or abstraction which the programmer is not familiar with. The issue about parent/children pointers mentioned in this article seems more a lack of understanding on the concepts of ownership an…

What "non-OO" methods for representing cyclical data structures are you referring to? The only one I can think of is lots of indirection (e.g. how petgraph does it), which can be too slow (especially for systems programming). As far as I can tell, Rust's model for verified code is pretty hostile to cyclical structures, especially if you want inhomogeneous references (i.e. not everything is an edge on a graph). I don't think you can just sweep this under the rug as "lack of understanding" of Rust's better ways of doing things.

Re: Why I’m dropping Rust

#149

Post by steveklabnik »

xuejie wrote: post #134
skywhopper wrote: post #10

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.

While I do agree that six month is not quite long, there's another issue: in the RFC PR, most of discussions took place before Mar 27, which is 10 days after when the RFC was submitted. Then there were a few comments on on Apr 28, and nothing really happened until Aug 4, when someone mentioned they were interested in the RFC, and there only has been minor discussions after that compared to the situation before Mar 27…

  > it did seem to me that the core team is not interested in this feature.
It was proposed by a core team member, even. Changing a language takes time. There's only so many people and so much work to do: the author of that RFC has also been working really hard on incremental recompilation, for example, which a lot of people have been waiting for.

To re-phrase someone from the Reddit, you can't win: if we don't add new features but fix bugs, people claim that you ignore feature work, but if you add tons of new features, people wonder why you're bothering to add new features when there's lots of bugs open. It's tough.

Re: Why I’m dropping Rust

#150

Post by steveklabnik »

eriknstr wrote: post #121
steveklabnik wrote: post #24

Earlier quoted context omitted.

There are already some CS courses in Rust, Penn is running another one this upcoming semester. (It's not a basic course, but you absolutely could.)

CIS 198 or something else? https://cis198-2016f.github.io/ I am currently "attending" the above mentioned course by following along online. I am enjoying it very much so far. There have been three assignments so far, the first of which was to get rust installed and such. I think it would take most of the HN crowd less than a week to catch up with the course so that they can follow it for the remainder of the semester…

That's the one!
Post reply on HN