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

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

291–300 of 301 posts

Re: The struggle with Rust

#291

Post by mmstick »

spullara wrote: post #155
bluejekyll wrote: post #128

Earlier quoted context omitted.

> It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. This arguing with the compiler is really only while you are learning Rust and it's nuances. For me the first two weeks were this way, then I started thinking more in Rust terms. Now I rarely deal with the borrow checker at all, but I do end up in some complex type situations. You're spot on…

I think the difference is that while you are coding Python in a C style the code is working. The front loaded nature of Rust means that you are in a constant fight to get something to run.

I've been writing Rust solutions for two years now, and I do not feel like I am in a 'constant fight' to get something to run. That only happened for the first two or so weeks as I was learning Rust.

Re: The struggle with Rust

#292

Post by eternalban »

gcp wrote: post #275
eternalban wrote: post #152

Earlier quoted context omitted.

I guess I should have added that I last touched C++ in '96 and never (ever) have had an urge to look back. :)

I've you've never seen template programming, but just C with classes, then yes, I can see how you arrive at this conclusion. C++ in 2017 is very different from what it was in 1996.

I was using STL and RTTI. I know the language has substantially improved. These days I've actually rediscovered the joy of plain C.

Re: The struggle with Rust

#293

Post by galangalalgol »

rbehrends wrote: post #186
bluejekyll wrote: post #162

Earlier quoted context omitted.

I think you're implication here is that other languages do handle multiple ownership well. What I think you find in Rust, is that the guarantees you need to make when using unsafe in these limited situations, are the exact same guarantees you need to make in a language like C or C++. Destroying a circular list takes some thought to make sure you don't double free, same as Rust. Rust just makes those sections of code…

Your assumption seems to be that I'm talking about languages with manual memory management. I'm not; I'm talking about garbage-collected languages, where you get memory safety automatically, regardless of ownership rules. In fact, C++ has some of the same problems that Rust has when it comes to multiple ownership.

Does GC imply memory safety? Use after free and dangling references probably can't happen, but I have never heard of a GC supplying cross thread memory safety. The borrow checker does.

Re: The struggle with Rust

#294

Post by the_duke »

rev_null wrote: post #86
the_duke wrote: post #45

Earlier quoted context omitted.

I think the problems with Haskell are quite different than the ones with Rust. Haskell suffers more from being a research playground, bad documentation for both the language and it's libraries, confronting you with many unusual concepts (type theory, monads, laziness,...) and, as a pretty old language, a lot of legacy cruft that makes a lot of things awkward (string handling is the prime example). Rust wants to be a…

When the blub programmers look up the ladder, they see a bunch of type theory, monads, and laziness. They don't see the use for these features as they think in blub.

The type system in Haskell and other ML family languages is incredibly powerful, but it takes a long time for most to intuitively grasp functors, monads, monad transformers,...

It's a huge entry barrier.

Re: The struggle with Rust

#295

Post by readittwice »

mtanski wrote: post #160
readittwice wrote: post #145

Earlier quoted context omitted.

You could use id/vec indices, instead of directly pointing to your e.g. sucessors: "struct Node { successors: Vec }". This has the obvious disadvantage that deleting nodes is quite hard though.

> This has the obvious disadvantage that deleting nodes is quite hard though It's hard because now you're in charge of building a malloc(3) implementation. Depending how important this data structure is you might need to worry about 1. about fragmentation 2. free space managment 3. adjacency and cache effects So you've traded on hard problem for another hard problem. Not something I'd call a win.

Sure, I wouldn't recommend that solution if you have to delete single nodes a lot. But it is quite convenient if you don't need to do that.

Re: The struggle with Rust

#297

Post by JepZ »

valarauca1 wrote: post #82
JepZ wrote: post #62

Earlier quoted context omitted.

I never wrote a single line of rust, but when a language is hard to learn, the compiler error messages are probably just bad in terms of comprehensibility and offer the user no direct solution.

when a language is hard to learn, the compiler error messages are probably just bad in terms of comprehensibility and offer the user no direct solution. I don't want to sound snarky but Rust really does have amazing error messages, and they literally do offer direct solutions/suggestions using literal examples and raw samples of your source code. It even offers the `rustc --explain EXXXX` (where XXXX is an error code…

So what do you think, why is it so hard to learn rust, if it is not about the compiler messages?

Re: The struggle with Rust

#298

Post by rbehrends »

galangalalgol wrote: post #293
rbehrends wrote: post #186

Earlier quoted context omitted.

Your assumption seems to be that I'm talking about languages with manual memory management. I'm not; I'm talking about garbage-collected languages, where you get memory safety automatically, regardless of ownership rules. In fact, C++ has some of the same problems that Rust has when it comes to multiple ownership.

Does GC imply memory safety? Use after free and dangling references probably can't happen, but I have never heard of a GC supplying cross thread memory safety. The borrow checker does.

Memory safety in multi-threaded programs is not a hard problem once you have GC. Eiffel solved it decades ago. The JVM also has a weak form of memory safety; it does not preclude data races, but the VM cannot crash as the result of a data race.

Re: The struggle with Rust

#299

Post by petersp »

nebopolis wrote: post #133
ajmurmann wrote: post #108

Earlier quoted context omitted.

The issues and solutions you list sound super valuable. Do you know if there is a write up about those issues somewhere or did you just learn through blood and sweat?

Learning Rust With Entirely Too Many Linked Lists ( http://cglab.ca/~abeinges/blah/too-many-lists/book/ ) is the best resource I've found for learning how to create data structures in Rust. It goes over a lot of the pain points of interacting with cyclic data structures.

Thank you for this pointer!

Re: The struggle with Rust

#300

Post by webmaven »

noxToken wrote: post #51
wiremine wrote: post #39

Earlier quoted context omitted.

> It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. In my experience, most developers can't or won't put in this sort of investment. Which leads me to wonder what fields/niches will Rust land in? This might change if, as other commenters have stated, it is taught as a first or second language, but that doesn't seem likely anytime soon...

> it is taught as a first or second language This is interesting. Many universities teach Java, C, C++ or Python as a first language. The headache that many first year students suffer from these basic (relatively speaking) languages is readily apparent. Rust is very strict, and it requires an entirely different mindset to use. I wonder how this would fare with students who have a clean slate.

> I wonder how this would fare with students who have a clean slate.

I suspect that the % of students who have difficulties won't be much different, overall. There may be a different distribution of when they run into trouble.

The interesting question is whether the group of students who have problems with other first programming languages is different from the group that have problems with Rust-as-a-first-language...

Post reply on HN