Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Golang Is and Is Not

danmux.com

Post reply on HN
Print view View original

91–100 of 279 posts

Re: What Golang Is and Is Not

#91

Post by tome »

catnaroek wrote: post #67
mafribe wrote: post #66

Earlier quoted context omitted.

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 more serious problem with higher-kinded types IMO is that they wouldn't interact very well with an ML-style module system

That's interesting. Why is that?

Re: What Golang Is and Is Not

#92

Post by unsignedqword »

herval wrote: post #63
unsignedqword wrote: post #50

I'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)

Handling it as tuples is just as fine, but it's important that a language intending to do so be devoid of verbosity and cruft. For example, D supports tuples, but I would not want to attempt Go-style error handling in it: https://rosettacode.org/wiki/Return_multiple_values#D

You make a good point, too, that multiple-return being the only way to do errors is more ideal than the language saying "oh, we support that, but we also have exceptions, too!" At least in a language with Go's philosophy, you can expect other people's libraries and your own code to play by the same rules.

Re: What Golang Is and Is Not

#93

Post by snaky »

berkay wrote: post #69
bluejekyll wrote: post #6

> “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.

> lambdas, it can be a complicated concept to learn

I'm curious, when was that being said? (Perl 5 was released in 1994, JavaScript 1.2 in 1997)

Re: What Golang Is and Is Not

#94

Post by catnaroek »

tome wrote: post #91
catnaroek wrote: post #67

Earlier quoted context omitted.

> 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 more serious problem with higher-kinded types IMO is that they wouldn't interact very well with an ML-style module system That's interesting. Why is that?

Because, in ML, a type-level function that one module views as an abstract type constructor might be viewed by another module as a type synonym. Haskell's type language allows type constructors to appear partially applied, but requires type synonyms to appear fully applied, so it can't deal with this discrepancy.

Re: What Golang Is and Is Not

#95

Post by stcredzero »

knucklesandwich wrote: post #74
Jtsummers wrote: post #33

Earlier quoted context omitted.

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…

FWIW I'm not trying to strawman the argument behind not having features like this. Rob Pike said this in a talk about Go: "The key point here is our programmers are Googlers [...] They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." I'll concede there's the possibility for…

seems to be the canonical view among gophers that Go's paucity of features is about accessibility for programmers that don't understand them or find them cumbersome to work with

Please keep in mind that there are differences at scale. What is "easy to work with" for 1 programmer over a month might not be so for 20 programmers over years.

The argument can't be that paucity is good as a general condition, its that there are forms of abstraction and programming language features that Gophers find unhelpful or difficult to understand

The argument is that simpler is better at scale. Airplanes can move freely in 3 dimensions, but airliners are constrained to fly in particular ways around busy airports and cross country.

I also have a hard time believing that the ability to define parametric types and functions costs you anything. It's almost always self-evident when to use parametric types or functions, things that are "wrappers" or "collections" probably account for 80% of their use.

I could see an argument for parametric collections and parametric sorting in Go. Not, however, for wrappers.

The frustration of using Go is actually that I now have to consider the later as a possibility or trade off type safety by using unsafe casting.

In your experience, what kind of "cost" has there been in unsafe casting to use collections? Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially. Does your frustration come from having to abandon the "assured safety" the type system would give you, or does it come from an experience of the costs?

Re: What Golang Is and Is Not

#96

Post by snaky »

catnaroek wrote: post #75
mafribe wrote: post #73

Earlier quoted context omitted.

provide just let polymorphism and ML-style type inference I mostly agree with this, and this should be the default starting point for any new programming language. If B. Eich had built Javascript on this basis, the world would have been a better place. My main caveat would be that even a basic language needs a mechanism to glue related code together, objects, modules, structs with row-typing, existentials, not sure.…

> My main caveat would be that even a basic language needs a mechanism to glue related code together, objects, modules, structs with row-typing, existentials, not sure. But something. While not perfect, I think ML's solution is pretty reasonable: a separate module language, whose complexity doesn't infect the core language.

There's 1ML where those languages are are unified into one language.

http://www.mpi-sws.org/~rossberg/1ml/

Re: What Golang Is and Is Not

#97

Post by codygman »

snaky wrote: post #62
codygman wrote: post #31

Earlier quoted context omitted.

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.

Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).

Re: What Golang Is and Is Not

#98

Post by catnaroek »

snaky wrote: post #96
catnaroek wrote: post #75

Earlier quoted context omitted.

> My main caveat would be that even a basic language needs a mechanism to glue related code together, objects, modules, structs with row-typing, existentials, not sure. But something. While not perfect, I think ML's solution is pretty reasonable: a separate module language, whose complexity doesn't infect the core language.

There's 1ML where those languages are are unified into one language. http://www.mpi-sws.org/~rossberg/1ml/

I'm aware of it. But my previous suggestions were in part shaped by the stated goals of Go's designers: to keep the language simple and easy to learn for non-language geeks. 1ML is really cool, but its type system can be intimidating: small vs. large types, incomplete inference, type-checking as elaboration into System F-omega, etc. OTOH, plain Damas-Milner is dead simple.

Re: What Golang Is and Is Not

#99

Post by spraak »

bluejekyll wrote: post #6

> “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…

What is the better language that you found?

Re: What Golang Is and Is Not

#100

Post by bluejekyll »

spraak wrote: post #99
bluejekyll wrote: post #6

> “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…

What is the better language that you found?

(Copied from below): Rust, but I think there are others that will fit people's needs as well. Rust suits my needs/wants perfectly.
Post reply on HN