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

81–90 of 164 posts

Re: Why I’m dropping Rust

#81

Post by joeldg »

Ahh this is the time honored tradition of 'new language grumping'.. It goes something like this.

1) Pick a hot new language that is just in version 1

2) Attempt to shoehorn your shitty existing project into hot new language trying to use old paradigms and bad design.

3) Complain that new language does not have all the 'features' of the old language you have been using and be super vague about how you 'really' tried to get the 'community' to help you.

4) Strawman up a "solution" that some random gave you on IRC or a forum.

5) Write post to complain about new language in order to get lots of new visitors because you know all the fan boys are using hot new language..

6) Congratulate yourself on successful troll.

Saw a bunch of these with python, perl, php, c# and node. Now they are coming out for go and rust right on schedule.

Re: Why I’m dropping Rust

#82

Post by roblabla »

Animats wrote: post #57
stouset wrote: post #50

Earlier quoted context omitted.

In what conceivable way? Safe Rust allows one to do an incredible amount of things whole providing strong guarantees against the sorts of problems that plague lower level languages. Since this isn't suitable for absolutely everything, we have unsafe Rust to fill in the gaps in the small areas it's needed. Unsafe Rust isn't "bad", it just doesn't provide the same guarantees as safe Rust. And if something goes wrong, y…

And if something goes wrong, you can at least narrow down your search to unsafe areas of the code. No. That's only true if the unsafe code presents a completely safe interface to its callers. If the safe code opens a hole in Rust's protection system, which is very easy to do, you can now have C-type no-idea-where-it-is bugs.

But the origin of the bug is still certainly in the unsafe areas.

Re: Why I’m dropping Rust

#84

Post by loup-vaillant »

jerf wrote: post #78
loup-vaillant wrote: post #38

Earlier quoted context omitted.

> GUI libraries are an interesting special case: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership. I doubt they have to be. There are other ways to do GUI, see for instance how Light Table uses a database-like Entity Component System. https://www.youtube.com/watch?v=V1Eu9vZaDYw

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 and heaps of code, but I'm sure it doesn't have to affect the core.)

It's only an intuition at this point (I have yet to implement my own GUI toolkit). But I have reasons to believe this intuition is right: http://www.vpri.org/pdf/tr2012001_steps.pdf

Re: Why I’m dropping Rust

#85

Post by loup-vaillant »

mookid11 wrote: post #64
loup-vaillant wrote: post #62

Earlier quoted context omitted.

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

> Yes, but hardly anybody uses that part of the language. We tend to stick with modules and variations over them. You can have inheritance via polymorphic variants: see Garrigue's `Code reuse through polymorphic variants`.

I have never used polymorphic variants… Too lazy to learn.

Re: Why I’m dropping Rust

#86

Post by trimbo »

steveklabnik wrote: post #63
arbre wrote: post #60

I have been feeling that way ever since two years ago when I first looked at the language. I still don't understand why this language has such popularity. It's really bad for the reasons mentioned. C++ is a solid language where you can do everything you want and also write memory safe code in a clean way with unique_ptr. C++ is not perfect but to me no alternative come close yet, rust and go comprised.

C++ is not memory safe, and neither is uniq_ptr. Use after move on one causes a segfault. (Actually IIRC it's UB, but it usually manifests as a segfault)

It looks like clang-tidy just committed a check for this case: https://reviews.llvm.org/D23353

Re: Why I’m dropping Rust

#87

Post by whyever »

steveklabnik wrote: post #27
whyever wrote: post #6

I don't understand why the author wants to access fields from a trait. They can be accessed by the trait implementations, which makes sense, because the fields depend on the type.

You should check out the RFC they linked; there are good reasons to enable this.

Thanks! Here are the reason why trait fields are preferable over accessors in case anyone else is wondering:

1. The borrow checker assumes accessors can do anything, freezing all other fields. This does not happen with trait fields. 2. Accessors have to use dynamic dispatch in case of trait objects, resulting in worse performance.

Re: Why I’m dropping Rust

#88

Post by steveklabnik »

trimbo wrote: post #86
steveklabnik wrote: post #63

Earlier quoted context omitted.

C++ is not memory safe, and neither is uniq_ptr. Use after move on one causes a segfault. (Actually IIRC it's UB, but it usually manifests as a segfault)

It looks like clang-tidy just committed a check for this case: https://reviews.llvm.org/D23353

Not exactly this case. From the link:

  > No warnings are emitted for objects of type ``std::unique_ptr`` and
  > ``std::shared_ptr``, as they have defined move behavior.
Regardless, I am happy to see more static checking for C++, and am following the GSL/Core Guidelines closely. It's important work.

Re: Why I’m dropping Rust

#89

Post by jblow »

ekidd wrote: post #31
TillE wrote: post #15

Earlier quoted context omitted.

A lot of problems in Rust seem to involve replacing (smart) pointers with handles. Sometimes you really do want to do that, but it's bad if it's a necessary kludge. Like someone else said recently, it's a problem if you can't reasonably teach a basic computer science course in Rust.

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

Re: Why I’m dropping Rust

#90

Post by lmm »

TillE wrote: post #15
pcwalton wrote: post #7

Earlier quoted context omitted.

> The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code. It's not much different from the C++ solution. Well, petgraph uses vectors and indices to avoid unsafe code, and it's the most popular graph library on crates.io. Really, the answer here is "use a graph crate on crates.io". If you don't know which one to use, the best answer is probably petgraph…

A lot of problems in Rust seem to involve replacing (smart) pointers with handles. Sometimes you really do want to do that, but it's bad if it's a necessary kludge. Like someone else said recently, it's a problem if you can't reasonably teach a basic computer science course in Rust.

My basic CS course was taught in Standard ML. Pointers are an implementation detail for the vast majority of CS.
Post reply on HN