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

71–80 of 279 posts

Re: What Golang Is and Is Not

#71

Post by snaky »

skybrian wrote: post #59
codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

Having tried to use Go for analytics, I agree that it's not a good fit for that use case. (It does work well for scripts and simple servers, though.)

Looking at things people write in Go, I can't shake the feeling Go is a new /bin/sh with xinetd built in.

Re: What Golang Is and Is Not

#72

Post by Ericson2314 »

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.

Or, you know, we could actually learn something in accordance with the nice pay most of us get.

Re: What Golang Is and Is Not

#73

Post by mafribe »

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…

   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. But something.

Re: What Golang Is and Is Not

#74

Post by knucklesandwich »

Jtsummers wrote: post #33
knucklesandwich wrote: post #13

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

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 some weird tongue-in-cheekness here, but it definitely 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.

I think this idea that "paucity = good" is so easily abusable that whenever this comes up from gophers I wish they would concede that this is an unhelpful simplification of what they must actually believe. Assembly language has possibly the highest paucity of concepts given it offers no ability to introduce language-level abstractions (other than say conventions about calling, etc.), but Go is nothing like this.

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 problem I have with this when applied to parametric polymorphism, is that Gophers already work with these concepts daily, so it can't be that use of them is complicated.

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 also don't think I've ever experienced ambiguity of choice with the feature. For instance I don't think I've ever been in the situation where I had to trade off implementing a generic definition vs. N specialized definitions. 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.

If there's a place where parametricity truly introduces complexity, I'd love to hear about it from a Gopher instead of a blanket statement about how "programmers don't understand it", "it decreases readability", or "Go is simpler without it".

Re: What Golang Is and Is Not

#75

Post by catnaroek »

mafribe wrote: post #73
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…

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.

Re: What Golang Is and Is Not

#76

Post by snaky »

rwmj wrote: post #70
dominotw wrote: post #18

Earlier quoted context omitted.

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

And if you don't need types, there's LuaJIT with all the dynamic features, best inline C FFI ever done, runtime performance in par with native compiled languages, and tools for producing self-contained binaries if needed - https://luapower.com/bundle

Re: What Golang Is and Is Not

#77

Post by Jtsummers »

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…

Ouch. That quote is incredibly unkind to his colleagues. I remember back when Google practically required at least a masters degree for their new hires. Throwing out Georgia Tech grads with 4.0 GPAs and only a bachelors.

Guess they don't think so highly of their hires anymore.

Re: What Golang Is and Is Not

#78

Post by jksmith »

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success.

Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far?

The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole.

Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards.

This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.

Re: What Golang Is and Is Not

#79

Post by pcwalton »

Gankro wrote: post #17
catnaroek wrote: post #11

Earlier quoted context omitted.

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taki…

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…

> Don't get me wrong, I love me some parametric polymorphism, but it's by no means a simple thing as far as I've seen.

I disagree. You should look at OCaml (and Standard ML, though the eqtypes in SML are a botch): generics are dead simple there. Much simpler than Go interfaces, in fact.

Sure, there's always "one more thing" you could add, but that's always true for anything in any language. Slippery slope is a fallacy for this reason.

> 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

Which is what happens even more if you don't have generics!

Re: What Golang Is and Is Not

#80

Post by pcwalton »

codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

> I wish it would do away with nil/null.

I don't think that's possible to retrofit onto a language. Best you can do is to add non-nullable types. But zero values are so core to Go's semantics that I kind of doubt it's possible to even add those in a sensible way.

Post reply on HN