Toward Go 2 • Hacker News Board

Re: Toward Go 2

#511

Post by mathw » Fri, Jul 14, 2017, 6:34 AM UTC

rbehrends wrote: post #307

willtim wrote: post #108

Earlier quoted context omitted.

As a far as I can tell, an "optional type system" is just an unsound type system with a marketing name. Any decent static type system would allow one to progressively increase the level of typing, the weakest form being using a Variant type to hold all other types. The advantage here is that any invariants/proofs that are captured in the system are not compromised by unsoundness.

No, there's more to it. There's been some research in recent years on the actual benefits of types and the results are less straightforward than some people think. An important aspect of type annotations, for example, seems to be that they help document the API of a module, regardless of whether they're statically checked. This is especially relevant with respect to maintenance tasks. Conversely, the benefits of stat…

Type annotations are brilliant for documentation, and it does matter if they're checked or not, because otherwise they're just comments, and we all know comments become wrong over time. If the compiler doesn't enforce your type annotations you can't trust them.

The sweet spot for me at the moment is a language which is fundamentally static but has good type inference so that you don't actually have to mention types all the time.

Haskell's pretty good at this, although because it's possible to write many Haskell programs without actually mentioning a single type anywhere it can be a pain to read the results. Rust deliberately constrained type inference so that you have to have type annotations on functions, which makes sure your interfaces don't get too murky when reading the code.

I'll go with the idea in another reply that static typing really starts to show its benefit in long-lived code bases under maintenance.

Certainly a static type checker makes refactoring a lot easier, in my experience.

Re: Toward Go 2

#512

Post by mathw » Fri, Jul 14, 2017, 6:38 AM UTC

adrianratnapala wrote: post #489

jules wrote: post #449

Earlier quoted context omitted.

What are the very real downsides that generics have?

Even if you don't care about binary bloat (and I do care), it can introduce some of the same problems as dynamic typing. If I am debugging some C++, and I find myself looking at templated function, then I can't easily see what types the template parameters are. Also it becomes hard to navigate to method calls etc. C++ is a particularly bad example, because template metaprogramming is essentially typeless. But any for…

Since C++ monomorphises every single template instantiation in a program, your debugger certainly should be able to tell you what the type parameters for that instance were!

Re: Toward Go 2

#513

Post by willtim » Fri, Jul 14, 2017, 6:41 AM UTC

munificent wrote: post #414

ufo wrote: post #394

Earlier quoted context omitted.

The problem munificent was talking about is that for more complex types you cannot write that type checking predicate you want, which would check if a value belongs to the given type and return a variant-free version of the object. For example, if you have a reference to an array of integers in the typed part of the code you need to protect against untyped parts of the code inserting non-integers inside the array. Th…

This is exactly right. It's a subtle, complex problem that isn't apparent until you start really digging into these kinds of type systems. It's really hard to define the right membrane around the untyped code and values as they flow through your program into typed regions while giving you the safety and performance you expect inside the typed code.

I respectfully disagree. The "right membrane" around any untyped value is a Variant type. A static type system would then stop you making any assumptions without unpacking and asserting its type. If we don't want variants and just want to defer type errors until runtime, then this is possible too (GHC Haskell can do this).

Re: Toward Go 2

#514

Post by JelteF » Fri, Jul 14, 2017, 6:41 AM UTC

stubish wrote: post #320

notheguyouthink wrote: post #221

Earlier quoted context omitted.

I'm so undecided on using GOPATH like that. Though, I may just do it. Personally I hate Go's imports, and I think the GOPATH is a terrible, terrible idea. Yet, I quite like the vendor directory, and I expect the new `dep` tool to be the final touch. Now my only problem is that I often forget which projects of mine are in my GOPATH, so I'm afraid to delete them -_-

vendor has big problems too. There are some proposals on how to start fixing them, after the dep tool lands (originally slated for 1.7 or 1.8 but still in Alpha?) To support the uncommon edge case, src/foo/vendor/dep is completely different to src/bar/vendor/dep. Your src/foo code can't pass src/foo/vendor/dep types to src/bar code expecting src/bar/vendor/dep types. Even if the deps are identical checkouts. Code can…

If you look two parents up you see my colleague posted virtualgo (https://github.com/GetStream/vg). That's the tool I built at my company support GOPATH and version pinning (which is forwarded to dep). You can use it to solve the exact issue you're describing by using "vg uninstall packageName".

Re: Toward Go 2

#515

Post by rbehrends » Fri, Jul 14, 2017, 6:42 AM UTC

mathw wrote: post #511

rbehrends wrote: post #307

Earlier quoted context omitted.

No, there's more to it. There's been some research in recent years on the actual benefits of types and the results are less straightforward than some people think. An important aspect of type annotations, for example, seems to be that they help document the API of a module, regardless of whether they're statically checked. This is especially relevant with respect to maintenance tasks. Conversely, the benefits of stat…

Type annotations are brilliant for documentation, and it does matter if they're checked or not, because otherwise they're just comments, and we all know comments become wrong over time. If the compiler doesn't enforce your type annotations you can't trust them. The sweet spot for me at the moment is a language which is fundamentally static but has good type inference so that you don't actually have to mention types a…

> Type annotations are brilliant for documentation, and it does matter if they're checked or not, because otherwise they're just comments, and we all know comments become wrong over time. If the compiler doesn't enforce your type annotations you can't trust them.

Note that I wrote statically checked. You can also check them at runtime (basically as a form of Design by Contract), which is what Dart does at the moment.

Re: Toward Go 2

#516

Post by mathw » Fri, Jul 14, 2017, 6:43 AM UTC

JBReefer wrote: post #90

seanwilson wrote: post #74

Earlier quoted context omitted.

> If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Yeah, I find it strange how languages are trending at a glacially slow pace to having the same features that strongly typed functional programming languages have had for literally decades. It's like we're going to be using actua…

C# is adding pattern matching in the upcoming release, and to your point, people are acting like it's the new hotness.

I think the reason for that enthusiasm is not so much that it's the new hotness (although it is some people's first encounter with the idea), but that it's now available in a mainstream language that their employer will actually let them use (in about five years when they finally bother upgrading Visual Studio).

Re: Toward Go 2

#517

Post by JelteF » Fri, Jul 14, 2017, 6:49 AM UTC

Spiritus wrote: post #296

cdelsolar wrote: post #219

Earlier quoted context omitted.

It shouldn't be. Set the GOPATH once and use any text editor.

Except you have to set it every time you open a shell. You can’t put it into your .bashrc either unless you only ever work on one project. This workflow sucks: $ cd projects/foo $ export GOPATH=$PWD $ cd src/github.com/company/foo $ go build

You should try out https://github.com/GetStream/vg, it handles managing of multiple gopaths in such a way that cding to a directory switches you automatically.

Re: Toward Go 2

#518

Post by cannabis_sam » Fri, Jul 14, 2017, 6:50 AM UTC

skybrian wrote: post #438

wwweston wrote: post #433

Earlier quoted context omitted.

"low resolution" is a perfectly accurate description of "fuck generics", which like any two-word phrase can't entirely capture the attitude of the golang team, but nevertheless does seem to capture something of gestalt of their approach. Finer resolution would be if fusiongyro had characterized the golang team as saying "fuck off developers who want generics," which wouldn't have been as polite as the phrase "I don't…

No. Unless someone finds a quote, the low order bit is that they didn't use the word "fuck" or any other swear word at all. You can't use the word "fuck" to accurately quote someone who didn't use that word.

Take a look at this article/talk https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

He's explicitly rude. Sets up a strawman argument with the developer who can't imagine programming without generics. Mocks the people who want generics. Gasps in faux disbelief that it could be solved by types.

And then, when he goes in for the kill, to show once and for all that generics are pointless garbage:

He attacks type hierarchies and inheritance... completely missing the point by conflating parametric polymorphism and subtype polymorphism.

I think "Fuck generics" does a decent job of summarazing the rudeness, misinformation and ill-thought out arguments that the article contains about generics.

Re: Toward Go 2

#519

Post by lngnmn » Fri, Jul 14, 2017, 6:53 AM UTC

wheaties wrote: post #16

fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!

The classic Wizards lecture on generic '+ is good enough argument.

The numeric tower of lisps is the canonical use case of what generic functions are good for.

Smalltalk, the second greatest language after Lisp, is also good example.

Re: Toward Go 2

#520

Post by runeks » Fri, Jul 14, 2017, 7:05 AM UTC

spyspy wrote: post #426

vec wrote: post #291

Earlier quoted context omitted.

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

> If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

It's not incomprehensible, it's just phrased a different way from what you're used to.

A lot of programming boils down to mutating local or global state, by executing lines of code -- each of which mutating the contents of some variable somewhere -- in order, one at a time. But this is just one style of programming, and is not the only one. When using map, filter, reduce etc. we, instead, construct a path through which data flows, where each line modifies some aspect of the data, as it flows through the path. This is essentially what Functional Reactive Programming is, although you can get the same effect using a pure language and function composition.