5 ms·

Well, no, the state that's shared, is shared across goroutines in Go, or across Posix threads in C. Those are not directly exposing the machine, those are expos

Well, no, the state that's shared, is shared across goroutines in Go, or across Posix threads in C. Those are not directly exposing the machine, those are exposing a particular type of abstract machine over the actual machine. Contrast Erlang processes which are built on the same machine but have different assumptions (message passing by copying, no shared state) In fact there are hardware models that fit Erlang better, such as non-cache-coherent NUMA. So from a certain perspective, it's not that C is low level, it's that the CPU was designed to execute C. And the CPU is anyhow general enough to be used in non-C-like ways. I personally think Go missed a trick when it didn't require channel data to be provably impossible to alias across goroutines. (It could be immutable, pass-by-value, or "unique" such that aliasing is disallowed.) As for nulls, Go actually doesn't really have them, the poster above is mistaken - Go has zeroed values, and you are encouraged to make them valid-but-empty. That includes zeroed pointers.

sid0 15y ago
Go has zeroed values, and you are encouraged to make them valid-but-empty. That includes zeroed pointers. Is there a material difference between that and null? I don't care what I'm "encouraged" to do -- does the language force you to opt in to null?
- JulianMorrison 15y ago
  http://golang.org/doc/go_spec.html#The_zero_value http://golang.org/doc/go_spec.html#The_zero_value Yes if you're using pointer-like things, but at least in Go it's an unsurprising thing, all uninitialized data is zeroed. And Go permits you to work with by-value structs and arrays if you want.
  - sid0 15y ago
    t.next == nil I don't give a fuck whether it's called null or 0 or nil or whatever, or whether it's amazing or surprising or shocking. Every single pointer has null as a possible value, which means Go suffers from what I think is the biggest possible mistake a (non-scripting) programming language could make (and I'm not alone -- Tony Hoare thinks the same). The worst thing about all this is that we already have a well-known and well-studied solution in the Maybe monad, yet the Go designers buried their collective heads in the sand here.
    - JulianMorrison 15y ago
      On the upside, Go does not suffer from the common Java anti pattern of returning a semantically meaningful null. Its multiple return means that while it can't return "Maybe Foo", it usually returns something like "Either Error Foo", with the multiple assignment taking the place of a rather primitive pattern match. Also a go function is typically structured like a primitive Either monad - it returns with an error immediately if it gets one, or else it returns from the end with a value.
      - sid0 15y ago
        Tons of functions in most imperative languages are structured in an early-return-on-error style, with exceptions simply being a special case of that. That is neither novel nor uncommon.
        JulianMorrison 15y ago
        But not with multiple return where (as an idiomatic design pattern) the same error object is passed up through the call stack until something decides to handle it, which is what the Either monad does. (And unlike exceptions, the Go way and the Either monad are both explicit, there are no unmarked returns.) The C way with single return means that it's generally impossible to just forward the same error object - the caller has a different type from the callee, so where one returns null another has to return -1, and so forth.

sid0 15y ago

Go has zeroed values, and you are encouraged to make them valid-but-empty. That includes zeroed pointers. Is there a material difference between that and null? I don't care what I'm "encouraged" to do -- does the language force you to opt in to null?

JulianMorrison 15y ago
http://golang.org/doc/go_spec.html#The_zero_value http://golang.org/doc/go_spec.html#The_zero_value Yes if you're using pointer-like things, but at least in Go it's an unsurprising thing, all uninitialized data is zeroed. And Go permits you to work with by-value structs and arrays if you want.
- sid0 15y ago
  t.next == nil I don't give a fuck whether it's called null or 0 or nil or whatever, or whether it's amazing or surprising or shocking. Every single pointer has null as a possible value, which means Go suffers from what I think is the biggest possible mistake a (non-scripting) programming language could make (and I'm not alone -- Tony Hoare thinks the same). The worst thing about all this is that we already have a well-known and well-studied solution in the Maybe monad, yet the Go designers buried their collective heads in the sand here.
  - JulianMorrison 15y ago
    On the upside, Go does not suffer from the common Java anti pattern of returning a semantically meaningful null. Its multiple return means that while it can't return "Maybe Foo", it usually returns something like "Either Error Foo", with the multiple assignment taking the place of a rather primitive pattern match. Also a go function is typically structured like a primitive Either monad - it returns with an error immediately if it gets one, or else it returns from the end with a value.
    - sid0 15y ago
      Tons of functions in most imperative languages are structured in an early-return-on-error style, with exceptions simply being a special case of that. That is neither novel nor uncommon.
      - JulianMorrison 15y ago
        But not with multiple return where (as an idiomatic design pattern) the same error object is passed up through the call stack until something decides to handle it, which is what the Either monad does. (And unlike exceptions, the Go way and the Either monad are both explicit, there are no unmarked returns.) The C way with single return means that it's generally impossible to just forward the same error object - the caller has a different type from the callee, so where one returns null another has to return -1, and so forth.