Go doesn't really tries to be 'better C'. It's more like "Java but from Google" - they are even repeating the same "mistakes" like having mutable variables by default and the common heap.
And then the philosophy of Go is completely nuts. They are trying to be 'simpler' but it instead results in lots and lots of cruft.
Posted Apr 4, 2013 4:08 UTC (Thu) by imgx64 (guest, #78590)
[Link]
> Go doesn't really tries to be 'better C'. It's more like "Java but from Google"
Java? What does Go have in common with Java?
Go didn't even start its life as "something from Google" (unlike Dart for example). It started as a 20% project by Rob Pike, Ken Thompson, et al. then other developers at Google started using it because they found it a good fit for their problems.
> having mutable variables by default and the common heap.
Like I said, "practical"--that's how computers work.
> And then the philosophy of Go is completely nuts. They are trying to be 'simpler' but it instead results in lots and lots of cruft.
What kind of cruft are you objecting to? make()? append() and friends?
I agree they're not orthogonal, and to an outsider, they feel like a kludge for the lack of generics. But after using them for a while, they don't bother me much. And the simplicity of the rest of Go more than makes up for any conceived "cruft".
Rust-lang
Posted Apr 4, 2013 4:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
>Java? What does Go have in common with Java?
"Style" of it.
>Like I said, "practical"--that's how computers work.
No it isn't. CPUs now quite often have their own local memory so having explicit support for local arenas is becoming essential.
> What kind of cruft are you objecting to? make()? append() and friends?
The idiotic error handling with tuples. For example. Then the whole generics fiasco.
From what I'm seeing, a lot of Go code out there simply has no error handling - it either works or fails mysteriously.