Seven years of Go • Hacker News Board

Re: Seven years of Go

#191

Post by mappu » Thu, Nov 10, 2016, 8:36 PM UTC

aikah wrote: post #168

stcredzero wrote: post #138

Earlier quoted context omitted.

Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. Classic. All languages stink, somewhere. The classic programmer Dunning-Kruger mistake: evaluating one language without self-awareness of all of the (probably unconscious) cost/benefit optimizations that mostly apply to the other language. This is like Smalltalkers and C++ programmers in the 90's arguing ab…

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

>C++ doesn't have reflection

How would you describe RTTI?

Re: Seven years of Go

#192

Post by dilap » Thu, Nov 10, 2016, 8:38 PM UTC

Matthias247 wrote: post #110

72deluxe wrote: post #64

Earlier quoted context omitted.

What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?

IMHO Go is a good choice for lots of system daemons and commandline tools. If networking is involved it shines even more. > 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere? You could apply this criticism to nearly all languags, as there are currently only very few that are used for native GUIs: C and C++, because the operating systems and native toolkits are written in t…

objc is a huge one! most iphone apps. increasingly, swift too.

there's some python stuff. the original bittorrent client. i did a couple apps using PyQt and python -- not an experience i would want to repeat, though.

Re: Seven years of Go

#193

Post by weberc2 » Thu, Nov 10, 2016, 8:40 PM UTC

wyager wrote: post #120

weberc2 wrote: post #98

Earlier quoted context omitted.

Efficient concurrent programming. I'm not aware of any cross-platform C/C++ or Python libraries that give you async I/O + multi-threaded coroutines. Such a library exists for the Java ecosystem (quasar), but IIRC, it's enabled by clever bytecode tricks, so it's not built with vanilla Java. Further, you still have to take care not to use any libraries that are incompatible with this concurrency model (e.g., anything t…

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" 99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.

> 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 opportunity cost in today's no-free-lunch, multicore, I/O-bound world.

> But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang.

I dispute that Haskell or Erlang are better suited for the purpose. And good luck finding Haskell and Erlang developers.

> This isn't a very convincing argument for Go.

I disagree.

Re: Seven years of Go

#194

Post by Someone » Thu, Nov 10, 2016, 8:42 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!

Almost any powerful new feature in any language initially gets overused, but that isn't a reason to ban it.

Class hierarchies, for example, got heavily overused before people discovered that composition most of the time is the better option, exceptions got overused before people learnt to only use them in exceptional cases, and dependency injection and XML (one of the first environments with strong support for it) got overused in Java programs.

Generics are going the same way, if they haven't already (JavaScript modules will get there, too, but that seems at least a generation of programmers away)

Also, the only difference I see between generics (with a bit of 'compile-time reflection') and go generate is that the former may be too magical for some, while the latter requires programmers to do more work (writing special comments to use existing functionality, and writing AST manipulation code to write new ones) and that it generates files only because the compiler wants to see them.

Re: Seven years of Go

#195

Post by mappu » Thu, Nov 10, 2016, 8:42 PM UTC

AsyncAwait wrote: post #103

weberc2 wrote: post #92

Earlier quoted context omitted.

I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between. The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

Generics in java work via type erasure, so is the same as interface{} by the time the code is running.

Re: Seven years of Go

#196

Post by wtetzner » Thu, Nov 10, 2016, 8:47 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!

Overused in what way? Do you have an example of what you mean by that?

I'm having a hard time understanding where using generics would cause problems.

C++ templates, sure, but those are much more powerful than just having parametric polymorphism.

Re: Seven years of Go

#197

Post by weberc2 » Thu, Nov 10, 2016, 8:47 PM UTC

AsyncAwait wrote: post #103

weberc2 wrote: post #92

Earlier quoted context omitted.

I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between. The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

> The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

I don't understand this argument. You need `interface{}` about 1% of the time; somehow it's better to have no type checking than only 99% type checking? Even in the 1% of cases, I've literally never seen a production bug (or even a failed test case) caused by a type error. I'm sure they happen, but I doubt they happen so frequently that adding in a generic type system would be a net gain.

Re: Seven years of Go

#198

Post by wtetzner » Thu, Nov 10, 2016, 8:51 PM UTC

weberc2 wrote: post #193

wyager wrote: post #120

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" 99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.

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

Re: Seven years of Go

#199

Post by ben_jones » Thu, Nov 10, 2016, 8:53 PM UTC

weberc2 wrote: post #90

randomdata wrote: post #54

Earlier quoted context omitted.

In my experience there is one property of Go that minimizes the need for a good ORM, and that is that the problem domain Go excels in does not have great overlap with the problem domain that ORMs excel in. What interfacing with a relational database does come up is of the nature that does not fit well into the ORM model anyway. Of course, you can write software in the same domain where ORMs excel in Go, but I am not…

What domain are you referring to?

Not GP but my view is that Go excels in "split-backends" where you kind of have a front-end server and a back-end server where the front-end is taking in requests and passing them to a queue or interacting with services representing the "backend's backend". In this regard you're usually building for scale and high optimizing your code to be incredibly concise and to the point. An ORM doesn't belong here because you've already decided software quality > developer productivity within such an important capacity-driven system.

Re: Seven years of Go

#200

Post by pcwalton » Thu, Nov 10, 2016, 8:57 PM UTC

weberc2 wrote: post #184

pcwalton wrote: post #176

Earlier quoted context omitted.

> Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety? Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc. > By the by, I like Rust, I just think it's not well-suited for most applications. I'm going t…

> Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's. > I'm going to push back on t…

> Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's.

Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance (although they are incidentally used to implement some speed/safety features, because why not). Inline assembly and FFI are useful for platform interop: again, these are not safety features.

> Granted, but that's not "pushing back" on my point, because important though those libraries may be, they still don't constitute a majority of applications.

I suspect the numbers are like: 95% of applications are best in scripting languages. 4% are best in managed languages (Java, C#, Go, etc.). 1% are best in low-level languages like Rust. If you want me to concede that point, fine. But in terms of importance of projects, which correlates with the number of developers you need on the project, the numbers look very different.