Thread

1. u8 · 1790344456 · focus · HN ↗

   This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.

   1. __s · 1790344640 · focus · HN ↗

      go data races aren't memory safe

      1. shikck200 · 1790350210 · focus · HN ↗

         That does not make sense to me. Go is memory-safe, but it does not guarantee data-race freedom.

         So whats your point here? Haskell?

         1. beltsazar · 1790353254 · focus · HN ↗

            > That does not make sense to me.

            You said that because you assumed Go is memory-safe in all conditions.

            > Go is memory-safe

            Yes, but only if there's no data race.

            Go is not like Java. Java doesn't guarantee no data race, but when it happens, it's still memory-safe.

            1. shikck200 · 1790354214 · focus · HN ↗

               Neither Java or Go guarantees data-race freedom. A data race does not by itself make ordinary Java or Go code memory-unsafe in the C/C++ sense.

               I fail to see how a racy Java program is more memory safe than a racy Go program?

               1. josefx · 1790355340 · focus · HN ↗

                  From what I understand a data race on a simple built in feature like an interface pointer can result in a bad address / type pair, which can cause memory safety issues on any future access. I don't think you can get the JVM itself confused about what type a pointer points to.

Unofficial Hacker News client; not affiliated with Y Combinator.