Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @06:07AM
(#2646213)
The only reason to use Go is if you've fallen victim to the Google hype. There's no reason to use a slightly less shitty version of C with most of its fundamental problems (shared mutable state, nullability by default...) fully intact but orders of magnitude fewer programmers when you can just use C.
Re:Reasons for using Golang
by derefr on Sunday June 12, 2011 @06:19AM
(#2646229)
> fundamental problems (shared mutable state, nullability by default...)
Those aren't the "fundamental problems of C", those are the reasons people use C in the first place. The point of "systems languages" like C and Go is that they directly expose a (standardized interface to) the Von Neumann architecture your computer actually implements, which allows for arbitrary references to memory that may be uninitialized, multiply-aliased, etc. This is what allows for the efficient implementation of such things as garbage collectors, process schedulers, virtual memory managers, IPC libraries, network stacks, and so forth, that the runtimes for higher-level languages rely upon as fundamental abstractions.
So, given the assumption that such code is necessary to write, why shouldn't we try to have a better language to write it in than C? I'm not suggesting that Go is such a language, but your argument seems to be that it's pointless to try to do better than C (because every language, no matter how good, starts with no one using it, and thus necessarily will have fewer programmers than C does.)
Re:Reasons for using Golang
by JulianMorrison on Sunday June 12, 2011 @12:12PM
(#2646710)
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.
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.
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @07:08PM
(#2647618)
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.
Re:Reasons for using Golang
by JulianMorrison on Sunday June 12, 2011 @08:55PM
(#2647776)
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.
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @11:31PM
(#2648018)
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.
Re:Reasons for using Golang
by JulianMorrison on Monday June 13, 2011 @07:15AM
(#2648679)
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.
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @06:21AM
(#2646233)
Justify the need for nullability by default (and not something like the Maybe monad) to implement (say) a process scheduler. Justify the need for nullability by default (and not something like the Maybe monad) to implement a network stack. Go does GC itself, so writing a garbage collector in Go is too inception-y.
My point is that it's stupid and harmful to do a little better than C when you can actually learn from experience [1] and the last forty years of PL research and do much better than C.
Re:Reasons for using Golang
by derefr on Sunday June 12, 2011 @06:31AM
(#2646243)
Edit: I see that you've changed your request. This was originally "justify the need for (say) unsafe pointers in (say) a process scheduler."
A process scheduler's job involves saving and unloading the virtual memory mapping of a process that is blocked or pre-empted, and overwriting it with the virtual memory mapping of a new process. The process scheduler must have direct access to physical memory in order to perform this transition. Any kind of pointer safety would be built on top of a virtual memory abstraction; the process scheduler must necessarily be outside of this abstraction to do its job.
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @06:35AM
(#2646244)
The process scheduler must have direct access to physical memory in order to perform this transition.
Given that a scheduler's going to be running in kernel mode, why can it not just muck around with kernel address space and leave it to the page table to do the translation?
Yeah, I did clarify my request a little -- by safe I meant safe with optional nullability.
Re:Reasons for using Golang
by ori_b on Sunday June 12, 2011 @07:45AM
(#2646309)
How does it muck about with the kernel address space again? Oh right, by writing to magic locations in memory. The same way that you interface with virtually all hardware, for that matter.
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @03:03PM
(#2647126)
No, you misunderstand: I believe most of the operations you need to perform a context switch are safe in the kernel's context. Sure, you'll need a bit of assembly code to copy out and set registers and stuff, and you can't do that bit in C either. But other than that, safe pointers should work.
Re:Reasons for using Golang
by quag on Sunday June 12, 2011 @06:39AM
(#2646251)
"you've fallen victim to the Google hype"?!
Since when has Google been hyping Go? I've only come across the Go team itself talking about Go in public. The language comes across as "a language created by people at Google" much more than, "Google's language".
The feel from watching the weekly releases is that apart from the work of the (tiny) Go team, there are more patches coming from the public than from within Google.
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @06:45AM
(#2646254)
The Google hype for Go is fairly indirect: it's basically people hyping Go because it's "a language created by people at Google", as you say. Look at how the user who wrote that comment's completely star-struck -- "Go is well designed, in all apsects (sic)". It's as if he thinks it's a language straight from the Google heavens, gracing us mortals with its existence.
Re:Reasons for using Golang
by benihana on Sunday June 12, 2011 @11:54AM
(#2646673)
Maybe when it was first announced, Go was considered a language created by people at Google. Now it's more considered a language being written by Rob Pike and Ken Thompson.
Re:Reasons for using Golang
by ajays on Sunday June 12, 2011 @12:03PM
(#2646692)
Even if it's "Google hype", so what? In the end, superior tools will win on their own merits. People are not idiots to be just blinded by Google's logo; Google is a teenager now, and the hype has worn off, IMHO.
Given _any_ language, I can find some non-empty problem set where that language performs badly (or is ill-suited). That does not take anything away from the language. There is no "perfect" language yet; maybe we'll get one in 5 years... [1]
Re:Reasons for using Golang
by sid0 on Sunday June 12, 2011 @07:13PM
(#2647620)
The set of problems for which Go is the best programming language to use is empty, simply because Rust exists. Rust has non-nullability, immutable shared state...
Re:Reasons for using Golang
by enneff on Sunday June 12, 2011 @08:16PM
(#2647713)
Rust is nowhere near ready. A language is more than a language spec and a compiler. Its the standard library and ecosystem of tools that make a language truly useful. Go has those, Rust does not. It is unfair to both projects to compare them.
Those aren't the "fundamental problems of C", those are the reasons people use C in the first place. The point of "systems languages" like C and Go is that they directly expose a (standardized interface to) the Von Neumann architecture your computer actually implements, which allows for arbitrary references to memory that may be uninitialized, multiply-aliased, etc. This is what allows for the efficient implementation of such things as garbage collectors, process schedulers, virtual memory managers, IPC libraries, network stacks, and so forth, that the runtimes for higher-level languages rely upon as fundamental abstractions.
So, given the assumption that such code is necessary to write, why shouldn't we try to have a better language to write it in than C? I'm not suggesting that Go is such a language, but your argument seems to be that it's pointless to try to do better than C (because every language, no matter how good, starts with no one using it, and thus necessarily will have fewer programmers than C does.)
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.
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?
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.
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.
My point is that it's stupid and harmful to do a little better than C when you can actually learn from experience [1] and the last forty years of PL research and do much better than C.
[1] http://qconlondon.com/london-2009/presentation/Null+Referenc...
A process scheduler's job involves saving and unloading the virtual memory mapping of a process that is blocked or pre-empted, and overwriting it with the virtual memory mapping of a new process. The process scheduler must have direct access to physical memory in order to perform this transition. Any kind of pointer safety would be built on top of a virtual memory abstraction; the process scheduler must necessarily be outside of this abstraction to do its job.
Given that a scheduler's going to be running in kernel mode, why can it not just muck around with kernel address space and leave it to the page table to do the translation?
Yeah, I did clarify my request a little -- by safe I meant safe with optional nullability.
Since when has Google been hyping Go? I've only come across the Go team itself talking about Go in public. The language comes across as "a language created by people at Google" much more than, "Google's language".
The feel from watching the weekly releases is that apart from the work of the (tiny) Go team, there are more patches coming from the public than from within Google.
Hype. What hype?
And to be brutally honest, its the only reason I initially even gave it a glance.
Given _any_ language, I can find some non-empty problem set where that language performs badly (or is ill-suited). That does not take anything away from the language. There is no "perfect" language yet; maybe we'll get one in 5 years... [1]
[1] http://www.great-quotes.com/quote/63358