Not this zealotry again.
What Golang Is and Is Not
61–70 of 279 posts
Re: What Golang Is and Is Not
#62Earlier quoted context omitted.
Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.
One thing I can credit Go for is leading me from the untyped world to the typed one. I soon found the holes in the Go type system, and went looking for a stronger type system. I now generally prefer Haskell.
If Go is from typed world, then Perl too.
Some magical built-in types (scalar, array, hash, typeglob, regexp, io handle) you cannot confuse, interface{} is scalar holding a reference, and built-in datatypes (arrays and hashes) are magical and you cannot construct something similar. Well, at least there's 'tie' mechanics in Perl after all that makes types extensible.
Re: What Golang Is and Is Not
#63I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.
Some languages support tuples - you can also use stuff like ADTs to the same effect. I think Go's advantage here is that it's the only way to handle non-panic exceptions, so you won't have systems where half of the errors are handled with exceptions and half with returning tuples, for instance...(I personally like the lack of "throwing exceptions" part, but find the multiple-return somewhat exotic)
Re: What Golang Is and Is Not
#64> Custom data structures can be composed from the well understood builtins, rolled in under 100 lines of code and can can exist close to the place they are used (yes repeated!). The effect of this approach on readability, maintainability, decoupling, ... adds so much more value to the whole lifecycle, than the cost of the omission.
It's interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google's source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It's of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.
Re: What Golang Is and Is Not
#65Earlier quoted context omitted.
The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric t…
If we consider Go in the context of a systems (their definition) engineering language within Google's enterprise, limiting choice is not about how dumb the programmers are, but about ensuring conformity. Rewriting code is expensive. As my office knows well. We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant en…
> limiting choice is not about how dumb the programmers are, but about ensuring conformity.
What you say doesn't make sense given how Go reflection is implemented. If it was really about limiting choice Go would have no reflection . Go reflection is basically a way to opt-out of its (poor) type system. You should never have to do that in a statically typed language yet Go reflection is used a lot in the standard library itself.
Furthermore let's be honest. What do you think is more complicated ? generics or concurrency ? generics aren't complicated, at all.
> We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant enough for new features.
But Go isn't for embedded system programming. You can't run Go on bare metal without an OS.
Re: What Golang Is and Is Not
#66Earlier quoted context omitted.
Honestly parametric polymorphism is a big slippery slope feature. There's always Just One More Thing -- higher rank/order/kinded types, where clauses, dependent types, specialization... or else you force people to use dynamic checks/allocations/casts that reduce your type-safety and bog the code down relative to the "optimal" design. Don't get me wrong, I love me some parametric polymorphism, but it's by no means a s…
> higher rank A language designer can provide let polymorphism, refuse to add more, and call it a day. > (higher) order/kinded types, This is orthogonal to parametric polymorphism. Higher-kinded types are problematic for inference, and the way Haskell has implemented them has unfortunate consequences for modularity. > where clauses, This is just syntactic sugar. (FWIW, what I think Rust needs is better inference, rat…
This is orthogonal to
parametric polymorphism
Higher-kinded types are
problematic for inference
In practise, Haskell needs only few kind-annotations to make kind inference possible. This is helped by unannotated kind variables having kind * in Haskell (IIRC).
Re: What Golang Is and Is Not
#67Earlier quoted context omitted.
> higher rank A language designer can provide let polymorphism, refuse to add more, and call it a day. > (higher) order/kinded types, This is orthogonal to parametric polymorphism. Higher-kinded types are problematic for inference, and the way Haskell has implemented them has unfortunate consequences for modularity. > where clauses, This is just syntactic sugar. (FWIW, what I think Rust needs is better inference, rat…
This is orthogonal to parametric polymorphism Higher-rank types are not orthogonal to parametric polymorphism, instead they are a special case. You can see this when you realise that rank-k polymorphism is a subsystem of System F (the paradigmatic typing system for parametric polymorphism) for any k. The let-polymorphism of the ML-family is just rank-1. See Chapters 22 and 23 of Pierce's great "Types and Programming…
> Higher-rank types are not orthogonal to parametric polymorphism, instead it's a special case.
Errr, sorry, I only saw “higher-kinded”, not “higher-ranked”. But, of course, you are right.
> That is true, but already type inference for rank-3 polymorphism is undeciable, hence also System F polymorphism.
Let polymorphism covers 95% of what most programmers need. So if a language designer feels particularly risk-averse (a perfectly legitimate position), they can provide just let polymorphism and ML-style type inference, and then call it a day.
Of course, higher-ranked polymorphism is a nice thing to have, and you can require type annotations when you use more (as Haskell does).
> In practise, Haskell needs only few kind-annotations to make kind inference possible.
A more serious problem with higher-kinded types IMO is that they wouldn't interact very well with an ML-style module system, where you can define an abstract type whose internal implementation is a synonym. `newtype` is an ugly hack.
Re: What Golang Is and Is Not
#68> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…
>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?
There are much more robust and advanced programming languages with native code compilers, imperative programming support and decent code performance - e.g. OCaml.
Re: What Golang Is and Is Not
#69> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…
"Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more"
With the caveat that anyone who may be maintaining/using/enhancing your code will also need to be able to "unlock" this. Keeping the language simpler has benefits beyond the initial code development.
Re: What Golang Is and Is Not
#70> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…
>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?
OCaml and Haskell build self-contained binaries, and have done for decades. OCaml has very fast compile times, and an ordinary C-like linking system. You can even directly link C *.o files. Go certainly isn't "innovative" here.