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

251–260 of 279 posts

Re: What Golang Is and Is Not

#251

Post by premium-concern »

stcredzero wrote: post #249
catnaroek wrote: post #107

Earlier quoted context omitted.

> Terseness is a good thing? Some people say terseness is bad. Clarity is good. Clarity comes from both including every relevant detail (which pulls away from terseness) and excluding irrelevant details (which pushes towards terseness). Clarity also comes from saying everything that has to be said exactly once and no more than that (which pushes towards terseness). Unfortunately, when you program in Go, you often hav…

The benefits of typeful programming go beyond type safety. They also include: “economy of thought”, “fearless refactoring”, “less time wasted on fixing stupid mistakes”, etc. Funny, but that's exactly what we Smalltalkers had in Smalltalk -- with far less of the "type system" enforced by the compiler and almost all of it in our heads. (That said, back in the day, we had tooling which was more advanced while also bein…

> with far less of the "type system" enforced by the compiler and almost all of it in our heads

That's why reasonable people want to have good type systems: People who think that they can keep the type system in their head are exactly the people whose opinion should be ignored.

Re: What Golang Is and Is Not

#252

Post by catnaroek »

stcredzero wrote: post #247
catnaroek wrote: post #104

Earlier quoted context omitted.

> The argument is that simpler is better at scale . Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood for some 40 years already. > I could see an argument for parametric collections and parametric sorting in Go. C++'s header is proof that there are lots of algorithms that benefit from being expressed generically, not just sorting. > In your experience, what kind…

Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? What use is there for a fancy data structure? In practice, these occasions aren't that common. Many "fancy" data structures tend to exhibit bad cache behaviors if implemented naively. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is…

> What use is there for a fancy data structure?

Improving asymptotic bounds. Providing functionality typically not supported by common data structures. (e.g., I want a key-value container that's a priority queue on keys, but concatenates multiple values associated to the same key)

> Are you an undergraduate?

No.

> Also, the law of large numbers isn't that relevant for most codebases and developer populations

The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average.

Re: What Golang Is and Is Not

#253

Post by catnaroek »

pcwalton wrote: post #79
Gankro wrote: post #17

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

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

> eqtypes in SML are a botch

Standard ML's `eqtypes` aren't a bad idea at all:

(0) They ensure that `op=` can only be used on things that actually have decidable equality.

(1) If SML were to be equipped with dependent types in the future, it would make sense to only allow `eqtypes` as type indices. First-order unification can be used on syntactic values of `eqtypes`, so the basic architecture of a Damas-Milner type checker can be retained, in spite of having dependent types.

OTOH, equality and comparisons in OCaml are completely broken.

Re: What Golang Is and Is Not

#254

Post by stcredzero »

catnaroek wrote: post #250
stcredzero wrote: post #249

Earlier quoted context omitted.

The benefits of typeful programming go beyond type safety. They also include: “economy of thought”, “fearless refactoring”, “less time wasted on fixing stupid mistakes”, etc. Funny, but that's exactly what we Smalltalkers had in Smalltalk -- with far less of the "type system" enforced by the compiler and almost all of it in our heads. (That said, back in the day, we had tooling which was more advanced while also bein…

> Funny, but that's exactly what we Smalltalkers had in Smalltalk Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”. In other words, there's no separation of concerns. > and almost all of it in our heads What you realistically can't produce entirely in your head is a proof that your program is correct, unless the language is explicitly designed to lift part…

Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”.

In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

Re: What Golang Is and Is Not

#255

Post by catnaroek »

stcredzero wrote: post #254
catnaroek wrote: post #250

Earlier quoted context omitted.

> Funny, but that's exactly what we Smalltalkers had in Smalltalk Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”. In other words, there's no separation of concerns. > and almost all of it in our heads What you realistically can't produce entirely in your head is a proof that your program is correct, unless the language is explicitly designed to lift part…

Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”. In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

> In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds.

This doesn't scale to either large programs or programs not entirely written by yourself.

In ML, there's no need to search anything: the only admissible operations on a value are those sanctioned by its type.

> You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

As a library author, you can't search code written by users of your library.

In ML, I can prove things not only about my own code, but also about how others may use it.

Re: What Golang Is and Is Not

#256

Post by [deleted] »

behnamoh wrote: post #234
seabrookmx wrote: post #136

Earlier quoted context omitted.

Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it. Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain f…

> Android predates Go... So? Apple introduced Swift after Obj-C to make developing iOS apps easier. What about GOOG? Couldn't they at least use Dart or Go (both of which they developed) for android app development after Java? BTW, last time I checked, they're still in for a lot to come from Oracle. > Again, Al-*-Go was based off technology from ... So let me get this straight. They bought a technology which was appar…

[deleted]

Re: What Golang Is and Is Not

#257

Post by stcredzero »

catnaroek wrote: post #252
stcredzero wrote: post #247

Earlier quoted context omitted.

Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? What use is there for a fancy data structure? In practice, these occasions aren't that common. Many "fancy" data structures tend to exhibit bad cache behaviors if implemented naively. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is…

> What use is there for a fancy data structure? Improving asymptotic bounds. Providing functionality typically not supported by common data structures. (e.g., I want a key-value container that's a priority queue on keys, but concatenates multiple values associated to the same key) > Are you an undergraduate? No. > Also, the law of large numbers isn't that relevant for most codebases and developer populations The law…

> Improving asymptotic bounds. Providing functionality typically not supported by common data structures.

It's nice to know that you remember stuff from the textbook. However, how often do you need to do something like this for real production code? Depending on what it is you normally do, it's entirely possible that you need to do this every other project. It's also possible that you never have a real need to do these things. (It's also possible that you never have a real need to do these things, but you do them anyways, which is far, far worse.)

> The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average.

True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point.

Contrast that with an endless parade of "hubris coding" in the same timeframe. My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude. If you're going to be clever about applying your clever, you need to apply it in a fashion where it gives your company's business the biggest bang for the buck. Most coders in their 20's are just trying to impress their fellow programmers.

Re: What Golang Is and Is Not

#258

Post by stcredzero »

catnaroek wrote: post #255
stcredzero wrote: post #254

Earlier quoted context omitted.

Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”. In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

> In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. This doesn't scale to either large programs or programs not entirely written by yourself. In ML, there's no need to search anything: the only admissible operations on a value are those sanctioned by its type. > You could also sometimes achieve this with a few cascaded searches through the Refactoring Brows…

This doesn't scale to either large programs or programs not entirely written by yourself.

My industry experience clearly shows that you're just flat wrong -- with multiple large systems written by other people over the span of over a decade.

As a library author, you can't search code written by users of your library.

What kind of nonsense is this? The library author doesn't need to do such a search! The library users in Smalltalk would do such searches. Access to source was the norm. Decompilation in Smalltalk is trivially perfect, excluding local variable names, so closed source was fairly pointless.

Re: What Golang Is and Is Not

#259

Post by catnaroek »

stcredzero wrote: post #258
catnaroek wrote: post #255

Earlier quoted context omitted.

> In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. This doesn't scale to either large programs or programs not entirely written by yourself. In ML, there's no need to search anything: the only admissible operations on a value are those sanctioned by its type. > You could also sometimes achieve this with a few cascaded searches through the Refactoring Brows…

This doesn't scale to either large programs or programs not entirely written by yourself. My industry experience clearly shows that you're just flat wrong -- with multiple large systems written by other people over the span of over a decade. As a library author, you can't search code written by users of your library. What kind of nonsense is this? The library author doesn't need to do such a search! The library users…

> My industry experience clearly shows that you're just flat wrong

Please tell me how a code search performed by library author Foo will ensure that library user Bar won't break invariants Foo intended to enforce.

> What kind of nonsense is this?

In ML, I can prove that users my library can't use my library wrong. Maybe they won't be able to use my library at all - they type checker will reject every attempt. But it guarantees that, if they can use my library, they will use it right, in the sense that every invariant I enforce won't (and can't possibly) be broken by users.

For example, there may be multiple ways to realize the same ordered set as a red-black tree (balanced differently), but I can arrange things so that the difference can't be observed by users of the ordered set abstraction.

> The library users in Smalltalk would do such searches.

Library users shouldn't be in the business of enforcing invariants that are only relevant to the library's author. See? This is what I mean by “Smalltalk can't separate concerns”.

I'm not saying all of this to be mean. It's been known for quite a while that parametricity is the mathematics of abstraction and separation of concerns [0]. If you need to insulate users of your code from your design choices, you absolutely need parametricity. (Or “social conventions”, but those don't work in the long run.)

[0] http://www.cse.chalmers.se/edu/year/2010/course/DAT140_Types...

Re: What Golang Is and Is Not

#260

Post by catnaroek »

stcredzero wrote: post #257
catnaroek wrote: post #252

Earlier quoted context omitted.

> What use is there for a fancy data structure? Improving asymptotic bounds. Providing functionality typically not supported by common data structures. (e.g., I want a key-value container that's a priority queue on keys, but concatenates multiple values associated to the same key) > Are you an undergraduate? No. > Also, the law of large numbers isn't that relevant for most codebases and developer populations The law…

> Improving asymptotic bounds. Providing functionality typically not supported by common data structures. It's nice to know that you remember stuff from the textbook. However, how often do you need to do something like this for real production code? Depending on what it is you normally do, it's entirely possible that you need to do this every other project. It's also possible that you never have a real need to do the…

> It's also possible that you never have a real need to do these things.

What I don't have a real need for is the ability to destroy the internal invariants of other modules. :-p

> True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point.

Who says homogeneous collections are the only use case for parametricity? Parametricity is useful whenever you need to make sure that unrelated parts of your program don't accidentally rely on (or, even worse, alter) each other's implementation details. “Modularity”, as they call it elsewhere. Of course, Smalltalk has none of this.

> My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude.

I don't separate concerns to be “clever”. Au contraire! I separate concerns to deal with my own brain's limited ability to simultaneously process multiple pieces of information. (And I'll be perfectly honest: I also separate concerns because it's beautiful.)

“Hubris” is a term I would reserve for those who write large programs whose constituent parts don't have fixed structure, yet claim they understand what's going on in the code. (Or perhaps they claim “the tests do the understanding”?)

Post reply on HN