Hacker News Reader

Comment by pjmlp | Hacker News Reader

I can have a great runtime, with static linking support in many other languages.

The sync.Map in Go 1.9 is yet another example of the price to pay for lacking generics.

What price are you talking about? They're adding a map that offers a bit more leeway when working with it from several goroutines, is all I am seeing without thinking extensively about it.

Abandoning type safety with interface{} for keys and values.

I was doing that with Turbo Pascal 6.0 and Borland C++ 2.x for MS-DOS with Turbo Vision and TObject as interface{} in 1993.

So what's your complaint? That you want a synchronized map? Then write a two line function that wraps your native golang typed mapped with sync.Mutex and be done with it.

If you are sharing a map in this way across many goroutines you are probably "doing it wrong" in go anyways.

That is how I used to code in the old days, still on MS-DOS, we are way past those basic type systems.

I can see your point but you're generalizing a bit. For many people they work, for many others they don't. The old and the new type systems both have their place and use-cases.

The new type system is a superset of the older ones.

You can still write your own specialized error-prone repetitive containers for each and every type by hand.

Yet, once a language has generics, people don't use the old way even though it's still possible to.

Perhaps that's because it has no place when there's a replacement which is less error-prone, less repetitive, more usable, and can be implemented once in a library and used forever.

I don't disagree. The risk is there. It's just that for me and others in this thread it's at an acceptable level.

Outside of that, agreed.

> Then write a two line function that wraps your native golang typed mapped with sync.Mutex and be done with it.

Two lines? I think you underestimate what's going on in sync.Map: https://github.com/golang/go/blob/master/src/sync/map.go

Reply on news.ycombinator.com