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

261–270 of 301 posts

Re: The struggle with Rust

#261

Post by pjmlp »

AstralStorm wrote: post #233
humanrebar wrote: post #225

Earlier quoted context omitted.

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".

Kind of, you cannot enforce your team mates, consultants and third party libraries that are part of the whole product to use them.

Static analysers and code reviews are not always possible, depending on the target OS and compiler being used, or how the whole project across teams is organized.

Re: The struggle with Rust

#262

Post by kibwen »

braveo wrote: post #224
kibwen wrote: post #191

Earlier quoted context omitted.

If you just want to write code that runs but that will suddenly break without warning an unknowable time into the future, then C++ has a lower learning curve. If you want to code defensively and write software that isn't going to eat your laundry, then the learning curve for C++ surpasses Rust in steepness, because of the sheer number of things you have to learn not to do.

No student in any language learns by writing production ready code. Anyone who thinks this is what it means to learn a language is attacking a strawman.

No strawman here. It's incorrect to believe that the process of learning a language has necessarily ended by the time that someone has begun putting code into production.

Re: The struggle with Rust

#263

Post by flukus »

wyldfire wrote: post #130
trishume wrote: post #18

Earlier quoted context omitted.

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve. The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like th…

> Agreed. Rust is different from other languages in that it is HARD to learn. Don't you think C/C++ are hard to learn too? C++ has a vast surface area and I think it's unlikely that most people who use it understand much of it. When I code in C, I feel like I have to be paranoid because it's so easy to forget a path that doesn't recover allocated resources. But if I'm not paranoid, I just leak the resources and don't…

C++ is hard, but C is about the simplest language in modern use.

Re: The struggle with Rust

#264

Post by flukus »

leshow wrote: post #69

The first few of these types of posts were OK. But now it's a bit ridiculous. You spent 2 days trying a new language and you didn't like it, your opinion means nothing.

This is particularly bad considering who it's from, his claims to fame include nHibernate and ravenDB, both of which take much longer than a few evenings to learn, with more questionable value as well.

Re: The struggle with Rust

#265

Post by dllthomas »

rntz wrote: post #244
rbehrends wrote: post #212

Earlier quoted context omitted.

> Great! I believe, by that definition, your assertion that "good" typesystems don't reduce expressiveness is false, at least for common type systems such as Haskell's, Java's, ML's, etc. Haskell is not very good at extensible runtime polymorphism (one of its weaknesses). Try OCaml's polymorphic variants.

Okay, then I can pick another example: A dictionary where the type of the values depends on the key they're inserted under. (For example, a representation of the closure of a function in a typed language.) Of course, then I can go to a dependently typed language, but are you really going to tell me that only dependently typed languages count as "good" static type systems?

You can do this in GHC Haskell with existential quantification, or trade static checks for runtime with Data.Dynamic.

(Again, not arguing against your thesis here.)

Re: The struggle with Rust

#266

Post by bluejekyll »

spullara wrote: post #257
bluejekyll wrote: post #218

Earlier quoted context omitted.

I'm hoping that things like the Rust Language Server and it's integration into some of the IDE's out there will help with the initial learning curve; already the rustc error output is a million times better than when I started with it. I definitely share your concern; for me, Rust was like putting on a glove perfectly shaped for my hand. It works and prevents every basic pattern that it took 10 years to learn and sta…

Have they thought about allowing code to work by warning and elevating the scope so you can quickly get the procedural work done and then attack the memory usage?

I've been thinking about a good answer to this, but I don't know what it would look like. Code looks so different when you need to be concerned about mutable vs. immutable borrows. For example you might want to iterate over a list perform an action and then delete items after doing work. This needs to be broken into two blocks, one that does the iteration and then a second block to remove any elements that no longer belong.

That's an example of just two blocks, but if it's deeper structures then ignoring this until the end could cause you to go back and restructure significant sections of code to make it abide by the mutability rules.

The process I use to stay productive, is to write small blocks of code, write a unit test for it, compile, and then move on. That way I don't build up a ton of compiler debt...

Re: The struggle with Rust

#267

Post by mixedCase »

braveo wrote: post #251
mixedCase wrote: post #246

Earlier quoted context omitted.

Worked for me when learning Go.

I think that says more about your idea of production ready code than it does the issue under discussion.

I didn't know a many useful "Goisms" at the time, but it was certainly code that didn't need drastic refactoring. I just picked up the language basics in a day, and 3 days later I was effectively writing code that I might certainly write better today, but it was functional, extensible and fault-tolerant.

Re: The struggle with Rust

#268

Post by sambe »

jandrese wrote: post #209
sambe wrote: post #16

Earlier quoted context omitted.

Not sure if your comment was intended dismissively/jokingly, but I think also somewhat insightful. I find myself much less often really thinking about how to do something these days; if it seems remotely standard or potentially troublesome I google it. As a result, I spend less time thinking "algorithmically" about low-level stuff and probably lose something. But I also spend more time thinking (perhaps algorithmical…

Googling for Rust solutions is dangerous since frequently the advice you find only applied to some old beta version and no longer works. Then you find a second answer but it only applies to an even older beta version. None of the examples anywhere work of course. This is my biggest frustration with the language: the manual is good for what it is, but it only covers the basics. You can see this in the article, where t…

And your comment sounds exactly like the author to me: "I can't move transparently from languages I know well to ones I don't". Would you be able to whip up same in Haskell or Erlang? How many people claiming this would include a few bugs that Rust prevents?

Learning curve is a feature for sure, and the Rust community seems to be aware of this. But expectations of minimal effort are odd.

Re: The struggle with Rust

#269

Post by AstralStorm »

dbaupp wrote: post #236
AstralStorm wrote: post #233

Earlier quoted context omitted.

You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".

Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.

1) If you cannot get a plain reference you cannot get dangling references. 2) Use data structures that keep iterators valid and modern reference counted internals. (so that when you have an iterator, you have the object) Alternatively copy on write semantics. 3) Use after move is relatively tricky if you want more. However, your allocator or data structure can catch it with specific implementation of move operators. Use after free can be reduced to use after move or caught with right delete/new operators. 4) Instead, you may have an API where you have your own high level reference-like type. There is a cost to it, same as in Rust. 5) What you cannot do is enforce people to use it always.

Re: The struggle with Rust

#270

Post by AstralStorm »

steveklabnik wrote: post #238
AstralStorm wrote: post #234

Earlier quoted context omitted.

First, Rust does not prevent data races, just makes them pain to write. Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds) This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.

Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug. You can write arenas in Rust.

You can, but it is an extreme pain to do it, especially for any nontrivial data structure. That is because even if the arena is safe enough, say with copy on write semantics, you cannot specify that for the borrow checker easily (or at all)

You cannot implement many data structures in a decent performance way without unsafe, so Rust guarantee is weak.

Post reply on HN