Comment by returningfory2

Comment by returningfory2 a day ago

3 replies

The code in the article is not wrong. It is not unsafe. The author explicitly handles the OOM case correctly. It is true that there are more optimal ways to do it if you do have an OOM handling strategy.

And no, you're not supposed to teach your students the best way to do things at the start. That's not how teaching works. You start with the simpler (but still correct) way, and then work towards the best way. This is why introductions to Rust are full of clone calls. The best Rust code minimizes the number of clones. But when you're introducing people to something, you don't necessarily do the optimal thing first because that disrupts the learning process.

dataflow a day ago

> The code in the article is not wrong. It is not unsafe. The author explicitly handles the OOM case correctly.

And hence we circle back to what I just wrote above: you're confusing the code with the program that it compiles to. Because the code isn't there solely for the purpose of being compiled into a program, it's also serving as a stepping stone for other things (learning, modification, whatever). https://news.ycombinator.com/item?id=42733611

If it helps to phrase it differently: the code might be "compile-safe", but not "modification-safe" or "learning-safe".

  • returningfory2 a day ago

    I don't see why the code is not "learning safe". The code presents the simplest safe way to handle an OOM condition. Seems basically perfect for a _beginners guide_ to manual memory management.

    • dataflow a day ago

      It's not learning-safe because it teaches said learners to write bad code like this.