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

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

411–420 of 439 posts

Re: Proposal: Go should have generics

#411

Post by sythe2o0 »

atombender wrote: post #400
sythe2o0 wrote: post #302

Earlier quoted context omitted.

nil in Go doesn't work that way. Most types cannot be nil.

But a bunch types you do expect to work can: Slices, maps and channels. var m map[string]bool m["foo"] = 1 // Nil, panic var a []string a[0] = "x" // Nil, panic var c chan int This violates the principle of least surprise. Go has a nicely defined concept of "zero value" (for example, ints are 0 and strings are empty) until you get to these. The most surprising nil wart, however, is this ugly monster: package main imp…

I don't think using nil to represent uninitialized data is a major issue-- if it were possible to catch uninitialized but queried variables at compile-time, that could be an improvement, but we want to give the programmer control to declare and initialize variables separately.

I agree the second case is a little silly.

Re: Proposal: Go should have generics

#412

Post by parenthephobia »

NateDad wrote: post #347
pklausler wrote: post #340

Earlier quoted context omitted.

> But in any other language, we'd still have the same 57 definitions of how to sort a type... That claim turns out to not be the case.

Aside from trivial types, like strings or integers, how does the language know how to sort a list of values, if you don't tell it how to? Translate this into whatever language you like: Machine { Name string OS string RAM int } You have 3 places that want to sort a list of machines, one by name, one by OS, and one by RAM. You're telling me there's a language that can do that without having to write some kind of code…

There are no languages where you can sort machines by either name, OS, or RAM without in some way saying which to sort by.

That's a straw man: nobody is telling you that.

But, you are being told there are multiple languages where you can sort machines by their fields without having to write

    type byName []Machine
    type byOS []Machine
    type byRAM []Machine

    func (a byName) Len () int {
      return len(a)
    }

    func (a byOS) Len () int {
      return len(a)
    }

    func (a byRAM) Len () int {
      return len(a)
    }

    func (a byName) Swap(i, j int) {
      a[i], a[j] = a[j], a[i]
    }

    func (a byOS) Swap(i, j int) {
      a[i], a[j] = a[i], a[i]
    }

    func (a byRAM) Swap(i, j int) {
      a[i], a[j] = a[j], a[i]
    }

    func (a byName) Less(i, j int) bool {
      return a[i].Name
For example, in Julia, you can just do

    sort(machines, by=m->m.Name)
    sort(machines, by=m->m.OS)
    sort(machines, by=m->m.RAM)
The equivalent is possible in any almost modern language. E.g. in C#

    machines.OrderBy(m=>m.Name)
    machines.OrderBy(m=>m.OS)
    machines.OrderBy(m=>m.RAM)
In Haskell

    sortBy (comparing Name) machines
    sortBy (comparing OS) machines
    sortBy (comparing RAM) machines
This is an extensively solved problem in modern programming languages.

As a bonus, the opportunity for making an error each time you want to sort a new type of array in a new way is reduced if you only have to write one line of code each time.

Re: Proposal: Go should have generics

#413

Post by spankalee »

pjmlp wrote: post #388
narrowrail wrote: post #268

Earlier quoted context omitted.

Your theory fails to account for the lack of success with respect to Dart; so, it seems more like something you have an urge to believe (despite a lack of evidence).

Dart has been abandoned by Google the day that Angular team has chosen Typescript instead of believing in Dart, thus sending to the world the message that the company doesn't believe in it. Whereas there are a few production examples of Go at Google.

That's some odd reasoning. The Angular team does not decide which languages are invested in by Google.

Re: Proposal: Go should have generics

#414

Post by Arzh »

tacos wrote: post #398
Arzh wrote: post #373

Earlier quoted context omitted.

Yes of course, but compiling the code is faster than generating the code and then compiling it. Templates are much slower than just compiling code straight.

With the exception of pathological metaprogramming examples -- and even those have largely been fixed -- there's no way you could even measure this, let alone justify such a strong, broad opinion. You're using incomplete information to justify sloppy engineering and promoting it to others.

It's compile times, those are very easily tested and measured.

Re: Proposal: Go should have generics

#415

Post by mikecb »

serge2k wrote: post #359
mikecb wrote: post #312

Earlier quoted context omitted.

The G build system was open sourced: http://bazel.io/

Not the distributed secret sauce though. > Does Bazel require a build cluster? Google's in-house flavor of Bazel does use build clusters, so Bazel does have hooks in the code base to plug in a remote build cache or a remote execution system. The open source Bazel code runs build operations locally. We believe that this is fast enough for most of our users.

Unless you have a very advanced infrastructure sitting around, their version of the distributed pieces is going to be worthless. Same reason tensorflow was initially released without it.

Re: Proposal: Go should have generics

#416

Post by tacos »

Arzh wrote: post #414
tacos wrote: post #398

Earlier quoted context omitted.

With the exception of pathological metaprogramming examples -- and even those have largely been fixed -- there's no way you could even measure this, let alone justify such a strong, broad opinion. You're using incomplete information to justify sloppy engineering and promoting it to others.

It's compile times, those are very easily tested and measured.

Templatizing/de-templatizing enough code to see a difference would be a significant effort on any non-trivial code base. But I'll spare you the trouble: instantiating a template is less work than parsing a duplicated file. Some of the early C++ compilers had problems but it hasn't been an issue in 20+ years. If you look at both the G++ and Clang test suites you'll see they verify performance, memory usage and correctness with complicated templates by doing basically this exercise for you.

Re: Proposal: Go should have generics

#417

Post by vorg »

sievebrain wrote: post #153
eva1984 wrote: post #89

Earlier quoted context omitted.

Java itself is, IMHO, quite straightforward. But setup a java toolchain, building, deploying, and a lot of other configuration if some heavy framework is involved, is non-trivial. Gradle is like a must for modern Java application, and mastering itself takes some efforts. Go, when coming to toolchain, it is pretty much battery-included, best-practice-builtin, sometimes even a little forced. Language wise, Java recentl…

A build.gradle file that lists a few dependencies is like maybe 7 or 8 lines of code, which can almost all be cargo culted. You only need to start consulting the Gradle manual once you start doing things like defining custom build tasks or wanting to use custom plugins. Go's toolchain doesn't even bother with versioning. That's like the opposite of batteries-included, forced-best-practices. But of course it will seem…

> A build.gradle file that lists a few dependencies is like maybe 7 or 8 lines of code, which can almost all be cargo culted

...and that code is written in Apache Groovy. Strange why they'd bundle a Turing-complete scripting language for their build file DSL when it's only 7 or 8 lines long.

Re: Proposal: Go should have generics

#418

Post by vorg »

sievebrain wrote: post #154
omginternets wrote: post #70

Earlier quoted context omitted.

>you get the language simplicity And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.

If popular Java toolchains are the most complex you can imagine, I assume you have never encountered autotools, or really any toolchain for a large C++ project. Toolchains normally mean build systems, debuggers, profilers, editors and other things. Java itself doesn't require any build tool at all, you could do it all with a custom shell script. The next step up after that is an IDE like IntelliJ where you press "new…

> Gradle [...] give you dependency resolution with one-line-one-dependency, versioning, automatic downloads, update checking and other useful features.

Not only automatic downloads, but also unwanted downloads courtesy of Groovy. See https://github.com/jaseg/ffi

> Many IDEs can create a Gradle project for you. Gradle avoids the custom dictionary and uses a much lighter weight syntax.

That "much lighter weight syntax" is actually all of Apache Groovy. It's grammar definition is far, far more complex than XML's.

Re: Proposal: Go should have generics

#419

Post by Arzh »

tacos wrote: post #416
Arzh wrote: post #414

Earlier quoted context omitted.

It's compile times, those are very easily tested and measured.

Templatizing/de-templatizing enough code to see a difference would be a significant effort on any non-trivial code base. But I'll spare you the trouble: instantiating a template is less work than parsing a duplicated file. Some of the early C++ compilers had problems but it hasn't been an issue in 20+ years. If you look at both the G++ and Clang test suites you'll see they verify performance, memory usage and correct…

ok, thank

Re: Proposal: Go should have generics

#420

Post by idobai »

duaneb wrote: post #343
idobai wrote: post #123

Earlier quoted context omitted.

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.

> You see Scala as a complex language because you need to learn something before you use it No, I see Scala as a complex language because—much like C++—each library uses its own curious dialect. There is no community consensus on the balance between the object-oriented and functional. It's a mess, albeit a mess I'd prefer over most other languages. But dealing with implicits, language changes between versions, and "d…

> each library uses its own curious dialect

That's the point of high-level languages - to create effective DSLs...

> There is no community consensus on the balance between the object-oriented and functional.

We mix it - there is neither functional nor oop camp at Scala, only objecto-functional - which makes our life easier with decent type and modular systems.

>But dealing with implicits

What's so hard about implicits? One of the easiest feature in PLT. It means to do things implicitly - implicitly waiting for a parameter, implicitly converting something or implicitly extending types with methods.

> language changes between versions

That's the point of versions - to release changes. And no, there aren't as many breaking changes to destroy your workflow if you didn't use any type-level magic.

> and "default" trait implementations (e.g. `val foo = Set()` is a simple example)

val foo = Set() means foo is an empty Set - why does it bother you? It helps to abstract your code and removes unwanted specializations. If you want to use concrete types nothing gonna stop you from that.

Post reply on HN