Toward Go 2

https://blog.golang.org/toward-go2

by dmit • 9 years ago

746 640 9 years ago

blog.golang.org

fusiongyro2• 9 years ago

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 cases, we could begin to answer a question like this by examining the significant ones.

This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. I wonder if Go's historical antipathy towards this feature has driven away most of the people who would want it, or if there is still enough latent desire for generics that serious Go users will be able to produce the necessary mountain of real-world use cases to get something going here.

TheDong2• 9 years ago

The fact that go1.9 will include a "sync.Map" type which should be generic, but can't be due to the language's limitations should already answer that.

See also all of the "container" portion of the stdlib: https://golang.org/pkg/container/

All of those should be generic, but aren't.

Clearly there's already sufficient demand for generic collections just based on the stdlib and the fact sync.Map was seen as needed.

piinbinary3• 9 years ago

I'm not sure why this is being downvoted. These are perfect examples of where generics would make a genuine improvement.

xienze2• 9 years ago

All of those should be generic, but aren't.

They aren't because the prevailing attitude is "what do you need generics for? Just do a cast!"

The issue is the Go developers are unwilling to consider generics until someone can come up with a problem that absolutely, positively cannot be solved without generics. And of course there isn't one.

jadbox• 9 years ago

Agree- having map, filter, reduce with strong type guarantees will be a huge boon. Imagine being able to map over a collection and the code hints will understand the new output types in the chain. This is something you cannot have when your higher order ops are all typed to Interface {}.

maxekman• 9 years ago

The sync.Map case for generics is a perfect example. Thanks for bringing it up.

jerf• 9 years ago

"All of those should be generic, but aren't."

I think even more damning then "these should be generic" is that there should be more of them. The real problem is the lack of generics inhibits the introduction of more data structures because they are hard to use.

It is true that arrays and maps/hashes take you a long way, but there's a lot of other useful data structures in the world. And despite the fact they may look easy at first, data structure code tends to be notoriously difficult to write both correctly and with high performance.

crawshaw• 9 years ago

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with.

I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

kyrra• 9 years ago

Link to top-level proposal: https://github.com/golang/proposal/blob/master/design/15292-...

If you scroll to the bottom, you can see 4 large proposals written by Ian over the years.

pjmlp20• 9 years ago

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

wwweston3• 9 years ago

While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough.

As other respondents to the GP comment show, it's not at all hard to come up with that ostensibly elusive picture if you're attending to it. So I suppose the obvious takeaway is that they're still not really attending to it. Which is fine, Go clearly has its niche and its fans, and people who don't want a pretty good Blub have other options.

sbov• 9 years ago

Did he compare those shortcomings with the shortcomings of not implementing generics at all? Because that is the tradeoff here. After decades of research, a decade of go, millions of lines of public and private code, a decade of feedback, and dozens of languages with generics, it's obvious that the perfect generic system isn't going to just happen, so it's not perfect generics vs imperfect generics, it's no generics vs imperfect generics.

e12e• 9 years ago

This made me wonder if there's been efforts to fork golang and add generics as a proof of concept? In theory it should be much easier than a few of the crazy things people have done with c over the years?

callesgg2• 9 years ago

Not having generics makes it hard to do proper type safe functions and libraries.

My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.

weberc212• 9 years ago

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...

zerr• 9 years ago

They should look up the usage of empty interfaces [in the wild or in-house].

munificent5• 9 years ago

This is a great point. Other analysis one could do:

1. Look at uses of cast operators in a codebase. How many of those would be eliminated by making the surrounding operation generic?

2. Go through the language spec and see how many features could be moved out of the language and into the core library if generics were supported.

tomovo4• 9 years ago

Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.

tomovo4• 9 years ago

More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.

vram2217• 9 years ago

"2 Hell with generics", or "Go 2 Hell with generics"

/jk 2

HarkMamilton• 9 years ago

I think this is too little, too late. Anyone who saw an advantage to using generic programming is already using something else. They've already invested resources in something besides Go; why spend the effort to switch back for what will, at best, probably be very mediocre support for parametricity compared to whatever they're already using?

cat199• 9 years ago

This presumes that:

a) generic programming is a new thing

b) any of those people you mention aren't using go for some things and other things where this feature is desired

c) that the feature will 'at best' be at level X

d) that level X won't be enough to satisfy some use cases

and a whole host of other things, not least of which the fact that go itself was invented to suit some purpose after other languages existed, and has been successful for many users

matthewowen• 9 years ago

Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.

wheaties• 9 years ago

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!

masklinn19• 9 years ago

perhaps they can read the literature of the past 30yrs

40, nearing on 45:

Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)

pjmlp20• 9 years ago

You forgot CLU in 1975. :)

seanwilson• 9 years ago

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 actual functional programming languages eventually but the only way it'll happen is to very slowly change what everyone is currently using in small steps.

Static types, immutability, type inference and non-null variables are popular design choices right now but they've been in functional programming languages for nearly 50 years. I'm still waiting for inductive types and pattern matching to turn up in a mainstream language and seeing them talked about like they're new concepts.

lngnmn• 9 years ago

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.

solomatov2• 9 years ago

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

Spiritus5• 9 years ago

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want.

It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

nemo1618• 9 years ago

You might be interested in my side project: https://github.com/lukechampine/ply

It's a small superset of Go that allows you to call map/filter/reduce methods on any slice. It's not true generics (you can't define your own generic functions or types) but it covers the most common use case for me: declarative data processing.

Shorel• 9 years ago

What do you use?

treehau56• 9 years ago

Conversely, I would stop using Go in my projects if it introduces generics.

If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations that nobody else in the world understands, and your project fails but hey -- at least you have a dope, terse, generic implementation -- totally rad.

solomatov2• 9 years ago

Collections, for example. Functional reactive programming. Things like I write in Java now: https://github.com/JetBrains/jetpad-mapper

I remember when Java started to have generics in 1.5. It was very hard to go back to 1.4 after having used that. I feel that I just can't program without them any longer.

xienze2• 9 years ago

This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues.

Nah, this is pretty much the same answer they've been giving all along, lots of handwaving about how generics are so cutting edge that no one can figure out how to use them effectively yet ("we just can't wrap our heads around this crazy idea!")

In other words, don't count on them in Go 2.

stormbrew• 9 years ago

If I were in the "go community" I would be pretty annoyed by this quote. I would find it dismissive of the literal years of people pointing at areas of their code that are bloated and less safe due to not having generics.

It doesn't seem to me that there's a shortage of people pointing out real-world use cases at all, and I'm looking from the outside in.

liveoneggs• 9 years ago

the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way.

basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.

saghm2• 9 years ago

I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handling and traditional exceptions.

imsofuture3• 9 years ago

Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.

the_duke2• 9 years ago

I have no idea why you are being downvoted.

In Rust, this was handled the right way. The Result type forces you to at least actively dispose of the error.

In Go, it's just way too easy to leave an error unhandled.

untog• 9 years ago

It strikes me as a pretty odd statement, though. I'll admit that I'm not very familiar with Go, but surely you can look back at the benefits of generics in other languages? Go is hardly so specialised that you can't learn a single lesson from elsewhere.

Touche2• 9 years ago

I agree, I didn't find the statement refreshing at all, I found it insulting. You damn well know the use-cases for generics. If you still don't like it; fine, say that explicitly. Don't pussyfoot around it and play the "we just don't know that much about it yet" lie.

coldtea7• 9 years ago

This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues.

It seems to me to be the same "Generics is some foreign concept we just heard of, and we're not sure how to implement them in Go yet, but we'll consider it if we chance upon some magical optimal way" that has been the official party line of Go since forever...

Even the "we are asking you for proposals" part has been there since a decade or so...

pjmlp20• 9 years ago

I would already be happy if they supported generics like CLU did in 1975, no need for nothing too fancy.

slantedview8• 9 years ago

The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.

43224gg2527• 9 years ago

Then why don't you come up with a legitimate use case?

kernelbandwidth• 9 years ago

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics!

Rust has generics and traits/typeclasses, and the result is my Rust code uses those features extensively and the presence of those features greatly influences the designs. Similarly, when I write Java, I design with inheritance in mind. I would have trouble showing real world use cases for inheritance in my Rust code, because Rust doesn't have inheritance and so the designs don't use inheritance-based patterns.

Essentially, how does one provide real world evidence for the utility of something that's only hypothetical? You can't write working programs in hypothetical Go 2-with-generics, so examples are always going to be hypothetical or drawn from other languages where those tools do exist.

erikpukinskis3• 9 years ago

This suggests that both generics and inheritance are unnecessary.

Pxtl• 9 years ago

It reminds me of the old urban planning line "You can't decide on the necessity of a bridge based on the number of people who swim across the river".

Users who have heavy need for genetics have already moved away from Go.

vec• 9 years ago

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<T>` instead of half a dozen variations on `sql.NullWhatever`)
  * 99% of functions that accept or return `interface{}`

I appreciate that they seem open to the idea for v2, but "the use case isn't clear" is absurdly out of touch with the community. Using `interface{}` to temporarily escape the type system and copy/pasting functions just to adjust the signature a bit were among the first go idioms I learned, and they both exist solely to work around the lack of generics.

zemo2• 9 years ago

I'm not even a Go developer
Using `interface{}` to temporarily escape the type system

tbh if you program Go correctly, you use interface{} pretty rarely.

spyspy3• 9 years ago

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.

piinbinary3• 9 years ago

I would also love Result<Err,MyThing> in as a return type in place of (err, myThing)

hota_mazi4• 9 years ago

That's a charitable way to look at the comment.

My more cynical reaction is that someone who doesn't understand the benefit of generics or can't even come up with examples where generics are superior to their alternative should not be allowed anywhere near a language design discussion.

kccqzy4• 9 years ago

Generics in Go: https://twitter.com/snoyberg/status/882255351382462464

kccqzy4• 9 years ago

It really reminds me of early C macros where people use the ## operator to synthesize monomorphized versions.

zyxzkz• 9 years ago

That's an awesome trick, using angle brackets that aren't angle brackets!

jgrahamc2• 9 years ago

I didn't expect to get namechecked in that.

Shows the value of constantly being transparent and supporting open source projects.

rsc9• 9 years ago

It absolutely does, and thank you. (I thought you might be here so I could thank you in person.)

jgrahamc2• 9 years ago

You're most welcome. We love Go and use it extensively.

Analemma_• 9 years ago

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.

This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must have use cases where the lack of generics is not a problem and the existing language features are good enough. Sampling Go users to try and find compelling use cases for adding generics is not going to yield any useful data almost by definition.

eropple8• 9 years ago

no longer even bother participating in Go-related discussions, because they've believe it will never happen

/raises hand

I like when tools are good, but I've basically written off Go as a tool for generating unsustainable code right now (and a big part of it is the odious options, either type-unsafety or code generation, for things that are trivially handled by parametricity). If things change, I'll be happy to revisit it, but the described thought process just ignores my existence. And that's fine from my perspective, because I don't need Go, but I'd still like it to be better in case I do need to use it.

kardianos• 9 years ago

I think the Go team would still like to understand your production uses that caused you to write off Go. What is your problem domain? How would you accomplish that in Go? How did you actually solve your problem with a different language?

For me, user provided data structures are the only thing that comes to mind (sync.Map for example) in my production use of Go. But even then, my pain (time spent, errors made) due to a lack of generics is low.

You may have written off Go. But if you're willing, I bet the Go team would still like to read your production code use-cases that caused you to do so.

pjmlp20• 9 years ago

I kind of think the same way, but thanks to Docker and K8s success, it means we might have to deal with Go code regardless how we think about it.

xfer• 9 years ago

Yes, using empty interfaces and adding common data structures to the runtime eliminate the primary use-case of generics. Who would have thought..

phillipcarter2• 9 years ago

We have a similar viewpoint w.r.t Higher Kinded Types in F#. Much of the motivation for HKTs comes from people wishing to use them how they've used them in other languages, but we've yet to see something like this in our language suggestions or design repositories:

"Here is a concrete example of a task I must accomplish with <design involving HKTs>, and the lack of HKTs prohibits me from doing this in such a way that I must completely re-think my approach.

(Concrete example explained)

I am of the opinion that lacking HKTs prevents me from having any kind of elegant and extensible design which will hold strong for years as the code around it changes."

Not that HKTs and TypeClasses aren't interesting, but without that kind of motivation, it's quite difficult to justify the incredibly large cost of implementing them well. And that cost isn't just in the code and testing of the compiler. This cost also surfaces in tooling, documentation, and mindshare. It could also have an unknown effect on the ethos of F#, which for better or for worse, does bring with it a bit of a somewhat intangible quality that many people like.

Personally, I think Golang should implement generics. But I'm sympathetic with the views expressed by Russ Cox here. And I don't think it's just sampling bias.

eropple8• 9 years ago

This is apples and hand grenades, though. You're looking for a use case for HKTs. I just want to make a tree without copy-pasting.

int_19h4• 9 years ago

It's the same thing in principle, but it's one of those cases where details matter a lot. Generics have been mainstream - as in, implemented in mainstream programming languages used to write millions of lines of production code - for over a decade now. At this point, someone claiming that they need specific user scenarios to convince them that generics are worthwhile, or that they aren't aware of a "good enough" way to implement them, beggars belief.

amluto• 9 years ago

This is a fair point. OTOH, just punting entirely seems like the wrong reaction.

Rust, for example, has been thinking about HKTs for a while, and they might not fit well in the language. Rust wants to solve the problems that HKTs solve, and it looks like the solution is converging to ATCs (associated type constructors).

It's taking a while, but Rust is newish, and it isn't taking anywhere near as long as Go is taking to get generics.

smdz• 9 years ago

I have used generics for quite long. When I used it I loved it. Then I moved to a different language for a few years, and lost generics. Now I have written large programs in GoLang too - and frankly I do not miss out on generics at all. Now, I also find reading code with generics isn't straightforward either - it requires a slightly complicated mental model.

xyzxyz998• 9 years ago

So what's happening here? The parent made a reasonable comment, without flaming anybody. All his children give evidence for him (except one but they weren't able to downvote) and yet the parent is downvoted. Votes don't matter but I'm curious about drive-by-downvoting. What does that signify? Fanboyism?

rsc9• 9 years ago

I think you're mostly right. Doesn't it make sense then to ask for help correcting that bias?

JepZ3• 9 years ago

I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go.

From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data structures: Slices and Maps. And both feel as if they are pretty hard coded into the language.

Yes, I am sure there are more container formats and it is possible to build your own, but I think it is not easy enough.

masklinn19• 9 years ago

I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go.

That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts.

Yes, I am sure there are more container formats

First, you forgot Channels and arrays (which are distinct from slices) as well as "range" to iterate over them generically, second there are more containers than that in Go's own standard library: https://golang.org/pkg/container/, https://github.com/golang/go/issues/18177

it is possible to build your own, but I think it is not easy enough

What does that mean? It is not easy enough what? To write containers? To have generics?

JepZ3• 9 years ago

So if generics in java don't do anything beyond 'get typechecked, and insert implicit casts.' the empty interface is enough for all use-cases in go?

JepZ3• 9 years ago

What does that mean? It is not easy enough what? To write containers? To have generics?

Actually, I meant it is not easy enough to build container formats (maybe due to the lack of generics).

Btw. I will not continue this conversation as I am tired of getting insulted (inane and insane), getting downvoted for merely asking questions and you editing your post without labeling it. Just saying.

eropple8• 9 years ago

they make 80% of what we would like to have generics for

I regularly use generics in other languages for tasks unrelated to "containers"/data structures. They allow me to write less code and have the compiler check my mistakes.

Containers are frequently where people start with parameterized types, but once you are in the habit of using them actively that's rarely where you stop.

masklinn19• 9 years ago

once you are in the habit of using them actively that's rarely where you stop.

Eh. Many people don't ever go beyond that and it's fine, containers-type structures (to which I include stuff like futures or option types) and functions working on those are by far the most common use case.

drfuchs• 9 years ago

"Go 2 considered harmful" - Edsger Dijkstra, 1968

zeptomu• 9 years ago

Underrated comment. :)

Haha, thanks.

If there's a Go2 there will be a lot of these headlines for blog posts/rants.

It doesn't matter if it is true or not, but that phrase is wonderful.

masterponomo• 9 years ago

Beat you to it:-)

https://news.ycombinator.com/item?id=3085082

alexandernst• 9 years ago

How about fixing all the GOPATH crap?

frik4• 9 years ago

Now we have at least vendor. But this alien-style fixed paths is really annoying - no other language forces such GOPATH crap. Please remove this limitation from Go 2!

artursapek4• 9 years ago

What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.

kzisme2• 9 years ago

I'm also curious as to what issues you have come across with GOPATHS

frik4• 9 years ago

Multiple unrelated Go projects in different repos located in different directories.

No problem at all with very other language, except with Go - not possible!

I want to open cmd.exe (Win) or bash (Linux) and cd to the directory and build. And not configure a GOPATH in the environment variables of the current user or pretend it to the batch script, set it in IntelliJ Go plugin, etc. It so unflexible, so arkward, and there is no reason for this crap at all. So please fix it for Go 2. Thx

tschellenbach3• 9 years ago

We've worked around it like this and it works pretty well: https://github.com/getstream/vg

notheguyouthink6• 9 years ago

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 -_-

petepete• 9 years ago

Thanks for this. For the first time in my six months using Go the 'peek definition' and 'goto definition' options work correctly!

vhost-• 9 years ago

yeah, I don't fully understand this. I've had the least problems with GOPATH than I have with any other language. You literally set GOPATH=${HOME} and it just works.

GoodbyeEarl• 9 years ago

I still find it difficult to install and use Go.

herewego-4• 9 years ago

Huh. It was dead simple for me.

hackerboos• 9 years ago

I think 1.8 addressed the issue.

https://golang.org/doc/go1.8#gopath

closeparen• 9 years ago

"The GOPATH issue" is the requirement that I keep my source code checkouts at any particular path, in any particular structure, to be able to use the toolchain.

Solving the GOPATH issue would be letting me "git clone" a Go project to a directory of my choosing and still use the tools.

munificent5• 9 years ago

    > 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.

I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both.

We proceeded that way for several years. It was annoying, but tolerable because of Dart's optional type system -- you can sneak around the type checker really easily anyway, so in most cases you can just use "dynamic" instead of a generic method and get your code to run. Of course, it won't be type safe, but it will at least mostly do what you want.

When we later moved to a sound static type system, generic methods were a key part of that. Even though end users don't define their own generic methods very often, they use them all the time. Critical common core library methods like Iterable.map() are generic methods and need to be in order to be safely, precisely typed.

This is partially because functional-styled code is fairly idiomatic on Dart. You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I'm not sure if they'll feel the same pressure.

I do think if you add generic types without generic methods, you will run into their lack. Methods are how you abstract over and reuse behavior. If you have generic methods without generic classes, you lose the ability to abstract over operations that happen to use generic classes.

A simple example is a constructor function. If you define a generic class that needs some kind of initialization (discouraged in Go, but it still happens), you really need that constructor to be generic too.

masklinn19• 9 years ago

You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I'm not sure if they'll feel the same pressure.

`range` is generic, and by virtue of that is a builtin which only works with a subset of the also builtin magically generic types.

The reason why Go "does not feel the same pressure" has nothing to do with its imperative style[0] it is because they special-cased a few generic structures as builtin very early on, unlike, say, Java (which only had arrays as a typed datastucture).

[0] Java and C# are could hardly be more imperative, hell Java is only just adding anonymous functions

snuxoll• 9 years ago

Java has "had" anonymous functions for ages with anonymous inner classes, they just sucked as an implementation.

dvt• 9 years ago

I edited a book on Dart a few years ago. It's a shame the language hasn't gotten much traction outside of Google, as I enjoyed learning and using it.

girvo• 9 years ago

I think it'll see more traction with Flutter and the like over the next year

jcstk• 9 years ago

Ditto on generic methods both changing the game for Dart and being necessary. I spend most of my time in Dart, Swift and ObjC, and I've built serious applications in Erlang and Java. All of which I like for different reasons.

My opinion is that Dart's type system is the optimal type system. It allows for statically typed API surface, but at the same time, I can still add some dynamic voodoo under the surface and enable productive meta-programming.

willtim10• 9 years ago

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.

cdnsteve• 9 years ago

"We estimate that there are at least half a million Go developers worldwide, which means there are millions of Go source files and at least a billion of lines of Go code"

ovao2• 9 years ago

Perhaps fewer than a billion lines of Go code if there were generics.

EddieRingle• 9 years ago

    > To minimize disruption, each change will require
    > careful thought, planning, and tooling, which in
    > turn limits the number of changes we can make.
    > Maybe we can do two or three, certainly not more than five.

    > ... I'm focusing today on possible major changes,
    > such as additional support for error handling, or
    > introducing immutable or read-only values, or adding
    > some form of generics, or other important topics
    > not yet suggested. We can do only a few of those
    > major changes. We will have to choose carefully.

This makes very little sense to me. If you _finally_ have the opportunity to break backwards-compatibility, just do it. Especially if, as he mentions earlier, they want to build tools to ease the transition from 1 to 2.

    > Once all the backwards-compatible work is done,
    > say in Go 1.20, then we can make the backwards-
    > incompatible changes in Go 2.0. If there turn out
    > to be no backwards-incompatible changes, maybe we
    > just declare that Go 1.20 is Go 2.0. Either way,
    > at that point we will transition from working on
    > the Go 1.X release sequence to working on the
    > Go 2.X sequence, perhaps with an extended support
    > window for the final Go 1.X release.

If there aren't any backwards-incompatible changes, why call it Go 2? Why confuse anyone?

---

Additionally, I'm of the opinion that more projects should adopt faster release cycles. The Linux kernel has a new release roughly every ~7-8 weeks. GitLab releases monthly. This allows a tight, quick iterate-and-feedback loop.

Set a timetable, and cut a release with whatever is ready at the time. If there are concerns of stability, you could do separate LTS releases. Two releases per year is far too short, I feel. Besides, isn't the whole idea of Go to go fast?

artursapek4• 9 years ago

They're trying to avoid creating the new Python 3

masklinn19• 9 years ago

Adding generics isn't even backwards-incompatible. AFAIK Java 1.5 was just fine with Java 1.4 code, and so was C# 2.0. The latter using reified generics (and not cheating with builtins) lead to the duplication of System.Collections but given builtins aside as of Go 1.9 it has under half a dozen non-generic collections (versus 25 types in System.Collections, though some of them didn't even make sense as generics and don't have a System.Collections.Generic version) that's unlikely to be an issue.

munificent5• 9 years ago

so was C# 2.0.

True, but C# also has nominal types, overloading, and explicit interface implementation. Adding generics without breaking existing code without those features looks very difficult to me.

ainar-g2• 9 years ago

(Copying my reply from Reddit.)

If you finally have the opportunity to break backwards-compatibility, just do it.

I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0.

Additionally, I'm of the opinion that more projects should adopt faster release cycles.

I am of the opposite opinion. In fact, I consider quick releases to be harmful. Releases should be planned and executed very carefully. There are production codebases with millions of lines of Go code. Updating them every month means that no progress will be made at all. The current pace is very pleasant, as most of the codebases I work with can benefit from a leap to newer version every six months.

camus25• 9 years ago

I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0.

The problem with Python 2/3 is that Python 3 didn't add enough new features to make people want to move to 3.

The problem with Angular 2 is that it just didn't know what it wanted to be.

If Go2 doesn't break enough yet still break it will be no different from Python 2/3 fiasco.

Go has serious design issues, the go team ignoring them hindered Go adoption pace at first place.

makecheck• 9 years ago

I think Python was too ingrained to pull a "Python 3"; Go is newer, and this could be more like a "Swift 3".

Break early and then stabilize for a long time; just make sure everybody knows the plan.

bad_user• 9 years ago

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 guess to why that happens is that the extra type safety and expressivity is definitely worth it in a language and without generics that type system ends up staying in your way. I personally can tolerate many things, but not a language without generics.

You might as well use a dynamic language. Not Python of course, but something like Erlang would definitely fit the bill for Google's notion of "systems programming".

The Go designers are right to not want to introduce generics though, because if you don't plan for generics from the get go, you inevitably end up with a broken implementation due to backwards compatibility concerns, just like Java before it.

But just like Java before it, Go will have half-assed generics. It's inevitable.

Personally I'm sad because Google had an opportunity to introduce a better language, given their marketing muscle. New mainstream languages are in fact a rare event. They had an opportunity here to really improve the status quo. And we got Go, yay!

jcadam• 9 years ago

After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library).

I've mostly moved on to Clojure for programming backend services. I still use Go for the occasional small utility program due to its speed and ease of deployment, though.

43224gg2527• 9 years ago

I've programmed scores of libraries in Go and found it pleasant, in fact it's more pleasant writing a library in Go than in any other language I've used.

I've never once even considered the fact that I might need generics because I've never run into an unsolvable problem or an extremely inelegant engineering solution. I see a lot of people claiming that the lack of generics is a big problem but no one is actually showing a concrete case where generics are necessary.

C doesn't have generics but we never have this discussion when we talk about C.

mmargerum7• 9 years ago

Similar background here, but I found Go refreshingly liberating because everything in the language makes sense and there isn't a lot of magic going on. I might write a bit more code but its crystal clear how it works and more importantly I can come back in 6 months and grok the code. In face, this is the first language i've used in 25 years of coding where I can read anyones code and grok it. go fmt might be the best part of go.

fixermark3• 9 years ago

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.

scribu3• 9 years ago

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.

hdhzy2• 9 years ago

Java`s generics have had issues due to use site variance

Use site variance can be really powerful when you're dealing with invariant data structures like Lists. You can then treat them like covariant or contravariant depending on a particular method call at hand.

logn• 9 years ago

My guess as to why people in Java use generics so much and switched to them so quickly is the squiggly yellow lines in their IDEs. A lot of Java code is easier to read/write with explicit and implicit casting and no use of generics. And the type erasure makes for sometimes unintuitive behavior at runtime. Being familiar with Java, I appreciate Go's skepticism toward generics because maybe just maybe they'll figure out a way to add them after the fact in an elegant way.

nickbauman• 9 years ago

Will there be gotos in Go 2? Asking for a friend.

Siecje• 9 years ago

They are in Go 1 and Go 2 will be backward compatible, so yes.

rsc9• 9 years ago

Have you actually used Go 1's goto? There's not a lot it can actually do. It's there for generated code state machines, and that's almost all it's good for. But yes, goto will stay in the absence of a very compelling benefit to take it out, a benefit that would far outweigh the cost of breaking all the programs that use it.

oelmekki• 9 years ago

As a ruby and go dev, I'm a bit sad to see backward-compatibility going. Thinking I could write code with minimum dependencies and that would just work as is years later was really refreshing compared to the high level of maintenance needed in a ruby app.

But well, I trust the core team to make the best choices.

tschellenbach3• 9 years ago

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++

Improvements to package management is probably the highest item on my wishlist for Go 2.

zbobet20122• 9 years ago

That's going to happen before go 2. Go 1.9 / 1.10 time frame.

owaislone2• 9 years ago

Improvements to package management is probably the highest item on my wishlist for Go 2.

The work is in progress and will most likely be available for general purpose use way before Go2.

Check it out: https://github.com/golang/dep

the_duke2• 9 years ago

There is so much boilerplate you have to write that productivity drops considerably, both because you have to re-re-re-re-implement things (or use code generation) and because you need to scan lot's of redundant code before making sense of it.

The alternative is often to just use interface{}, which hurts performance and type safety.

tschellenbach3• 9 years ago

This has so far been a theoretical concern for me only. If you want to write reusable data structures you obviously need generics. But none of the code I've written involves reusable data structures, so I can't say I really miss generics.

mmargerum7• 9 years ago

This is countered by having a much smaller footprint for the language / SDK in your brain. I easily write code twice as fast in Go as I do in Swift.

michaelcampbell• 9 years ago

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels ...

I'm curious as to what metric you use for "developer productivity", and the values of said metric you can cite for the 3 languages you list.

Walkman• 9 years ago

The productivity level is nowhere near to Python's yet. You should try Go for a couple of weeks and see that still soooo much missing from Go compared to Python.

johansch6• 9 years ago

My main wish:

Please don't refuse to compile just because there are unused imports.

Please do warn, and loudly say it's NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?

fixermark3• 9 years ago

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. ;)

johansch6• 9 years ago

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

ahacker15• 9 years ago

I like that Go don't allows unused import and variables.

If you're working with inexperienced programmers (and some experienced but bad programmers), you should be certain that they WILL let that code garbage there if the compiler allow it.

johansch6• 9 years ago

Funnily enough: I've never found that to be a big problem with other languages in practice. Actually, on a scale of problems in other people's code I'd probably put this very far down the list.

Orangeair• 9 years ago

That's the kind of thing that should be detected by a linter and stop code submission though, not necessarily stop it from even compiling. What if you just want to comment something out quickly? I don't program in Go, but it seems like it would be annoying to have to repeatedly add and remove the main dependencies while I was iterating on something.

rexf• 9 years ago

there is the godep tool that addresses the issue https://github.com/tools/godep

godep helps build packages reproducibly by fixing their dependencies

johansch6• 9 years ago

This is hostile behavior towards a new developer trying out golang. Any third-party tools aren't really going to fix that.

nuggien3• 9 years ago

Just use an editor that has goimports hooked up to run on save.

johansch6• 9 years ago

Or pick a language where you don't have to jump through arbitrary hoops.

mook• 9 years ago

Unfortunately, just importing the package can have side effects (due to `init()`), so making the programmer explicitly ignore the import is actually useful.

jasonwatkinspdx2• 9 years ago

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 heavy moralizing tone that you should feel bad for even asking about the issue. It's infuriating that the same people making those comments are now taking credit for the solution, when they had to be dragged into even admitting the issue was legitimate.

camus25• 9 years ago

overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue

The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead of engaging into the bullshit they engaged in for years when dismissing this or that problem as irrelevant.

Pike said "Go design" is done. Except that a language which design "is done" is a dead one.

treehau56• 9 years ago

Pike said "Go design" is done. Except that a language which design "is done" is a dead one.

Guess C is done for.

pmarreck7• 9 years ago

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

rsc9• 9 years ago

The second half of the "Introduction" section of the blog post explains what "done" meant and why.

kevinconaway• 9 years ago

asking for monotonic time

His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted.

We did what we always do when there's a problem without a clear solution: we waited

The original problem described the issue and the potential consequences very well and the problem didn't change between the initial report and when cloudflare hit it. It was only until a Serious Industrial User (to borrow a term from Xavier @ OCaml) got bit in a very public way that they actually began thinking about what a clear solution would look like.

hinkley4• 9 years ago

Well, but that's not waiting, that's stalling.

hota_mazi4• 9 years ago

We did what we always do when there's a problem without a clear solution: we waited

And this is exactly why the Go designers don't understand language design, and how this ignorance shines through every single place in their language.

Language design is about compromises. There is never a perfect solution, only one that satisfies certain parameters while compromising others. You, the designer, are here to make the tough choice and steer the language in a direction that satisfies your users.

Besides, characterizing their position as "We waited" is very disingenuous. First of all, this is more stalling than waiting, and second, waiting implies they at least acknowledge the problems, which the Go team famously never does. Read how various issues are answered and then summarily closed with smug and condescending tones.

Animats2• 9 years ago

Given Google's orientation towards server-side web applications, it makes sense. On the other hand, the real-time OSs such as QNX have had monotonic clocks available for decades, and they use them for all delay and time interval measurements. (In real-time, you use the monotonic clock for almost everything that matters, and the day clock for logging and display only. You don't want the clock used for delays and time intervals to "smear"; it might have physical effects if it's being used to measure RPM or something and seconds got slightly longer.)

Go is great for server-side web applications. The libraries for that are all there and well debugged. Anything else, not so much.

seabee• 9 years ago

Regarding the leap second bug, I suspect this is an example of perfect being the enemy of the good.

It appeared to me that the golang devs believed so strongly in the superiority of leap second smearing that waiting for everyone to adopt it was better than compromising their API or the implementation of time.Time.

notjack2• 9 years ago

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.

civilitty• 9 years ago

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

rsc9• 9 years ago

FWIW I think this is a fair criticism. We've had so much help from the Go community, not just for those two issues but also for essentially all the work we've done since the release in 2009. Go simply wouldn't exist without the community, and we're very grateful for it.

I couldn't fit any kinds of thank yous into the talk, except for the credit to the overall community in the first few minutes, because I had a lot to say and only 25 minutes. It's possible I should have written an extended blog post that was more than just the talk, but I didn't - the blog post is just the talk, as it says.

conorh• 9 years ago

Would you mind providing examples of what you are talking about? My experience has been different - I find that the golang maintainers are thoughtful but also very very (very) busy people. So I find they tend to respond in a terse, and sometimes what might seem like an unfriendly way, but I haven't seen any of what you mention here.

43224gg2527• 9 years ago

Same, and to add: Go 2 has been planned for a while (since the beginning?) and I'm pretty sure the core developers tend to defer major new feature ideas (e.g. generics) to Go 2.

If they implemented everything everyone asked for they'd have another screw-up like C++ or Java.

canes123456• 9 years ago

The discussion is not about identifying problems. The issue is communicating the problem and explaining the impact. The Go team was wrong about monotonic time but the correct response is not to assign blame. Concrete examples and conversations are a better way to communicate a problem. This is what they are trying to communicate now.

rsc9• 9 years ago

And if you _do_ want to assign blame, it's fine to put it on us. I did as much in the talk:

"Just as we at Google did not at first understand the significance of handling leap second time resets correctly, we did not effectively convey to the broader Go community the significance of handling gradual code migration and repair during large-scale changes."

Our fault, both times.

jasonwatkinspdx2• 9 years ago

This hit a nerve, so I'm going to leave it up, but after thinking about it I also don't like how purely negative it is. I can't edit it anymore but I do want to make a follow up to say something things explicitly:

I want to be clear I'm thankful for the effort everyone has put into golang. Making something people care about enough to love or hate is hard. Stewarding a FOSS project can be a very negative thankless experience as well. While I'm being critical above, there are also lots of examples of golang folks, core or otherwise, making really constructive and productive comments and contributions. I don't mean to trivialize that or ignore it.

AnimalMuppet• 9 years ago

There are many comments griping about generics. There are many comments griping about the Go team daring to even ask what problems the lack of generics cause.

But take a look at this article about the design goals of Go: https://talks.golang.org/2012/splash.article Look especially at section 4, "Pain Points". That is what Go is trying to solve. So what the Go team is asking for, I suspect, is concrete ways that the lack of generics hinders Go from solving those problems.

You say those aren't your problems? That's fine. You're free to use Go for your problems, but you aren't their target audience. Feel free to use another language that is more to your liking.

Note well: I'm not on the Go team, and I don't speak for them. This is my impression of what's going on - that there's a disconnect in what they're asking for and what the comments here are supplying.

(And by the way, for those here who say - or imply - that the Go team is ignorant of other languages and techniques, note in section 7 the casual way they say "oh, yeah, this technique has been used since the 1970s, Modula 2 and Ada used it, so don't think we're so brilliant to have come up with this one". These people know their stuff, they know their history, they know more languages than you think they do. They probably know more languages than you do - even pjmlp. Stop assuming they're ignorant of how generics are done in other languages. Seriously. Just stop it.)

thibran• 9 years ago

I would love to see uniform-function-call-syntax.

Turning: func (f Foo) name() string

Into: func name(f Foo) string

Callable like this: f.name() or name(f)

Extending foreign structs from another package should be possible too, just without access to private fields.

Other than that, if-as-expression would be nice to have, too.

likeclockwork• 9 years ago

One of my favorite features of D.

lemoncucumber3• 9 years ago

As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn't catch but could/should. One that comes to mind is how easy it is to accidentally write:

  for foo := range(bar)

Instead of:

  for _, foo := range(bar)

When you just want to iterate over the contents of a slice and don't care about the indices. Failing to unpack both the index and the value should be a compile error.

mappu• 9 years ago

If `bar` is a slice then the short syntax isn't that useful (although it's shorter than the three-clause for loop equivalent).

But if `bar` is a map or a channel, then that short syntax is very handy.

For comparison's sake, you don't see many PHP users complaining about the difference between `foreach($bar as $foo)` and `foreach($bar as $_ => $foo)`.

lemoncucumber3• 9 years ago

I'd also be fine with it if they switched the ordering of the tuple so that only unpacking one thing gave you the element instead of the index. My point is mainly that the behavior you get currently with a slice is not what you want 9 times out of 10.

lemoncucumber3• 9 years ago

Here's a toy version of a real bug that I wasted a bit of time debugging which was due to this behavior: https://play.golang.org/p/6pBUPBTTvj

akavel2• 9 years ago

Would be cool if you could consider doing a writeup about it, and linking it on the mentioned wiki page.

mmargerum7• 9 years ago

I've got caught by this more than once. Again, implicit behavior sucks so I suggest they get rid of the first form.

EngineerBetter• 9 years ago

I suspect the authors of Golang got drunk, and challenged each other to see how many times they could get people to type 'if err != nil' in the next decade.

treehau56• 9 years ago

Actually what really happened was instead of trying to catch em 'all with pokemon try/catching, they decided to treat errors like it was part of the actual code. Errors are values. You can actually code with them. Amazing, right?

Xeoncross2• 9 years ago

Generics have never stopped me from building in Go... But without them I often do my prototyping in python, javascript, or php.

Working with batch processing I'm often changing my maps to lists or hashes multiple times during discovery. Go makes me rewrite all my code each time I change the variable type.

notheguyouthink6• 9 years ago

It's weird, I see these complaints so often and I just.. don't.. get it. I'm not sure what I do differently, but I'm just so used to Go's method of non-generic that I don't run into frustration at all.

The only time I even notice it is if I have to write a method like `AcceptInt(), AcceptString(), AcceptBool()` and etc.

I enjoy generics in Rust, I'm just not sure what I'm doing differently in Go that causes me to not miss them.

Xeoncross2• 9 years ago

It's possible your data (and types) are short lived.

When I'm doing text processing for example, I pass the same strings/dicts/hashes through dozens of functions for cleaning, sorting, organising, benchmarking, comparing, etc..

It's not just in->save->out CRUD work.

didibus• 9 years ago

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 footprint.

But, I don't know of one, and maybe that's because the Go team is right, some tradeoffs need to be made, and they did, and so Go is what it is. You can't add all the other great features you want and eat the Go cake too.

Disclaimer: I'm no language design expert. Just thinking this from the fact that I've yet to hear of such a language.

Tyr42• 9 years ago

Sounds like you want Eager Haskell.

daww• 9 years ago

yes please

piinbinary3• 9 years ago

Idris is basically an eager-evaluated Haskell, with other niceties on top (dependent types if you want them; fixed String type)

nightski• 9 years ago

Nearly every item on your list is available with OCaml.

ziotom78• 9 years ago

Apart from "great concurrency story", because of the well known problems with the GC. This might be a huge shortcoming for a number of people.

cdelsolar4• 9 years ago

Except no one's ever heard of OCaml.

spyspy3• 9 years ago

A large standard library, too?

LukaD• 9 years ago

I really enjoy writing OCaml but I hate all the tooling around it. It lacks a good package management and build system à la Cargo.

abiox3• 9 years ago

it's a bummer that the windows story for ocaml is so sketchy. i'd like to use it for work (various utilities and whatnot) but the ecosystem seems to make a lot of assumptions about the system it runs on. (for me there's still haskell and rust at least.)

spion2• 9 years ago

OCaml might become this once multicore happens.

mhh__• 9 years ago

With the possible exception of the GC, d(lang) fits those parameters. Including optional lazyness, performance etc.

devit• 9 years ago

Rust is probably what you are looking for.

a functional language

Has closures.

Has pattern matching.

Has algebraic data types (however variants can't have generic parameters not present on the data type itself, but you can use trait objects to do that).

Functions that don't take &mut parameters, & parameters with types with interior mutability and don't call functions that do I/O are pure (although they may not terminate and may abort).

optional lazy constructs

"Automatic" lazy costructs are usually unnecessary and thus almost never used, but can be implemented as a library using macros.

Can also just use closures and call them explicitly.

great polymorphism

Has trait/typeclass polymorphism with either monomorphization or dynamic dispatch.

Structures can't be inherited, but composition gives equivalent results and is the proper way to do it.

There have been several proposals for inheriting structures though, so maybe it will be available at some point, despite not being advisable.

statically typed with inference

Yep.

generics

Yup.

Not higher kinded, no constant integer parameters and not variadic yet, but those features should be available in the future.

great concurrency story

Rust is the only popular language supporting safe concurrency without giving up the ability to share memory between threads.

an efficient GC

It turns out that a GC is unnecessary, and that reference counting is enough, which is what Rust provides (although it's still relatively rarely used).

If you insist on a tracing GC, there are/have been several attempts to add it, and maybe there will be a mature one in the future.

In particular, there is a "rust-gc" crate, and Servo has a working integration with the SpiderMonkey GC, which I suppose should be possible for others to use with some work.

compiles quickly

Work in progress (incremental compilation, more parallelization).

self contained binaries

Yes (or optionally using shared libraries).

simple and effective tooling which takes only seconds to setup

rustup can install the compiler and package manager in one line.

If you want an IDE, you'll have to install that too separately. Work in progress on improving IDE functionality and ease of use.

giving you perfomance that equals java and can rival C

Performance is at least theoretically the same as C since the generated assembly code is conceptually the same (other than array bounds checking, which can be opted out from with unsafe code).

low memory footprint

Same as C.

XorNot4• 9 years ago

How do you get self-contained binaries with Rust? There's a lot of talk but I've not found a definitive "produces a static library" build guide.

rbehrends13• 9 years ago

Honestly, no. For starters, I don't want a functional language (at least not a purely functional one). Purely functional programming has some distinct downsides. My preferences are firmly on the multiparadigm side, and I'm perfectly happy with a reasonable imperative language (that still supports higher-order functions and closures).

What I'm not happy with is language designers seemingly ignoring the state of the art even when it comes to picking low-hanging fruit.

mmargerum7• 9 years ago

Sounds like Scala might be what you are looking for if multi paradigm is your thing.

loup-vaillant3• 9 years ago

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. […] If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.

Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously.

Now what's the next step, refusing to implement generics because nobody uses it?

Every major potential change to Go should be motivated by one or more experience reports documenting how people use Go today and why that's not working well enough.

My goodness, it looks like that is the next step. Go users have put up with the absence of generics, so they're not likely to complain too loudly at this point (besides, I hear the empty interface escape hatch, while not very safe, does work). More exacting developers have probably dismissed Go from the outset, so the won't be able to provide those experience reports.

why-el3• 9 years ago

Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously.

I think you misunderstood. Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system.

loup-vaillant3• 9 years ago

Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system.

I don't think many such examples will emerge.

First, you have the empty interface escape hatch. It's cumbersome, but it works. The real reason why the repeated use of this escape hatch (instead of proper generics), is lack of compile time type safety, which is replaced by dynamic checks. This introduces elements of dynamic typing that generics could have avoided. This has a cost, which unfortunately is hard to asses.

Second, Go users tolerate the absence of generics for some reason. Maybe they don't really need it, but then they don't have a compelling use case. Maybe they do need them, but didn't realise the limitations of the language would hurt them down the line, but are they competent enough to articulate why generics would be better? They made quite the blunder when they chose Go, after all.

That said, he also wrote 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.

Of course he doesn't: Go doesn't have generics. Go users found other ways, thus proving they didn't really need generics. And generics users don't use Go…

notjack2• 9 years ago

We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as taking around negative 990 milliseconds, which caused simultaneous panics across their servers, breaking 0.2% of DNS queries at peak.

This is absurd. Waiting to fix a known language design issue until a production outage of a major customer is a failure of process, not an achievement. The fact that the post presents this as a positive aspect of Go's development process is beyond comprehension to me.

TazeTSchnitzel• 9 years ago

They did the same thing with adding a “round” function. As a result, there are myriad implementations of round() in the wild in Go, and almost every single one is broken in several ways.

43224gg2527• 9 years ago

It's not absurd. This methodology may not be best for everyone, but imo it's best for the language its self, and seeing as Go is one of todays fastest growing languages the developers must be doing something right.

zackmorris• 9 years ago

Go doesn't have const structs, maps or other objects:

https://stackoverflow.com/questions/43368604/constant-struct...

https://stackoverflow.com/questions/18342195/how-to-declare-...

This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data:

https://facebook.github.io/immutable-js/

Const-ness in the spirit of languages like Clojure would seem to be a relatively straightforward feature to add, so I don't really understand the philosophy of leaving it out. Hopefully someone here knows and can enlighten us!

secure• 9 years ago

There doesn’t need to be a philosophy behind leaving it out. Go was started by selecting only features which were deemed necessary. I think it’s fair to assume the creators of Go didn’t design it for writing purely-functional code, so that’s why it’s not in (yet?)

zemo2• 9 years ago

it's almost like writing purely-functional code is not the goal of Go.

akavel2• 9 years ago

I believe part of the reason was also some experience with C++, in which you sometimes have to "unconst" some fields of your const classes (the mutable keyword). This is a really ugly and nonintuitive design, so I assume they'd rather take extra care to make sure they don't have to repeat it. Even if it means no const at all.

johncolanduoni2• 9 years ago

I don't think this kind of thing is all that non-intuitive if you reframe const as shared vs. unique references. Rust is a good example of this, although with Go you would want to sidestep all the Cell stuff since it's unnecessary.

elliotmr3• 9 years ago

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.

scribu3• 9 years ago

I think the negative attitude comes more from frustration than from anything else.

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 didn't know what it was called either until I saw them mentioned here, but now that I know about it, I get why it would be useful. Before that, I kind of assumed all languages with generics would also allow you to access the type information at runtime.

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.

I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox

elliotmr3• 9 years ago

I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox

Interesting read, and I admit there is some of that. But my point isn't to say that those features aren't useful or powerful, but rather that with the constraint of working with a large group of programmers of varying skills, simplicity has more value than power (as long as we can deliver software that meets our requirements). It is similar to point 4 in the "Problems with the Blub Paradox" section.

Entalpi• 9 years ago

This made me think about Pony and its capabilities system.. Also of Haskell and all the rmap, lmap, rfold, lfold, rmagic, lmurloc.. :P

hota_mazi4• 9 years ago

FYI, reified generics undermine type safety and correctness in general, which is one of the reasons why so few languages support the concept (another is that erased generics allow for easier interoperability and for the creation of a much wider class of static type systems).

In my experience, most people who think they need reified generics don't really understand them and can actually do fine with much safer concepts expressed on an erased runtime.

neurotrace2• 9 years ago

I don't think anyone has been arguing against it's ease of use nor the ease of readability. Most people seem to be against it's ergonomics and intentional lack of features.

oblio2• 9 years ago

What if those two are related? ;)

owaislone2• 9 years ago

I like Go and it's intentional lack of feature or very slow speed of adding features is my favorite feature. May be I am a pseudo programmer like most people who dislike Go would probably say.

geodel• 9 years ago

It is because some people here who have no stake in Go programing seem extraordinarily angry or maybe just concerned that why the hell Go authors didn't just override Go programmers' and listened only to enlightened PL experts here and at Reddit.

If it were a topic of gender or race instead of programing language I am sure this behavior would be called out as mansplaining/whitesplaining.

I do wish some term like 'PLsplaining' be used for this infuriating behavior of calling Go/PHP or whatever programmers clueless.

camus25• 9 years ago

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)

What are you and your co-workers using aside from Go?

elliotmr3• 9 years ago

Mostly C and C++. Personally I am working in a C++ codebase right now and I struggle with all sorts of finicky cross-compilation and linking problems that just wouldn't exist in Go.

We also do some Python and Javascript for scripts and web work.

runT1ME• 9 years ago

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.

No you really can't. You can look at any given line of code and tell me what it does, where as it might take more time to parse any given line of Haskell, Scala, or OCaml longer.

However, expressivity in a large application pays a dividend tenfold, because the main challenge of reading code is not any given line, it is understanding the application architecture, the frameworks, the data flow and how it all works together.

That is the reason there are so many successful new programs popping up in Go with large open-source communities.

Successful, or popular? Just look at Docker. Certainly popular, but check the bug tracker or talk to anyone with real world experience using it at scale and you'll be hearing a completely different story.

smegel• 9 years ago

To be fair, forcing \t on people was a douchebag move.

herewego-4• 9 years ago

Having used C#, C/C++, Ruby, Perl, PHP, and Javascript, I find golang to be one of the most refreshing approaches to programming among them all. I think many people are finding themselves feeling upset because they are convinced that the simplicity of golang implies only idiots use it which then must mean that the language will be a failure (almost at an a priori level).

jimjimjim• 9 years ago

Here be Opinions:

I hate generics. also, I hate exceptions.

Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory.

If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring.

Better one hour writing "if err" than two hours looking at logs at ohshit.30am.

NiceGuy_Ty• 9 years ago

What don't you like about generics?

baq4• 9 years ago

there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that.

there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.

why-el3• 9 years ago

Curious, how is a map generic?

wtfrmyinitials• 9 years ago

I can sympathize with the dislike of exceptions. I very much prefer Rust's error handling model (return Result<T, Err>)

The fact that Go has had this much success without generics is mind-boggling to me.

Animats2• 9 years ago

Yes, go has generics, or at least parameterized types, used for channels and maps. What it doesn't have are user-defined parameterized types.

mmargerum7• 9 years ago

I think that's the point really. I think the average programmer like using generics, but rarely builds their own code with them. I've used them from time to time to great effect, but the use cases were pretty isolated. Maybe that makes me average? /shrug

abiox3• 9 years ago

in a sense, generics just let you provide parameters to your types, just like you give parameters to functions. it's not all that magical.

vram2217• 9 years ago

Yes, I had read in an article about/by Walter Bright about D, that that was the insight he had, when working on the design of generics or templates for D:

To paramet(e)rize the types (of a class or function or method), just like you parametrize the arguments of a function or method.

Update: searched for and found the article that mentions that:

https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interv...

Excerpt (italics mine):

[ Walter: We nailed it with arrays (Jan Knepper’s idea), the basic template design, compile-time function execution (CTFE), and static if. I have no idea what the thought process is in any repeatable manner. If anything, it’s simply a dogged sense that there’s got to be a better way. It took me years to suddenly realize that a template function is nothing more than a function with two sets of parameters –compile time and run time–and then everything just fell into place.

I was more or less blinded by the complexity of templates such that I had simply missed what they fundamentally were. There was also a bit of the “gee, templates are hard” that predisposes one to believe they actually are hard, and then confirmation bias sets in.

I once attended a Scott Meyers presentation on type lists. He took an hour to explain it, with slide after slide of complexity. I had the thought that if it was an array of ints, his presentation would be 2 minutes long. I realized that an array of types should be equally straightforward. ]

valarauca1• 9 years ago

http://www.paulgraham.com/avg.html

ovao2• 9 years ago

In Go, the magic right now is actually in special-cased types like map. Generics actually have the potential to reduce the amount of magic as it exists currently.

The design can go badly wrong, of course, but it can also go wonderfully right. Generics are a very important feature to consider for the language.

I have no opinion on exceptions with regard to Go specifically. I think they serve a good purpose in other languages but are often misused.

di4na2• 9 years ago

As erlang shows, quite the contrary. If you want your code to stay up and running you should concentrate on the happy path, bulkhead and let it crash.

I advice to read about Human Factors and Complex Systems engineering. You will be surprised.

mmargerum7• 9 years ago

So much this. Been doing this for 25 years and I loathe magic like Exceptions. I consider Go's explicit error handling a plus. Any editor would let you code ife to generate the error scaffold.

I don't hate generics, but I don't require them either. If the Go guys can make them work well and fit into the language i'd be fine with it, but I don't want them to feel pressured into throwing something out there for the language purists. I doubt they feel pressured. They've been around the block and have as good a sense as any group i've ever seen for what to include in the language.

Go is not the language to use if you want to write clever code, but it's great when you write code for businesses that must run 24x7.

fredmorcos• 9 years ago

But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring.

You mean like memory and resource management code? Oh wait.. you use a garbage collected language. lol

nebabyte• 9 years ago

But I always heard never to use Go 2! :P

concatime• 9 years ago

The leap second problem reminds me of this post[0].

[0] https://news.ycombinator.com/item?id=14121780

egonschiele• 9 years ago

Most of the discussion here seems to be around generics, and it sounds like they still don't see the benefit of generics.

I like Go, but the maintainers have a maddeningly stubborn attitude towards generics and package managers and won't ease up even with many voices asking for these features.

beliu• 9 years ago

This was announced at GopherCon today. FYI, if folks are interested in following along other conference proceedings, there is no livestream, but there is an official liveblog: https://sourcegraph.com/gophercon

treehau56• 9 years ago

It's on twitch I believe

dgacmu• 9 years ago

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost.

(1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloated than the integrated map type, just because of all the boxing: https://github.com/efficient/go-cuckoo/blob/master/cuckoo.go

(my research group created libcuckoo.)

Go 1.9 offers a native concurrent map type, four years after we looked at getting libcuckoo on go -- because fundamental containers like this really benefit from being type-safe and fast.

(2) I chose to very tightly restrict the initial set of operations we initially accepted into the TensorFlow Go API because there was no non-gross way that I could see to manipulate Tensor types without adding the syntactic equivalent of the bigint library, where everything was Tensor.This(a, b), and Tensor.That(z, q). https://github.com/tensorflow/tensorflow/pull/1237 and https://github.com/tensorflow/tensorflow/pull/1771

I love go, but the lack of generics simply causes me to look elsewhere for certain large classes of development and research. We need them.

aaronblohowiak• 9 years ago

please do send that to rsc

ramenmeal• 9 years ago

Care to explain?

bascule• 9 years ago

fundamental containers like this really benefit from being type-safe

Note that, at least in its current form, the native concurrent map type uses interface{} for all keys and values, and therefore offers no type safety:

https://github.com/golang/go/blob/master/src/sync/map.go

All of Go's built-in pseudo-generic types (e.g. maps) require special support from the parser. I'm not sure if they plan on doing that for sync.Map as well, but this is clearly an area that could benefit from generics.

rsc9• 9 years ago

Thanks for this. Will followup on email.

kevhito2• 9 years ago

For (2), are you looking for overloading arithmetic operators (+, -, etc.)? Do people normally consider that under the umbrella of "generics"?

For (1), for curiosity sake, I tried benchmarking the cuckoo.go file you posted. I'm curious if these numbers are in line with what you found. The first test I did was a Rand test, Putting 10,000 random string values under random string keys, then Getting the same 10,000 keys, then Getting 5000 more random keys. The first line below uses default code you posted, which uses

    type keytype string
    type valuetype string

The second line specializes the code to just using the string type directly for keys and values. The third line uses interface{} instead for values, which is the code style HN doesn't like.

    BenchmarkRandInsert-8                                100      13474408 ns/op
    BenchmarkStringStringRandInsert-8                    100      13585071 ns/op
    BenchmarkStringVoidStringRandInsert-8                100      14126666 ns/op

That third line shows the cost of casting to/from interface{}. The difference in the code was about as you might expect, with the "void" example needing a cast on each put and a cast on each get.

If I use uint32 for value instead, I get:

    BenchmarkStringIntRandInsert-8                	     200	   9431584 ns/op
    BenchmarkStringVoidIntRandInsert-8            	     100	  10485785 ns/op

The 9.4ms result is using a version of your code hand-specialized for string key and uint32 values. The 10.4ms result uses interface{} for values.

I ran a sequential-insert test as well, with keys and values generated sequentially instead of randomly. The results are much the same, though the cost of casting to/from interface{} seems to get mostly lost in the noise.

    BenchmarkSequentialInsert-8                          100      12185272 ns/op
    BenchmarkStringStringSequentialInsert-8              100      12233946 ns/op
    BenchmarkStringVoidStringSequentialInsert-8          100      12543980 ns/op
    BenchmarkStringIntSequentialInsert-8                 200       8823747 ns/op
    BenchmarkStringVoidIntSequentialInsert-8             200       8709242 ns/op

I also tried some tests using uint32 as the key type. This int key specialized version is 3x faster than any of the string key versions, but it's not really a fair comparison... a small part of the code is specific to string keys (getinthash), so it's not as obvious what the generic equivalent of that function would be. The keys need to be Hashable or some such, not just interface{}. I'm also allocating and formatting random strings in one case, vs just picking random numbers in the other case.

I didn't find the interface{} casting in any of the above code too horribly "gross", just a bit ugly, but that's entirely subjective. Yes, all of the cuckoo versions seemed about 30% slower than the corresponding builtin map type, but my benchmark numbers don't show if that is the price of boxing, of supporting concurrency, or maybe function call overhead, or something else. I'm guessing you did more detailed benchmarks that point to the source of the slowdown.

One last comment: keytype and valuetype really need to be exported, don't they? I wasn't able to use the library without changing them to exported symbols.

lomnakkus7• 9 years ago

For (2), are you looking for overloading arithmetic operators (+, -, etc.)? Do people normally consider that under the umbrella of "generics"?

Overloading is usually not a "generics" concern in most mainstream languages[1]. If you do a "type class"/"Rust-style-traits" (or even multiclasses) thing then it sort of naturally takes a front seat. Incidentally, Haskell fucked this one up horribly in some respects, see the "Num" type class.

Of course, e.g. Java could theoretically add an interface called Addable to complement Comparable which would sort-of allow generic "+", but they've chosen to not opt for that. The fact that the "first parameter" is privileged is also a bit of a detriment to such syntax conveniences. (I can expand on this, but it's bascially because that for "X op Y" and "Y op X" to work, they both need to know of each other. This problem can be solved by type classes, but cannot be solved by overloading, AFAIK.)

[1] If you do have overloading from the outset (like Java, IIRC), then you're constrained because you need to be able to "pick the most specific overload" in a "generic" context.

e3b0c• 9 years ago

Sounds like https://github.com/golang/go/issues/19335

I guess the performance issue has something to do with some missing optimizations. Hopefully it will get better.

Edit: Also https://github.com/golang/go/issues/19361

verroq• 9 years ago

Forget generics. What I missed most are algebraic data structures.

rmrfrmrf2• 9 years ago

Sorry, but if "a major cloud platform suffers a production outage at midnight" is the bar for effecting change in Go, then I want no part of it.

martyvis• 9 years ago

"Play it cool" https://youtu.be/BHIo6qwJarI Go! by Public Service Broadcasting.

(Sorry just discovered this song a few days ago)

issaria• 9 years ago

Regarding the lacking of generics problem, is there a way to get around it, there are always plenty of tools doing that, if the IDE can patch the syntax and support certain kind of prigma to generate the template code, then the problem is almost solved, not sure if it'll cover all cases like Java does though.

insulanian• 9 years ago

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.

Collections?

vbezhenar• 9 years ago

I like Go concept: very simple and minimalistic language, yet usable enough for many projects, even at cost of some repetition. Generics are not a concern for me. But error handling is the thing I don't like at all. I think that exceptions are best construct for error handling: they are not invasive and if you didn't handle error, it won't die silently, you have to be explicit about that. In my programs there's very little error handling, usually some generic handling at layer boundaries (unhandled exception leads to transaction rollback; unhandled exception returns as HTTP 500, etc) and very few cases when I want to handle it differently. And this produces correct and reliable program with very little effort. Now with Go I must handle every error. If I'm lazy, I'm handling it with `if err != nil { return err; }`, but this style doesn't preserve stack trace and it might be hard to understand what's going on. If I want to wrap original error, standard library don't even have this pattern, I have to roll my own wrapper or use 3-rd library for such a core concept.

What I'd like is some kind of automatic error propagation, so any unhandled error will return from function wrapped with some special class with enough information to find out what happened.

bsaul• 9 years ago

about generics : i've never had a deep look at it but i've always wondered if most of the problem couldn't be solved by having base types ( int, string, date, float, ..) implements fundamental interfaces (sortable, hashable, etc). i suppose that if the solution were that simple people would've already thought about it.

in particular, i think it could help with the method dispatch, but probably not with the memory allocation ( although go already uses interfaces pretty extensively).

silverlake• 9 years ago

This is a frustratingly common way to design mainstream PLs: "show me the use case". I've seen it firsthand for a number of big PL projects. People are trapped in their little bubble. My approach is to be wildly polyglot, actively searching for good ideas in other languages. Also, I try to write complex code outside the intended domain space and understand why it's harder than it should be.

For example, in Go it's difficult to implement state machines in a clean way. Another is handling events and timeouts is easier with Reactive programming. Distributed programming is easier with Erlang or Akka. Don't wait for problem reports in the Go community. Look at the problems in other PLs and proactively improve Go.

Miranda12• 9 years ago

I was newly married and my husband and I intended on getting a house but our credit scores were low and I also had a few bank debts. I spoke to a friend about it who happens to be a tech guy and he introduced me to a hacker (blackbutcher). I contacted blackbutcher and he helped my husband and I boost our credit scores and he also helped me clear my bank debts. This hacker is a genius and comes highly recommended by a lot of people. He's affordable and genuine unlike a lot of fakes I saw on the internet. Contact him on his mail blackbutcher.hacker@outlook.com

Toward Go 2

Related Stories