3 ms·

Java's "try with resources" is effectively the same as Go's 'defer' and Python's 'with', so the advantage is that you can't forget to do it. No matter what you

Java's "try with resources" is effectively the same as Go's 'defer' and Python's 'with', so the advantage is that you can't forget to do it. No matter what you do, when the object goes out of scope, the resource will be closed.

pjmlp 4y ago
If you actually use static analysis, you can't forget it in Java either. And it isn't as if using languages without static analysis is still considered a best practice in the 21st century.
- tialaramex 4y ago
  > And it isn't as if using languages without static analysis is still considered a best practice in the 21st century. So in summary, "Please just do better". Not helpful as a video game meme, and really no better for programming.
  - pjmlp 4y ago
    I guess that is why no one bothers with clippy then, it is superfluous.
    - tialaramex 4y ago
      Everywhere that a clippy lint is there to catch bugs, I wish it wasn't a clippy lint because it won't always get run and those bugs will get missed. An example of a clippy lint that I like in clippy: If you try to transmute() &[u8] into a &str clippy will point out that you should probably from_utf8_unchecked() -- this lint results in code that does the same thing but is clearer for maintainers about what we intended. If our reaction to the lint is "But it isn't UTF-8" then we just got an important red flag, but that's not why the lint is there. On the other hand, clippy lints for truncating casts and I want those gone from the language so the warnings ought to at least live in the compiler not clippy. I would like to see a future Edition outlaw these casts entirely so that you need to write a truncating cast explicitly if that's what you needed.
- throwaway2037 4y ago
  Is Java escape analysis done at compile time or run time? I don't know. FYI: As I understand, escape analysis is frequently used to either (a) avoid allocating on the heap, or (b) auto-magically free-ing a malloc'd object from a tight scope.
  - pjmlp 4y ago
    First of all it depends on the implementation, the language specification doesn't state how it works. https://en.m.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.m.wikipedia.org/wiki/List_of_Java_virtual_machine... As it stands is mostly done at runtime and only for a). Otherwise you are better with try-resources, and for something like malloced memory there are off-GC heap APIs. Also Valhalla will eventually land, although it is getting long by now.
    - vips7L 4y ago
      Personally I wish they would move some escape analysis to compile time just to help with memory consumption. I’m assuming it would require byte code changes though.
SemanticStrengh 4y ago
Kotlin doesn't allow mistakes https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.io/use.html https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.io/use.h... For structured concurrency too.

pjmlp 4y ago

If you actually use static analysis, you can't forget it in Java either. And it isn't as if using languages without static analysis is still considered a best practice in the 21st century.

tialaramex 4y ago
> And it isn't as if using languages without static analysis is still considered a best practice in the 21st century. So in summary, "Please just do better". Not helpful as a video game meme, and really no better for programming.
- pjmlp 4y ago
  I guess that is why no one bothers with clippy then, it is superfluous.
  - tialaramex 4y ago
    Everywhere that a clippy lint is there to catch bugs, I wish it wasn't a clippy lint because it won't always get run and those bugs will get missed. An example of a clippy lint that I like in clippy: If you try to transmute() &[u8] into a &str clippy will point out that you should probably from_utf8_unchecked() -- this lint results in code that does the same thing but is clearer for maintainers about what we intended. If our reaction to the lint is "But it isn't UTF-8" then we just got an important red flag, but that's not why the lint is there. On the other hand, clippy lints for truncating casts and I want those gone from the language so the warnings ought to at least live in the compiler not clippy. I would like to see a future Edition outlaw these casts entirely so that you need to write a truncating cast explicitly if that's what you needed.
throwaway2037 4y ago
Is Java escape analysis done at compile time or run time? I don't know. FYI: As I understand, escape analysis is frequently used to either (a) avoid allocating on the heap, or (b) auto-magically free-ing a malloc'd object from a tight scope.
- pjmlp 4y ago
  First of all it depends on the implementation, the language specification doesn't state how it works. https://en.m.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.m.wikipedia.org/wiki/List_of_Java_virtual_machine... As it stands is mostly done at runtime and only for a). Otherwise you are better with try-resources, and for something like malloced memory there are off-GC heap APIs. Also Valhalla will eventually land, although it is getting long by now.
  - vips7L 4y ago
    Personally I wish they would move some escape analysis to compile time just to help with memory consumption. I’m assuming it would require byte code changes though.

SemanticStrengh 4y ago

Kotlin doesn't allow mistakes https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.io/use.html https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.io/use.h... For structured concurrency too.