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

A half-hour to learn Rust

fasterthanli.me

Post reply on HN
Print view View original

281–290 of 342 posts

Re: A half-hour to learn Rust

#281

Post by cpeterso »

GrumpySloth wrote: post #275
gpm wrote: post #240

Earlier quoted context omitted.

My housemate was just rolling back from python 3.8 to 3.7 yesterday due to a backwards incompatible change breaking a library... it's not just 2 -> 3 that makes python relatively unstable compared to rust.

Yup, similar is 3.5->3.7. The community also doesn't seem to value backwards-compatiblity, judging from the libraries.

And I recently had to roll back from Python 3.9 to 3.7 to work around a couple different problems with the cffi and zstandard libraries on macOS 11.

Re: A half-hour to learn Rust

#282

Post by the8472 »

unethical_ban wrote: post #237
jgraham wrote: post #234

Earlier quoted context omitted.

I've shipped relatively lots of code in Python and a little bit in Rust. For any project where performance or correctness are significant concerns I'd much rather use Rust than Python. It provides a lot more tools to help you write correct code, and express invariants in a machine-checkable way. This means that they are maintained when the code changes, even when multiple contributors are involved. I'm must more conf…

My only bone to pick with this commentary is that it is 2020 and people are still complaining about Python as being unstable because of 2 -> 3. It was a rough transition, to be sure. Python2 was released 20 years ago, and Python3 12 years ago. It is a pretty stable language.

Some industries are very very slow when it comes to upgrades. E.g. the VFX reference platform[0] only adopted python 3 for the 2020 baseline, which means many recently released products are still embedding python 2.x [1].

[0] https://vfxplatform.com/ [1] https://vfxpy.com/

Re: A half-hour to learn Rust

#283

Post by _nckn »

artursapek wrote: post #268
_nckn wrote: post #191

Earlier quoted context omitted.

Try to use that in real world and see if your love still stays put. An hour is not enough to validate Rust.

Typical condescending HN response. We are using Rust, we've used it to build and ship a successful native desktop app.

In which sentence is this condesdending?

Re: A half-hour to learn Rust

#284

Post by snewman »

yakubin wrote: post #276
fasterthanlime wrote: post #190

Earlier quoted context omitted.

That's one of the things that get me about Rust discourse: it seems that "Rust is pain in exchange for performance" is a common misconception. Rust is discipline in exchange for performance and correctness . A GC lets you be relatively worry-free as far as memory leaks go (and even then..) but it doesn't prevent a lot of the correctness problems the borrow checker would. With a checker you're forced to think: do I re…

I don't see how a GC would do anything with memory leaks. When you have a data structure containing some elements, and you keep a reference to the structure, because you need some data from it, but you let it grow, then you have a leak, GC or no GC. If anything, GC encourages memory leaks by making freeing memory implicit, something a programmer normally doesn't think about. And yet a resize/push operation on a vecto…

GC also protects you against forget-to-free, which in most non-GC languages is a common form of memory leak.

Re: A half-hour to learn Rust

#285

Post by yakubin »

snewman wrote: post #284
yakubin wrote: post #276

Earlier quoted context omitted.

I don't see how a GC would do anything with memory leaks. When you have a data structure containing some elements, and you keep a reference to the structure, because you need some data from it, but you let it grow, then you have a leak, GC or no GC. If anything, GC encourages memory leaks by making freeing memory implicit, something a programmer normally doesn't think about. And yet a resize/push operation on a vecto…

GC also protects you against forget-to-free, which in most non-GC languages is a common form of memory leak.

That's just exchanging forget-to-free for forget-to-drop-reference.

Re: A half-hour to learn Rust

#287

Post by snewman »

yakubin wrote: post #285
snewman wrote: post #284

Earlier quoted context omitted.

GC also protects you against forget-to-free, which in most non-GC languages is a common form of memory leak.

That's just exchanging forget-to-free for forget-to-drop-reference.

But it's much easier to forget-to-free:

  Foo* foo = new Foo();
  ...code that uses foo...
This is a memory leak in a non-GC language, but not in a GC language.

In a practical sense... is it your personal experience that memory leaks are equally prevalent in GC and non-GC languages? I've spent decades working in each (primarily C++ and Java, but also Pascal, C, C#, Smalltalk...) and my experience is that memory leaks were a _much_ bigger issue, in practice, in the non-GC languages.

Re: A half-hour to learn Rust

#288

Post by yakubin »

snewman wrote: post #287
yakubin wrote: post #285

Earlier quoted context omitted.

That's just exchanging forget-to-free for forget-to-drop-reference.

But it's much easier to forget-to-free: Foo* foo = new Foo(); ...code that uses foo... This is a memory leak in a non-GC language, but not in a GC language. In a practical sense... is it your personal experience that memory leaks are equally prevalent in GC and non-GC languages? I've spent decades working in each (primarily C++ and Java, but also Pascal, C, C#, Smalltalk...) and my experience is that memory leaks wer…

This is a memory leak in a GC language as well, depending on what happens to foo in ...code that uses foo... Maybe it will become a field of some class, maybe it will get pushed to some queue, maybe it will get captured in a lambda, etc. You won't even be able to tell just from looking at this code in this one place alone, if you passed this pointer as argument to a function.

It is my experience that when people work with GC languages, they treat the GC as a blackbox (which it is) and simply won't bother investigating: do they have memory leaks? Of course not, they are using a GC after all, all memory-related problems solved, right? Right... With code that relies on free(), I can use a debugger and check which free() calls are hit for which pointers. Even better, I may use an arena allocator where appropriate and don't bother with free() at all. With a GC I'm just looking at some vague heap graph. Am I leaking memory? Who knows... "Do those numbers look right to you?"

Memory management issues are usually symptoms of architectural issues. A GC won't fix your architecture, but it will make your memory management issues less visible.

It is my experience that most memory problems in C come from out-of-bounds writes (which includes a lot more than just array access), not from anything related to free(). A GC doesn't help here.

Re: A half-hour to learn Rust

#289

Post by snewman »

yakubin wrote: post #288
snewman wrote: post #287

Earlier quoted context omitted.

But it's much easier to forget-to-free: Foo* foo = new Foo(); ...code that uses foo... This is a memory leak in a non-GC language, but not in a GC language. In a practical sense... is it your personal experience that memory leaks are equally prevalent in GC and non-GC languages? I've spent decades working in each (primarily C++ and Java, but also Pascal, C, C#, Smalltalk...) and my experience is that memory leaks wer…

This is a memory leak in a GC language as well, depending on what happens to foo in ...code that uses foo... Maybe it will become a field of some class, maybe it will get pushed to some queue, maybe it will get captured in a lambda, etc. You won't even be able to tell just from looking at this code in this one place alone, if you passed this pointer as argument to a function. It is my experience that when people work…

Per Wikipedia:

> In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released.

In most of your scenarios, e.g. "pushed to some queue", the object in question is still needed. Hence, this is not a leak. Presumably, the entry will eventually be removed from the queue, and GC will then reclaim the object.

At any rate, I think we're moving past the point of productive discussion. My experience in practice is that memory leaks are more common / harder to avoid in non-GC languages. Of course a true memory leak (per the definition above) is possible in a GC language, but I just don't see it much in practice. Perhaps your experience is different.

Re: A half-hour to learn Rust

#290

Post by kochismo »

mikepurvis wrote: post #272
projct wrote: post #266

Earlier quoted context omitted.

If you get rid of unwrap and use `if let` and `match`, this code will clean up nicely. If the code is supposed to be maintainable, you could also make something like a FromRegex trait for Input. It would be a good idea to try exercism's mentoring thing to get better at writing it the easier way the first time. The mentoring thing really is what helped me to think in ways that made this mess easier to avoid.

Fair fair. To be honest, I think in a lot of these cases there are good helper crates/macros; for this I would now probably use recap: https://docs.rs/recap/0.1.1/recap/ The really horrendous scenario was when I was trying to navigate pest iterators for parsing according to a grammar.

Even without if let or match many of those unwraps are unnecessary. See https://github.com/zookini/aoc-2020/blob/master/src/bin/2.rs
Post reply on HN