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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

231–240 of 670 posts

Re: Toward Go 2

#231

Post by int_19h »

pjmlp wrote: post #186
tomovo wrote: post #137

Earlier quoted context omitted.

So C++ generates separate code for each template type and C# and Java do a typecheck at compile time and reuse the same codepath for all types at runtime?

.NET does a mixture of C++ and Java, meaning generic instatiations for value types get their own version of the code, instatiations for reference types get a shared version.

It's worth noting that in case of C#, it's really an implementation detail. It could just as well share all instantiations by boxing and adding a bunch of runtime checks - the language semantics wouldn't change because of it.

In C++, on the other hand, separate compilation of template for each instantiation is effectively part of language semantics, because it has numerous observable effects.

Re: Toward Go 2

#232

Post by astrange »

pebers wrote: post #194
andrewprock wrote: post #145

Earlier quoted context omitted.

I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.

To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.

Any code that declares variables in the middle of a function, // comments, or varargs macros is using C99.

Re: Toward Go 2

#233

Post by elliotmr »

I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless.

It also really makes me wonder if I am living in some sort of alternate reality. I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is. I have run into some problems where being able to define custom generic containers would be nice, but I don't feel like that has seriously hindered my ability to deliver safe, functional, and maintainable software.

What I appreciate most about Go is that I am sure that I can look at 99% of the Go code written in the world and I can understand it immediately. When maintaining large code bases with many developers of differing skill levels, this advantage can't be understated. That is the reason there are so many successful new programs popping up in Go with large open-source communities. It is because Go is accessible and friendly to people of varying skill levels, unlike most of the opinions expressed in this thread.

Re: Toward Go 2

#234

Post by dmit »

johansch wrote: post #142
fixermark wrote: post #132

Earlier quoted context omitted.

I'd be even more excited if the compiler were willing to execute complete heresy on my behalf and (with user consent) edit my source code automatically to remove unused imports. ;)

You mean have the compiler modify the source code files destructively? Then I'll have to disagree, that just doesn't make sense.

There was a precedent in Haskell land: https://twitter.com/bos31337/status/116372971509121025

A more modern implementation: https://github.com/munificent/vigil

Re: Toward Go 2

#235

Post by scribu »

fixermark wrote: post #128
bad_user wrote: post #48

Java`s generics have had issues due to use site variance, plus the language isn't expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it's a case of missing the forest from the trees). But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design. My gue…

The point of Go 2.0, IIUC, is that it throws away backwards-compatibility guarantees, so if they want to do something in Go 2.0 that breaks correct go1 code to support generics, that's on the table. So backwards-compatibility nastiness is not guaranteed.

Not quite. The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase.

So, at runtime, Go 1 code needs to be able to work with Go 2 types. That will impose some restrictions, I imagine.

Re: Toward Go 2

#236

Post by daww »

Tyr42 wrote: post #198
didibus wrote: post #177

I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory fo…

Sounds like you want Eager Haskell.

yes please

Re: Toward Go 2

#237

Post by xyzzyz »

pebers wrote: post #194
andrewprock wrote: post #145

Earlier quoted context omitted.

I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.

To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.

Linux is definitely not on ANSI C, and CPython is on C99 starting from 3.6.

Re: Toward Go 2

#238

Post by dvlsg »

seanmcdirmid wrote: post #117
JBReefer wrote: post #90

Earlier quoted context omitted.

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

It is new to C#, which is slowly catching up to Scala and F# in that regards. Mads Torgesen is good friends with Martin Odersky, in fact, when I first met Mads back in 2006 or so, they were talking about adding pattern matching to C#. C# is a much more conservative language, and it makes sense it would take a while to add. There are good reasons to use C#, so when it gets a new feature that other languages have had f…

There's a proposal for it! Stage 0? Stage 1? Don't remember what stage it's in off the top of my head, but it looks promising.

Re: Toward Go 2

#239

Post by civilitty »

notjack wrote: post #185
jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.

Which is quite surprising. With open source projects it's usually the other way around...

Re: Toward Go 2

#240

Post by weberc2 »

callesgg wrote: post #113
weberc2 wrote: post #95

Earlier quoted context omitted.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

In my specific case it was the fact that i could not have one insert function or one update function. I would need one for each and every struct(table). These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler So from the ORM perspective we (as the community) have worked around it.

I guess I don't see how generics would help you reduce the number of insert/update functions. The basic problem of an ORM is to map struct fields to columns; I don't see how generics would help you here. Can you write the generic pseudocode you want to write?
Post reply on HN