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

251–260 of 323 posts

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

#251

Post by catnaroek »

perlgeek wrote: post #164
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…

My hope is that, over time, we figure out simpler ways to achieve the safety goals that Rust is pioneering right now, and so there will be simpler/easier alternatives that do the same. If in ten or twenty years we can't do better than now, we've failed to make progress. So yes, in the future we will hopefully consider Rust "too complex". (Disclaimer: I don't have much experience with Rust, speaking as an outside obse…

Safety can be established in three ways:

(0) Automatically and statically, in which case there is an unavoidable tradeoff between the simplicity and the power of the static analyses. Example: non-lexical lifetimes.

(1) Automatically and dynamically, in which case you need performance-draining checks. Example: slice indexing.

(2) Manually, i.e., leave it as an exercise for the programmer, in which case you need a language with a formal semantics, because how else are you supposed to prove anything? Example: none that I know of in Rust or any other similar language.

There are no other options, although you can take a pick and choose approach for different use cases. IMO (2) has not been given the attention it deserves.

---

So, do you have any concrete idea regarding what could be made simpler?

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

#253

Post by vlovich123 »

nabla9 wrote: post #162
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…

Reference counting is a form of GC. The problem with reference counting is that it don't work with recursive structures and counters may overflow. Overflow or reaching some max value and returning runtime error are both problems.

On 64-bit platforms you're not going to overflow the counter. 32-bit platforms these days are embedded & they too are highly unlikely to overflow the counter.

Recursive structures are a problem although in my experience you can usually just alter the ownership rules a bit instead.

FWIW there's a Rust GC library that provides opt-in GC for when you need it. https://github.com/Manishearth/rust-gc

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

#254

Post by dom96 »

Dowwie wrote: post #87

I have been working with Rust, full time, for a little less than 100 days. Like the author, I also came from Python (I authored Yosai). Unlike the author, I haven't been hitting brick walls. I also have observed all of the warning signs that the futures bridge on the tokio highway is unfinished so I didn't cross the barrier and still try to use it anyway. Instead, I have been working on myriad other synchronous parts…

I'm interested to know what attracts Python programmers to Rust. It's a very different language so I'm surprised to see so many python programmers take it up. What are your reasons for working with it?

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

#255

Post by theseoafs »

tdbgamer wrote: post #134
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.

You were being overpessimistic: Python's GC handles cyclic references perfectly well.

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

#256

Post by geofft »

tveita wrote: post #238
gnode wrote: post #47

Earlier quoted context omitted.

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.

I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.

If you're a library, creating threads causes side effects for the host program, and doing async when called doesn't. For instance, in a single-threaded program, it's always safe to call malloc() after fork(). In a multi-threaded program, another thread might have called malloc() and picked up a global lock; since only the thread that called fork gets copied (since you don't want to do the other threads' work twice!), there's now a copy of that global lock being held by a thread that doesn't exist, so calling malloc() will deadlock.

My personal interest in Rust is as a C replacement, including as a replacement for existing libraries that are written in C. While I agree threads can be very efficient (after all, the kernel implements threading by being async itself, more or less), they're annoying for this use case.

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

#257

Post by saghm »

xfer wrote: post #169
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::…

Yeah, i have recently finished a tokio based server. Working with future combinators is very frustrating. I accidentally captured a variable in a closure(should be cloned and moved), and it didn't tell me where it happened, just an error saying requires 'static lifetime for the variable.

I know this won't help you, but there is an issue tracking this: https://github.com/rust-lang/rust/issues/43353

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

#258

Post by zokier »

steveklabnik wrote: post #207
roadbeats wrote: post #115

PG had this comment about programming languages: The correct solution of a problem is the most simple solution. Just like in math, you can solve one problem in multiple ways, but the correct one is the shortest, beautiful looking one. When I look at Rust, it gives the feeling "could be simplified". Obviously it's a new language and it comes with lots of cool stuff, but it looks ugly, doesn't excite those who seek sim…

There are some ways in which Rust can be simpler; see my above comments about learn ability. But a lot of the complexity is inherent in the choices we've made for the constraints of the language. For example, including a GC would make things much simpler in some ways! But it would also make it not appropriate for many of the use cases that are crucial to Rust's existence.

The way I see it, Rust exposes more of the underlying complexity of things which makes Rust itself appear more complex than its peers.

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

#259

Post by thowawayburnout »

pimeys wrote: post #161
vardump wrote: post #150

Earlier quoted context omitted.

I see. Rust is aiming to be closer and closer to C++ every day! Anyways, I think it has still long way to go to match the length of even common C++ template related error messages...

I've definitely seen much worse with C++. These kind of errors you get though when you use Tokio and combine many different futures together, the future wanting to have static lifetimes and me using a reference to self inside an async block, hopefully solved this year.

I have found while the C++ error messes can be very long, its surprisingly often in the first line of the error message that you see the problem.

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

#260

Post by dman »

steveklabnik wrote: post #204
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…

Rust is certainly not the "end of history" for programming languages. But, taking on that task is for future generations of language devs; it's an open research question today. I can only hope so! I wrote some thoughts about "complexity" and language design here: http://words.steveklabnik.com/the-language-strangeness-budge... I also think the difference between incidental and inherent complexity is important...

One question I had after reading your post is - We currently build languages with purely additive models, ie features can be added to a language over time. Overtime the interaction between features creates "incidental complexity". Was wondering if you know of any languages that have been able to drop old features / ideas in a controlled manner.
Post reply on HN