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

100 days with Rust: a series of brick walls

brandur.org

Post reply on HN
Print view View original

131–140 of 323 posts

Re: 100 days with Rust: a series of brick walls

#131

Post by pcwalton »

alexeiz wrote: post #121
tkzzbneig wrote: post #73

Earlier quoted context omitted.

It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vector. You may very well get the program to compile, but then run into odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). So any overridden methods which expect extra data in a subclass will not behave a…

> It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vector. Baloney. In C++ vector or vector accomplish this task without any problems whatsoever.

And you can do the same in Rust with Box. What Rust doesn't have is the object slicing gotcha, which is probably a language design mistake in C++.

Re: 100 days with Rust: a series of brick walls

#132

Post by pcwalton »

skohan wrote: post #72
SCdF wrote: post #38

I am currently learning Rust and I feel this intensely[1]. I really want to like Rust, but I feel like the way they cope with no GC (lifetimes, borrowing) fights me at every turn, and really simple situations in other languages[2] become these intensely painful situations. Every time you think you've worked out how to fix a problem you find while you've fixed that one you've actually created 2 more. Want to have a da…

Two things jump out at me: 1. Automatic reference counting is a really good alternative to GC. It takes a little bit more book-keeping, but the performance characteristics are predictable since allocations/frees are handled along the way. Many GC implementations require execution to be halted while the reference graph is traced, which makes it a non-starter for applications trying to deliver predictable real-time per…

Automatic reference counting is just a slow form of GC.

Re: 100 days with Rust: a series of brick walls

#133

Post by irascible »

geezerjay wrote: post #125
seawlf wrote: post #10

As someone who has been programming in Rust for nearly a year, even for commercial purposes, this article is baffling to me. I've found the compiler messages to be succinct and helpful. The package system is wonderful. It's dead easy to get something off the ground quickly. All it took was learning how and when to borrow.

> As someone who has been programming in Rust for nearly a year, even for commercial purposes, this article is baffling to me. The author introduces himself as having a Python background, and as someone who experienced some challenges wrapping his mind around SQL. I wouldn't expect anything different.

Hopefully people don't cognitively shame you when you start experiencing mental decline due to your age.

Re: 100 days with Rust: a series of brick walls

#134

Post by tdbgamer »

zyxzevn wrote: post #75

The problem with Rust is that it is very hard to program interconnected graphs. Basic Rust does not allow cyclic references, which means that almost every graph needs to use special tricks to make it work. These tricks are variants of reference counting. A trick that was copied directly from C++. It feels like having to build a car with only a screwdriver and hammer. Each section of your graph needs to be managed sep…

To be clear, cyclic references are just as much an issue in GCed languages. In Python I had to use weakref lib to ensure cyclically referenced objects are still GCed. Rust is the same in that aspect, you use the Rc builtin type and create a weakref for one of them.

Re: 100 days with Rust: a series of brick walls

#135

Post by tdbgamer »

weberc2 wrote: post #54

I've been dabbling in Rust on and off since 2014, and this has always been my feeling. I thought my background in C++ would make things reasonably easy, and while I have little fondness for C++, it's still easier to get things done than with Rust, which is not at all what I expected given my 4 years with the language. There's a lot to like about Rust, but it falls far short of the "easy-as-Go" promises made by many o…

My impression is that people use Rust for correctness, security, and speed over ease of use. Although I do think once you get over the initial learning curve (which is admittedly large) it mostly makes sense.

Re: 100 days with Rust: a series of brick walls

#136

Post by reaperducer »

gnode wrote: post #47
majewsky wrote: post #39

Earlier quoted context omitted.

I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example: error[E0271]: type mismatch resolving ` + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result >, futures::MapErr , [closure@src/server/mod.rs:74:18: 74:74]>>, std::…

The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.

If we'd all start programming in stable, mature languages instead of letting peer pressure goad us into using betaware and worse, work would be a lot simpler.

It would also encourage organizations large and small to start releasing complete, polished products instead of the "move fast and break things" crap that has infected the industry.

Imagine if car makers worked the same way.

Re: 100 days with Rust: a series of brick walls

#137

Post by geezerjay »

pcwalton wrote: post #130
geezerjay wrote: post #127

Earlier quoted context omitted.

> It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vector. This is simply wrong. > You may very well get the program to compile, but then run into odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). That has nothing to do with object sizes. You're descri…

> The cause of this problem is ignorance and incompetence regarding fundamental aspects of the language. No! You can rationalize any language problem away with this argument. That's why it's a fallacy with a name: "no true Scotsman" (as in: "no true C++ programmer would let object slicing introduce a bug"). Object slicing is a problem with C++, period.

> No! You can rationalize any language problem away with this argument.

Sorry, the sole problem is incompetence. Coupling incompetencr with the inability to learn is a problem that no programming language solves. If you insist in shooting yourself in the foot, it makes absolutely no sense to complain that the gun is broken because it doesn't guide bullets away from your foot when you intentionally aim at it.

The object slicing problem is C++ 101. It isn't the language's fault that people who don't know the very basics end up doing mistakes.

Re: 100 days with Rust: a series of brick walls

#138

Post by pcwalton »

dman wrote: post #120

Disclaimer: Am a C++ programmer Watching from a distance I have to concede that from a safety, dynamism of the community and package management using cargo Rust has improved upon C++ in meaningful and measurable way. However on the complexity of the language front, I wonder if Rust will also join C++ in the realms of "too complex" 10 years from now. Would love to get some Rust experts to weigh in here on their though…

It's a goal of Rust to be simple--one look at the RFC repo is enough to see how important that is in the language design--but there are other goals too. In particular, nobody has successfully proposed any alternative to memory safety without GC that doesn't involve lifetimes and borrowing (and reference counting is just a form of GC).

Re: 100 days with Rust: a series of brick walls

#139

Post by widdershins »

pcwalton wrote: post #132
skohan wrote: post #72

Earlier quoted context omitted.

Two things jump out at me: 1. Automatic reference counting is a really good alternative to GC. It takes a little bit more book-keeping, but the performance characteristics are predictable since allocations/frees are handled along the way. Many GC implementations require execution to be halted while the reference graph is traced, which makes it a non-starter for applications trying to deliver predictable real-time per…

Automatic reference counting is just a slow form of GC.

Yes, slower than modern GC, but predictable and deterministic. Note that the parent comment never claimed it was faster, just that it avoids 'stop the world' which can be a problem in realtime contexts (e.g. games, audio).

Re: 100 days with Rust: a series of brick walls

#140

Post by pcwalton »

geezerjay wrote: post #137
pcwalton wrote: post #130

Earlier quoted context omitted.

> The cause of this problem is ignorance and incompetence regarding fundamental aspects of the language. No! You can rationalize any language problem away with this argument. That's why it's a fallacy with a name: "no true Scotsman" (as in: "no true C++ programmer would let object slicing introduce a bug"). Object slicing is a problem with C++, period.

> No! You can rationalize any language problem away with this argument. Sorry, the sole problem is incompetence. Coupling incompetencr with the inability to learn is a problem that no programming language solves. If you insist in shooting yourself in the foot, it makes absolutely no sense to complain that the gun is broken because it doesn't guide bullets away from your foot when you intentionally aim at it. The obje…

"Don't use heap memory after it's been freed" is C++ (and C) 101 as well. Yet if the bar for C++ competence is "never wrote a use-after-free", then your bar for "competence" excludes essentially everyone in the industry.

Whether a theoretically "competent" C++ developer makes mistakes related to object slicing is a completely uninteresting debate. Whether experienced C++ programmers make that mistake in practice is the interesting question. And they do.

Post reply on HN