Hacker News Reader

Comment by ehsankia | Hacker News Reader

I had a similar question, but rather, what's the difference between Go with Google deciding what goes in, and Python (a year ago) where the BDFL and a couple core devs decide what go in?

Sure you could argue that a company may have different incentives than a BDFL, but in this context, it's not clear that Go would've been more likely to accept the change you're proposing if they weren't being led by Google.

View on HN

I guess the most important distinction is the “B” part (benevolent). Guido is called that because he is known (since before BDFL is a thing) to listen to other people, and adapt when they disagree strongly with his decisions. Google has never demonstrated the same attitude afaict, and in multiple occasions showed exactly the opposite.

Edit: And to answer the question, no, there’s no philosophical differences. And there’s nothing wrong with that. Python never called itself a community’s language (there are instances core devs said in no ambiguous terms that it is Guido’s project). The problem only arises if a project gives an impression that it is owned by the community when it actually isn’t.

Given that the go core team has committed to adding generics I don't think it's fair to say they don't listen to critique from the community. Is there a more contentious issue in go?!

Not really, that is the hand waving when the issue ever pops up.

Rob Pike already stated publicly that he is against the proposed idea for Go 2.0.

"Rob Pike - Go 2 Draft Specifications" - https://www.youtube.com/watch?v=RIvL2ONhFBI

I wonder if they'd ever consider adding hygienic macros instead of templates/generics. To me, that solves the problem of needing to write the same code for float32+float64 and so on. And it doesn't require so much careful thought about the type system, accidentally creating an awkward metalanguage like happened in C++.

Rust people are very glad that Rust brought high-kinded types to replace the most common uses of hygienic macros. Using macros for everything is a nightmare.

About using them as generics, how do you enforce constraints? Unconstrained generics won't lead you far (or better, will lead you far into JS's Wat territory).

Rust does not have higher kinded types.

IMO, Rust has a very nice macro system, and this is a good thing (although I'm not familiar with any changes they've made in the last year or two). It's a bad thing that sometimes one needs to resort to the macro system because other features in Rust don't play well together, but that's a long topic with no solution in sight.

> About using them as generics, how do you enforce constraints?

I'm really thinking about the case for numerical algorithms where the exact same code works for different types (say float32 and float64 in Go). It sucks to copy and paste hundreds of lines of code and it sucks to have a separate code generator write your file for you (essentially an external macro processor). Imagine something like the C preprocessor for Go, but without the well known flaws of the C preprocessor:

    #define IMPLEMENT_FOOBAR(NAME, TYPE) \
        void NAME(TYPE* ptr, long len) { \
           hundred lines of implementation here \
        }

    IMPLEMENT_FOOBAR(foobar32, float32)
    IMPLEMENT_FOOBAR(foobar64, float64)

That parametric polymorphic enough for a lot of use cases, and this could work with data structures too.

As for constraints, you can pass function names as arguments too. For instance:

    IMPLEMENT_SORT(sort_baz, baz, bazcompare)

Other proposed features in go, such as the "check" statement for error handling, are probably implementable as a nice macro if you had a good macro language. This means the core language wouldn't have to grow, and features like "check" could be imported from a library. Including features like this in a library means the core language isn't bound by backwards compatibility when a better idea comes along. Old code used the old library, new code uses the new one, and the language stays clean and compatible with both.

This is how Borland C++ provided support for generics before they got into the ongoing ANSI/ISO standardisation process.

For their first implementation of BIDS, initially provided with Borland C++ 2.0 for MS-DOS.

Finding out the release date is left as exercise for the reader.

I see you're reinventing C++

I guess you missed the part above where I mentioned C++ templates as a cautionary tale about accidentally creating an awkward metalanguage. Besides, Go and Rust are both clearly responses to C++, so it makes sense they would try to provide (reinvent) similar capabilities while avoiding the flaws.

> Rob Pike already stated publicly that he is against the proposed idea for Go 2.0.

Rob Pike is not a member of the Go team anymore, and he has not been for several years.

That's sad. Was it because of disagreements?

> That's sad. Was it because of disagreements?

No, he moved to work full-time on Upspin: https://github.com/upspin/upspin

Wow. That makes me happy. The last thing we need in Golang are generics.

Wasn't Linus the original BDFL?

I think the B stood for something else in his case...

Seems to have been Guido.

https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

> The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language.

There are some who would argue it's a "soft B" - his recent conf outburst isn't the only example of him failing to listen and adapt.

Guido always took the role of gatekeeper and arbiter (I'll consult with the community and decide what submissions go in) rather than a true dictator (I'll decide what goes in... submissions? What submissions?).

Reply on news.ycombinator.com