100 days with Rust: a series of brick walls • Hacker News Board

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

#311

Post by kenhwang » Sat, Mar 24, 2018, 5:52 PM UTC

edflsafoiewq wrote: post #310

kenhwang wrote: post #261

Earlier quoted context omitted.

I love Rust when it's refactoring time, the compiler essentially spits out a checklist that you just need to work through. And once it's done complaining it feels pretty confidence inspiring. But I'll agree that Rust is unpleasant for prototyping. What I find myself doing a lot when starting out a project is just figuring out if some snippet of code will work. There's no REPL to just run it in. Then I have to either…

Do you know about unimplemented!()? I use #[test] functions for what I'd throw into a REPL and if it's not horrible you can keep them as actual tests later.

That's really nifty! Not quite was I was thinking of though, but it gave me a starting point for some research before I came across https://github.com/rust-lang/rfcs/issues/1911 which describes why unimplemented!() doesn't quite work and what I'd like instead.

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

#312

Post by jokoon » Sat, Mar 24, 2018, 7:30 PM UTC

pjmlp wrote: post #307

jokoon wrote: post #295

Earlier quoted context omitted.

Sure, but that's a different debate. If that would be the case, you would have much less competent programmers who would be able to do their job properly. I believe the software industry is still too young and immature.

On the contrary, only those able to meet the bar would be on the field, and we wouldn't have self taughs calling themselves engineers.

There is a big demand for programmers, so raising the bar doesn't make sense.

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

#313

Post by coldtea » Sat, Mar 24, 2018, 8:25 PM UTC

vardump wrote: post #150

pimeys wrote: post #100

Earlier quoted context omitted.

That's nothing! | 212 | / fn call(&self, payload: Self::Request) -> Self::Future { 213 | | let request = self.create_request(payload); 214 | | 215 | | let work = async_block! { ... | 254 | | FutureResponse(Box::new(work)) 255 | | } | |_____^ note: ...so that the type `impl futures::__rt::MyFuture request:hyper::Request for {futures::Async , (), fn(std::result::Result ) -> std::result::Result as std::ops::Try>::Ok, as…

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 see. Rust is aiming to be closer and closer to C++ every day!

Or you know, it's aiming nothing of the short, and this is early, still unsorted, behavior, while the language has been simplifying things (e.g. the early sigils and lots of other stuff), and plans even more simplification and friendliness.

https://jvns.ca/blog/2018/01/13/rust-in-2018--way-easier-to-...

https://blog.rust-lang.org/2018/03/12/roadmap.html

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

#314

Post by TheCoelacanth » Sat, Mar 24, 2018, 10:53 PM UTC

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…

> What I really meant was that you can't have Vec where T is a trait without also wrapping that in a box

In what language can you do something like that? In C++, it would compile but anything that you put in the vector would get sliced down to the base type. In Java, everything you put in would get boxed.

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

#315

Post by GolDDranks » Sun, Mar 25, 2018, 6:37 AM UTC

Yoric wrote: post #71

arghwhat wrote: post #66

Earlier quoted context omitted.

I recently wrote a few projects in Rust (C/C++/Go/JavaScript/Java/Python as background), and very much like the language. My 2 cents from my endeavors with Rust I felt like all type errors are backwards. That is, "got" was the target you are giving your type to, not the type that you are passing. This may only happen in some cases, but I just started tuning the content of those errors out and instead adjusted randoml…

> Enums are super nice, but it's very annoying that you cannot just use the value as a type. My project had a lot of enums (user-provided query trees), and it was causing a lot of friction. Note that OCaml has this feature of using-a-enum-value-as-a-type (or using a subset of enum values as a type, etc.). It works very well, but it quickly produces impossibly complicated error messages. I'd like Rust to have this fea…

I’m interested in this feature because of the ”incremental” static case analysis it enables. What’s the problem with the error messages?

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

#316

Post by paulddraper » Sun, Mar 25, 2018, 2:46 PM UTC

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.

> less to do with Rust itself, and more to do with this seemingly horrible futures library

Doesn't almost every major programming language have Futures though? (C++, Java, Python, Ruby, JavaScript, Go).

It seems a fair criticism for so common a building block.

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

#317

Post by pjmlp » Sun, Mar 25, 2018, 2:51 PM UTC

jokoon wrote: post #312

pjmlp wrote: post #307

Earlier quoted context omitted.

On the contrary, only those able to meet the bar would be on the field, and we wouldn't have self taughs calling themselves engineers.

There is a big demand for programmers, so raising the bar doesn't make sense.

If companies payed programmers properly, gave training and benefits, there wouldn't be lack of programmers.

Raising the bar makes sense in any engineering.

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

#318

Post by steveklabnik » Sun, Mar 25, 2018, 4:53 PM UTC

paulddraper wrote: post #316

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.

> less to do with Rust itself, and more to do with this seemingly horrible futures library Doesn't almost every major programming language have Futures though? (C++, Java, Python, Ruby, JavaScript, Go). It seems a fair criticism for so common a building block.

Rust's futures leverage the type system to have extremely minimal overhead; many of those languages don't try to do that. That's where the difficulty comes in.

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

#319

Post by vlovich123 » Sun, Mar 25, 2018, 6:37 PM UTC

Koshkin wrote: post #122

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 a really good alternative to GC 1) GC is lazy, whereas RC is eager; 2) the use of "pure" RC may lead to memory leaks.

Memory leaks occur in GC too.

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

#320

Post by gnode » Mon, Mar 26, 2018, 12:00 PM UTC

paulddraper wrote: post #316

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.

> less to do with Rust itself, and more to do with this seemingly horrible futures library Doesn't almost every major programming language have Futures though? (C++, Java, Python, Ruby, JavaScript, Go). It seems a fair criticism for so common a building block.

For a long time C++ and Javascript did not have futures. Rust is relatively new, and futures aren't part of the language proper yet. The problem is that the author's criticism of Rust seems to all hinge around a bleeding edge feature.

I would agree with the author's criticism if it was "futures are in the lang nursery and still not ready to use," rather than: Rust is bad, because I got nasty errors when using this work-in-progress library.