Seven years of Go

Post by eloff » Thu, Nov 10, 2016, 9:19 PM UTC

aikah wrote: post #209

eloff wrote: post #205

Earlier quoted context omitted.

Since when is powerful reflection a drawback or a sign of a broken language? In my experience reflection is not used all that often in Go and it's nowhere near as powerful as say .NET or JVM reflection - which means package private stuff stays package private, unlike the JVM where the JIT must assume that any type can change at any time. Go has its quirks, and many design decisions that I find dubious, but so does ev…

> Since when is powerful reflection a drawback or a sign of a broken language? When it is not balanced by an expressive type system, it becomes a cop-out where anything goes,including creating adhoc types at runtime ( reflect.StructOf() , reflect.SliceOf() , ... ), because it's the only way to get a little bit of expressiveness of out that language.

Post by _ph_ » Thu, Nov 10, 2016, 9:20 PM UTC

swift wrote: post #182

aikah wrote: post #168

Earlier quoted context omitted.

> If you're such a poor programmer, No need for personal attacks. > then just find a different language. What a warm an welcoming community the Go community is /s C++ doesn't have reflection, because it doesn't need it. But somehow Go needs it ? Reflection is a cop-out, especially in a language that has a simplistic type system. And don't get me started on struct tags. If you cant see the obvious issue with all these…

Gotta tell ya, criticizing Go for lacking generics, which Go supporters argue are unnecessary, while simultaneously arguing that C++ doesn't have reflection because it "doesn't need it" is ironic in the extreme.

Post by weberc2 » Thu, Nov 10, 2016, 9:22 PM UTC

wtetzner wrote: post #198

weberc2 wrote: post #193

Earlier quoted context omitted.

> Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives" I commented before your edit. The question I responded to was something like "What can you do in Go that you can't do in C++ or Java?" > 99% of projects don't need green threads. Perhaps not need , but many of those projects are paying a large opportunit…

> And good luck finding Haskell and Erlang developers. Unless you need a massive number of developers, or you're located out in the middle of nowhere, it really shouldn't be too difficult.

Post by fauigerzigerk » Thu, Nov 10, 2016, 9:26 PM UTC

pcwalton wrote: post #109

didip wrote: post #66

Earlier quoted context omitted.

Wrapper functions are not the same as full blown ORM. For every heavily used ORM features, there's an opportunity to fall into a trap, e.g N+1, because the surface area of an ORM is wide. In contrast, wrapper functions are low cost, easy to write, and recognizable because you write them yourself.

> In contrast, wrapper functions are low cost, easy to write, and recognizable because you write them yourself. Isn't saying that you should use functions that are "recognizable because you write them yourself" basically saying "you shouldn't use libraries?" This seems like the obvious NIH fallacy.

Post by aikah » Thu, Nov 10, 2016, 9:32 PM UTC

stcredzero wrote: post #157

richard_todd wrote: post #70

Earlier quoted context omitted.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!