3 ms·

We need more than one “mainstream” (not functional) memory safe language.

by andrewstuart 3y ago

marcosdumay 3y ago
Every mainstream language that isn't C or C++ is memory safe nowadays.
- knorker 3y ago
  Except Go. "Go does have undefined behaviour: if your program has a race condition, the behaviour is undefined" -- Ian Lance Taylor, https://groups.google.com/g/golang-nuts/c/MB1QmhDd_Rk https://groups.google.com/g/golang-nuts/c/MB1QmhDd_Rk It annoys me to no end how Go could be created in the 21st century and willfully ignore so many lessons from the state of the art in language design. The more code I read and write (basically every day, by good programmers), the more disappointed I am in how much of a missed opportunity Go is. There are other fundamental flaws in Go, but that would be off topic.
  - marcosdumay 3y ago
    That's not a memory safety issue. And well, like people keep pointing on that discussion thread, C and C++ undefined behavior isn't just an operation you don't know the result; it's a much deeper and crazier thing that no other language has (unless when they inherit it by sharing compiling tools).
    - knorker 3y ago
      To your second point: Ian Lance Taylor explicitly says that Go has undefined behavior, which as you say is not just "don't know what it is". He (as he shows in this thread too) is, like me, very much aware of what UB is. He's even correcting people who are using the term "undefined" incorrectly. As for "memory safety", maybe you're right on the terminology. But this does mean that in Go a data race, being UB, can do anything. There are no guarantees of no use after free, or read/write out of bounds, anymore. If you create a data race in Go, you are in UB land. And that's one of the many many missed opportunities of Go.
- chrisco255 3y ago
  I think OP means systems languages that are memory safe, without garbage collection and sandboxing.
  - marcosdumay 3y ago
    Hum, nothing on the context implies the argument is about system languages. But yeah, I can imagine somebody so focused on them that they ignore the need to add that bit of context. The issue with system languages is that all the evidence points towards there not being space for a lot of them. So we only get one with whatever properties are most desirable; and it dries the landscape from opportunities for any other with similar features. Thus, no, unless people decide there's some large new problem worth solving on them, we are not getting more memory-safe mainstream system languages. (But it's funny that you say sandboxing, because IMO that, probably with explicit effects is a nice thing to solve if you are trying to create the next generation system language.)

We need more than one “mainstream” (not functional) memory safe language.

marcosdumay 3y ago

Every mainstream language that isn't C or C++ is memory safe nowadays.

knorker 3y ago
Except Go. "Go does have undefined behaviour: if your program has a race condition, the behaviour is undefined" -- Ian Lance Taylor, https://groups.google.com/g/golang-nuts/c/MB1QmhDd_Rk https://groups.google.com/g/golang-nuts/c/MB1QmhDd_Rk It annoys me to no end how Go could be created in the 21st century and willfully ignore so many lessons from the state of the art in language design. The more code I read and write (basically every day, by good programmers), the more disappointed I am in how much of a missed opportunity Go is. There are other fundamental flaws in Go, but that would be off topic.
- marcosdumay 3y ago
  That's not a memory safety issue. And well, like people keep pointing on that discussion thread, C and C++ undefined behavior isn't just an operation you don't know the result; it's a much deeper and crazier thing that no other language has (unless when they inherit it by sharing compiling tools).
  - knorker 3y ago
    To your second point: Ian Lance Taylor explicitly says that Go has undefined behavior, which as you say is not just "don't know what it is". He (as he shows in this thread too) is, like me, very much aware of what UB is. He's even correcting people who are using the term "undefined" incorrectly. As for "memory safety", maybe you're right on the terminology. But this does mean that in Go a data race, being UB, can do anything. There are no guarantees of no use after free, or read/write out of bounds, anymore. If you create a data race in Go, you are in UB land. And that's one of the many many missed opportunities of Go.
chrisco255 3y ago
I think OP means systems languages that are memory safe, without garbage collection and sandboxing.
- marcosdumay 3y ago
  Hum, nothing on the context implies the argument is about system languages. But yeah, I can imagine somebody so focused on them that they ignore the need to add that bit of context. The issue with system languages is that all the evidence points towards there not being space for a lot of them. So we only get one with whatever properties are most desirable; and it dries the landscape from opportunities for any other with similar features. Thus, no, unless people decide there's some large new problem worth solving on them, we are not getting more memory-safe mainstream system languages. (But it's funny that you say sandboxing, because IMO that, probably with explicit effects is a nice thing to solve if you are trying to create the next generation system language.)