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

181–190 of 323 posts

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

#181

Post by katastic »

arghwhat wrote: post #66
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.

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…

>There are also many trivial tasks where you think "Of course there is an established ecosystem of libraries and frameworks for this", and end up proven wrong. I mostly did find one library for the thing I needed, but often immature. The HTTP server + DB game seems especially poor.

That's my situation with D. It's a beautiful language but you have to rely on bindings for everything, and many times, people start a project... and never maintain it. So you'll find a great lib... and then realize it hasn't been updated since 2012 and wonder whether you should risk adding a possibly bug-ridden (and unsupported) project to your project.

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

#182

Post by dmitrygr »

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…

   if something is hard to do in Rust it's
   probably an anti-pattern with respect
   to memory performance or safety.
Oh? Tell me, how many lines of Rust does this take you?

    struct Task {
      struct Task *next;
      struct Task *prev;
      struct TaskRegs regs;
      //other shit here
    }
Or are doubly-linked lists antipatterns now?

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

#183

Post by katastic »

tkzzbneig wrote: post #73
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…

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…

This is absolutely, 100%, certifiably wrong.

> odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class).

This only EVER happens if you do something you're never supposed to do. If you have a base pointer, it only knows about... base pointer fields!

>So what you usually do here is have a pointer and a VTable and all that jazz.

"Making a VTable" in C++ sounds like you have zero understanding of the language.

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

#184

Post by actuallyalys »

rayascott wrote: post #175
actuallyalys wrote: post #171

Earlier quoted context omitted.

Your comment stated that going from Python to Rust while struggling with SQL is something "you just should not do". That implies that the struggles they describe are the result of trying to learn Rust before they're ready—an attitude I disagree with, even if it were true that the author was struggling with SQL.

Read what you wrote. You said that I implied that “ANYTHING they struggle with is their fault.”

I stand by "anything"—your post didn't make any exceptions. I should have been clearer that I was referring to an attitude your comment implied rather than an attitude you have, though, and for that I apologize.

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

#185

Post by arghwhat »

kibwen wrote: post #110
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…

> My code was littered with .as_str() and .to_string(). PSA: If you have a variable that's a String, you can easily pass it to anything that expects a &str just by taking a reference to it: fn i_take_a_str(x: &str) {} let i_am_a_string = "foo".to_string(); i_take_a_str(&i_am_a_string); Every variable of type &str is just a reference to a string whose memory lives somewhere else. In the case of string literals, that m…

Ah, I found that out later but had forgotten all about it. :)

I don't remember how I found out, but it seemed oddly magical until I just now read the docs: String implements Deref. Makes more sense now.

I still had a bunch of to_strings()'s, though, as things tended to take String whenever I had &str's. I found this to be a very unexpected nuisance.

EDIT: Maybe I needed as_str() as the & trick doesn't work if the target type cannot be inferred as &str?

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

#186

Post by arghwhat »

arghwhat wrote: post #66
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.

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…

Oh, and added thing that bugged me a lot: The error part of Result. During my short time of coding Rust (I'll get back to it later), I never really found a way to ergonomically handle errors.

I find it really awkward that the error is a concrete type, making it so that you must convert all errors to "rethrow". Go's error interface, and even exception inheritance seems to have lower friction than this.

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

#187

Post by vvanders »

geezerjay wrote: post #146
pcwalton wrote: post #140

Earlier quoted context omitted.

"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 t…

> Yet if the bar for C++ competence is "never wrote a use-after-free" The bar for C++ competence in that regard is RAII. Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should i…

Oh man, the number of libraries I've used over the years where I got nailed by their use after free/mem overwrite.

Just because you're a perfect developer doesn't mean some downstream dependency isn't going to come along and wreck your day.

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

#188

Post by arghwhat »

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.

I write hardware drivers (mixed kernel/user-mode) for 100Gb/s FPGA network accelerators at work in C and C++ for 3 different OS's. I'd argue that I am very much the target audience for Rust.

And I also find that SQL can be quite infuriating to deal with, and had a high-friction experience with Rust.

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

#189

Post by hsivonen »

geezerjay wrote: post #146
pcwalton wrote: post #140

Earlier quoted context omitted.

"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 t…

> Yet if the bar for C++ competence is "never wrote a use-after-free" The bar for C++ competence in that regard is RAII. Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should i…

> The bar for C++ competence in that regard is RAII.

If it was that simple we'd never need kungFuDeathGrip in Gecko. Yet, we need it a lot: https://searchfox.org/mozilla-central/search?q=kungfu&path=

(KungFuDeathGrip is the pattern of introducing an extra RAII refcount incrementer/decrementer on the stack to avoid subsequent method calls doing something that would free an object from underneath the current stack frame.)

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

#190

Post by pcwalton »

geezerjay wrote: post #146
pcwalton wrote: post #140

Earlier quoted context omitted.

"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 t…

> Yet if the bar for C++ competence is "never wrote a use-after-free" The bar for C++ competence in that regard is RAII. Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should i…

RAII is nowhere near enough to prevent heap use-after-free.
Post reply on HN