Reasons for using Golang(programmers.stackexchange.com)
programmers.stackexchange.com
Reasons for using Golang
http://programmers.stackexchange.com/questions/82179/examples-of-beautiful-go/82307#82307
1 comments
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.
> 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.)
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.)
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.
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.
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?
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?
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.
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.
t.next == nil
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.
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.
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.
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.
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.
[1] http://qconlondon.com/london-2009/presentation/Null+Referenc...
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...
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.
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.
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.
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.
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.
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.
"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.
Hype. What 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.
Hype. What hype?
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.
If anything, Go's popularity has been driven primary by (entirely earned) Ken Thompson hype.
Seriously? Every time I heard someone mention Go, they linked it to google to make it sounds as big as possible.
Seriously! When I first started hearing about Go, it was always in the context of Ken Thompson's new language (that he wrote while working at Google).
Yes seriously. Ken Thompson's involvement in it is mentored, often exaggerated, in just about every introduction piece I see about it.
And to be brutally honest, its the only reason I initially even gave it a glance.
And to be brutally honest, its the only reason I initially even gave it a glance.
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.
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]
[1] http://www.great-quotes.com/quote/63358
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
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...
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.
Sure, but the world would have been a better place had Go not existed and Rust had all the limelight.