6 ms·

> doesn't seem like you go back and change things to be like Java Java is like Go in that regard. That's why you have to use ConcurrentHashMap instead of HashM

> doesn't seem like you go back and change things to be like Java Java is like Go in that regard. That's why you have to use ConcurrentHashMap instead of HashMap for instance.

deleted 5y ago
[deleted]
ibraheemdev 5y ago
Java will throw a ConcurrentModificationException. Go can cause undefined behavior.
- papercrane 5y ago
  Java might throw a ConcurrentModificationException. The docs are quite clear that it's not guaranteed and best-effort only.
- ngrilly 5y ago
  This is not guaranteed at all: > Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs. Source: https://docs.oracle.com/javase/8/docs/api/java/util/Vector.html https://docs.oracle.com/javase/8/docs/api/java/util/Vector.h... This is conceptually similar to the race detector in Go, which is also a debugging tool, but without strict guarantees.
twotwotwo 5y ago
Java's trick is maintaining memory/type safety in the presence of races. You might crash, and your application might not see the values it expects, but you never get a buffer-overflow-like situation where Java's internal structures might get corrupted in arbitrary ways, for example.
- ngrilly 5y ago
  I see your point now. Yes, Java won't segfault, unlike Go on slices/maps/interface values. But even without segfaults, undefined behaviors due to race conditions can still be pretty in Java (causing infinite loops, memory leaks, etc.). Maybe it's better to let the program crash with a segfault. https://stackoverflow.com/questions/51102644/what-the-worst-thing-that-can-happen-if-i-write-concurrently-from-multiple-trea https://stackoverflow.com/questions/51102644/what-the-worst-...
  - gpderetta 5y ago
    No it is not better. Java will preserve the integrity of the runtime. Still memory safety issues in go due to races are probably very hard to exploit so it might not make a huge difference in practice.
    - ngrilly 5y ago
      Yes, the JVM will keep executing the program, but I'm still not convinced this is strictly better than segfaulting if a thread is stuck in an infinite loop using CPU for nothing, and another is leaking memory.
      - gpderetta 5y ago
        It is better than invoking random code because the runtime mistakes some data for a vtable pointer.
        ngrilly 5y ago
        I agree that a data race on an interface value in Go, is worse than an infinite loop or a memory leak, because it can lead to calling the wrong method on a value, which is hard to debug.
        yc12340 5y ago
        ...and easy to exploit

> doesn't seem like you go back and change things to be like Java Java is like Go in that regard. That's why you have to use ConcurrentHashMap instead of HashMap for instance.

deleted 5y ago

[deleted]

ibraheemdev 5y ago

Java will throw a ConcurrentModificationException. Go can cause undefined behavior.

papercrane 5y ago
Java might throw a ConcurrentModificationException. The docs are quite clear that it's not guaranteed and best-effort only.
ngrilly 5y ago
This is not guaranteed at all: > Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs. Source: https://docs.oracle.com/javase/8/docs/api/java/util/Vector.html https://docs.oracle.com/javase/8/docs/api/java/util/Vector.h... This is conceptually similar to the race detector in Go, which is also a debugging tool, but without strict guarantees.

twotwotwo 5y ago

Java's trick is maintaining memory/type safety in the presence of races. You might crash, and your application might not see the values it expects, but you never get a buffer-overflow-like situation where Java's internal structures might get corrupted in arbitrary ways, for example.

ngrilly 5y ago
I see your point now. Yes, Java won't segfault, unlike Go on slices/maps/interface values. But even without segfaults, undefined behaviors due to race conditions can still be pretty in Java (causing infinite loops, memory leaks, etc.). Maybe it's better to let the program crash with a segfault. https://stackoverflow.com/questions/51102644/what-the-worst-thing-that-can-happen-if-i-write-concurrently-from-multiple-trea https://stackoverflow.com/questions/51102644/what-the-worst-...
- gpderetta 5y ago
  No it is not better. Java will preserve the integrity of the runtime. Still memory safety issues in go due to races are probably very hard to exploit so it might not make a huge difference in practice.
  - ngrilly 5y ago
    Yes, the JVM will keep executing the program, but I'm still not convinced this is strictly better than segfaulting if a thread is stuck in an infinite loop using CPU for nothing, and another is leaking memory.
    - gpderetta 5y ago
      It is better than invoking random code because the runtime mistakes some data for a vtable pointer.
      - ngrilly 5y ago
        I agree that a data race on an interface value in Go, is worse than an infinite loop or a memory leak, because it can lead to calling the wrong method on a value, which is hard to debug.
        yc12340 5y ago
        ...and easy to exploit