4 ms·

I Don’t Much Get GO

3 points by desigooner 16y ago

mhd 16y ago
While I don't exactly agree with his general assessment of C# as a language, I'm more baffled by the fact that he doesn't seem to get that Go is supposed to be a systems-level programming language, which precludes any virtual machine. It's not meant to replace C++/Java/C# as a language to build large enterprise systems/GUIs, but C/C++ as server/OS-level implementation languages. The sweet spot is a bit different.
- jacquesm 16y ago
  To be fair, he did say 'I don't get go', that just illustrates that he's right, he doesn't get it. Go is an improved C, not a modified Java, C++ or C#.
vital101 16y ago
Go is not a language to write a massive enterprise level program in. It's meant to be used at the system level, and it excels at that. He was right, he really doesn't "get" Go.
ngvrnd 16y ago
Also, he's clearly in the "zero-sum game" camp -- I like the "let a thousand flowers bloom" notion myself. If there's anything to Go, it will eventually become widely used. If not, ... it may at least influence the development of another language. We've pretty much entered the Cambrian Explosion of language design anyway, and what's wrong with that?
- mhd 16y ago
  I think he'd be okay with multiple languages (he even mentions F#), as long as they share a common runtime. And as long as that runtime is the CLR. I hope other .NET developers have a broader view and don't consider the CLR the sine qua non of programming.
frognibble 16y ago
There are many fundamental errors about Go in the article: the := operator distinguishes declare and assign from pure assignment, not assignment from equality as the author states. Pointers in Go do not make the language unsafe. Pointers in Go do not relegate automatic memory management to a "supposed" feature. Goroutines are not the same thing as threads. The lack of implicit "this" in methods does not make methods a low value add feature over static functions. There are several more errors in the article. Read it with caution.

3 points by desigooner 16y ago

mhd 16y ago

While I don't exactly agree with his general assessment of C# as a language, I'm more baffled by the fact that he doesn't seem to get that Go is supposed to be a systems-level programming language, which precludes any virtual machine. It's not meant to replace C++/Java/C# as a language to build large enterprise systems/GUIs, but C/C++ as server/OS-level implementation languages. The sweet spot is a bit different.

jacquesm 16y ago
To be fair, he did say 'I don't get go', that just illustrates that he's right, he doesn't get it. Go is an improved C, not a modified Java, C++ or C#.

vital101 16y ago

Go is not a language to write a massive enterprise level program in. It's meant to be used at the system level, and it excels at that. He was right, he really doesn't "get" Go.

ngvrnd 16y ago

Also, he's clearly in the "zero-sum game" camp -- I like the "let a thousand flowers bloom" notion myself. If there's anything to Go, it will eventually become widely used. If not, ... it may at least influence the development of another language. We've pretty much entered the Cambrian Explosion of language design anyway, and what's wrong with that?

mhd 16y ago
I think he'd be okay with multiple languages (he even mentions F#), as long as they share a common runtime. And as long as that runtime is the CLR. I hope other .NET developers have a broader view and don't consider the CLR the sine qua non of programming.

frognibble 16y ago

There are many fundamental errors about Go in the article: the := operator distinguishes declare and assign from pure assignment, not assignment from equality as the author states. Pointers in Go do not make the language unsafe. Pointers in Go do not relegate automatic memory management to a "supposed" feature. Goroutines are not the same thing as threads. The lack of implicit "this" in methods does not make methods a low value add feature over static functions. There are several more errors in the article. Read it with caution.