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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

261–270 of 318 posts

Re: Seven years of Go

#261

Post by pjmlp »

weberc2 wrote: post #240
pjmlp wrote: post #230

Earlier quoted context omitted.

Just like any other async/await model. Also you don't need explicit yield on task runtimes like HPX.

> Just like any other async/await model. I don't see how Go bears any resemblance to an async/await model. Did I misinterpret your statement? > Also you don't need explicit yield on task runtimes like HPX. I don't dispute that it's hypothetically possible to bolt enough things onto C++ to make it behave like Go, but I seriously doubt it's a viable solution. I would sincerely love to know if anyone has done all of thi…

Async/await model is nothing more than a state machine over coroutine.

Goroutines are coroutines.

On the async/await model there are two approaches.

1 - The compiler takes care of the scheduling of the coroutines among the threads on the task pool, like C# 5.0 introduced.

2 - The compiler maps async/await into intrisics that know magic functions on the handles that represent tasks managed by the thread pool. This is called generalized async/await and is how C++17 will do it, and also how the C# model will evolve on C# 7.0

So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible to have control how the scheduling actually takes place among co-routines.

Granted Go's model is easier to understand and might be enough for many people, but it isn't a solution for all types of concurrency problems.

Re: Seven years of Go

#262

Post by pcwalton »

Thaxll wrote: post #252
pcwalton wrote: post #134

Earlier quoted context omitted.

I'm not interested in debating which language is easier to learn for C++ programmers. I'm pushing back against the (clearly false, IMO) idea that adopting Rust is a mistake .

It's about the learning curve, especially people coming from Python to build websites, I mean seriously you would recommend Rust over Go to someone that build api / websites? It's telling someone that used to Ruby to go the C++ way, terrible idea for Python/ruby.

> I mean seriously you would recommend Rust over Go to someone that build api / websites?

Depends on the Web site. I wouldn't particularly recommend either for most CRUD apps.

Re: Seven years of Go

#263

Post by weberc2 »

pjmlp wrote: post #261
weberc2 wrote: post #240

Earlier quoted context omitted.

> Just like any other async/await model. I don't see how Go bears any resemblance to an async/await model. Did I misinterpret your statement? > Also you don't need explicit yield on task runtimes like HPX. I don't dispute that it's hypothetically possible to bolt enough things onto C++ to make it behave like Go, but I seriously doubt it's a viable solution. I would sincerely love to know if anyone has done all of thi…

Async/await model is nothing more than a state machine over coroutine. Goroutines are coroutines. On the async/await model there are two approaches. 1 - The compiler takes care of the scheduling of the coroutines among the threads on the task pool, like C# 5.0 introduced. 2 - The compiler maps async/await into intrisics that know magic functions on the handles that represent tasks managed by the thread pool. This is…

> Goroutines are coroutines.

Traditionally, "coroutine" has been used to refer to a userspace concurrency unit that is not multiplexed and which requires explicit yielding. Mostly I'm grumpy about broadening a previously precise definition.

> So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible to have control how the scheduling actually takes place among co-routines. Granted Go's model is easier to understand and might be enough for many people, but it isn't a solution for all types of concurrency problems.

Not having to control your own scheduling is the selling point of Go's concurrency model. Besides, Go does offer (at least some) control over scheduling via the runtime library. I've never had to use this in practice, and I can't imagine a scenario that would require nuanced control. I don't think async/await are the worst things, but I still prefer Go's runtime at least for the problems I have to solve.

Re: Seven years of Go

#264

Post by grayrest »

greendragon wrote: post #122
snovv_crash wrote: post #44

Earlier quoted context omitted.

From my time doing server backend python dev, it is only catching any problems at runtime, everything from missing arguments to typos in variable names that accidentally match another variable, turning your int to a string. Having a compiler catch these saves much time and hairpulling. And having unit tests as a final defense, rather than the only defense, does wonders for my peace of mind.

As a Python user and fan I hear this complaint a lot. I understand but I can't really agree since things like typos and type fails pretty much never happen to me, at least in production. My secret? I use the REPL, heavily. (And not even in the grand Lisp fashion, because Python's REPL isn't very advanced, mostly I use it just off to the side and maybe or maybe not running an instance of the full program, or parts of…

> I understand but I can't really agree since things like typos and type fails pretty much never happen to me, at least in production.

The typos / type fail comments are shorthand for the real complaint, which is that a long-maintained large dynamic language codebase requires continuous vigilance. I've worked in dynamic languages for most of my career (Python, JS, Clojure) and typos/type-fails are pretty rare but if you haven't spent a half day tracking down a bug that turned out to be one of these at some point in your career, I'd be quite surprised. The breakdown comes when someone not familiar with the code makes a change without fully considering the consequences and it goes through something that nil-puns so the error isn't detected immediately.

My experience with people who are really against type systems is that they haven't run into a language with a good type system. I'm a fan of the gradually typed JS dialects (Flow more than Typescript) since you get the quick hacking at the beginning combined with compiler-enforced vigilance once you switch over to maintenance mode. Type-inferred languages are also nice, particularly fully type-inferred languages. I think F# [0] is both terse and accessible, for example.

[0] https://fsharpforfunandprofit.com/why-use-fsharp/

Re: Seven years of Go

#265

Post by weberc2 »

wtetzner wrote: post #259
weberc2 wrote: post #215

Earlier quoted context omitted.

I disagree.

Have you tried hiring Erlang or Haskell developers? It's not like they don't exist. In fact, there are likely many developers that would love to take an Erlang or Haskell job, but there aren't that many opportunities.

I don't dispute that they exist, I dispute the economics of finding them compared to finding or training new Go developers. Frankly, no one is going to replace their entire team and start a hiring campaign because Haskell or Erlang (arguably) make concurrency slightly easier than Go.

Re: Seven years of Go

#266

Post by weberc2 »

wtetzner wrote: post #260
weberc2 wrote: post #253

Earlier quoted context omitted.

Probably like this: https://gist.github.com/ParthDesai/5e0f1d4725a644f1e632

Wow. That seems very complicated for an implementation of map(). It seems like this is a perfect example of how generics are a productivity feature.

It's complicated because the reflect library is very general. There's no need to repeat most of this. So in fact, it's a perfect example of how functions are a productivity feature.

Re: Seven years of Go

#267

Post by [deleted] »

wtetzner wrote: post #260
weberc2 wrote: post #253

Earlier quoted context omitted.

Probably like this: https://gist.github.com/ParthDesai/5e0f1d4725a644f1e632

Wow. That seems very complicated for an implementation of map(). It seems like this is a perfect example of how generics are a productivity feature.

[deleted]

Re: Seven years of Go

#268

Post by candiodari »

_ph_ wrote: post #213
swift wrote: post #182

Earlier quoted context omitted.

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.

Very few Go supporters would say that generics are unnecessary, especially not the development team. But they are not required at any price and so far no good solution for implementing them has been found. So they are delayed until that day. While I miss them certainly, I strongly prefer them being absent to a bad and complex/confusing implementation.

But the problems go further. The go type system is littered with exceptions. Why ? Because append, make, maps, channels in for loops, channels in while loops, ... all have their own specific entries in the type system.

Go has generics ... but only for the core team. Go has polymorphism (there are polymorphic functions, all of which BEHAVE differently in the type system), there are return type polymorphic functions (functions that behave differently depending on whether you assign their result to one or two variables).

One look at github will tell you exactly what the go way of handling errors does in practice : ignoring errors. Golang code is like C code: it makes it sooo easy to just ignore errors. Second thing: errors are so hard to localize, as they're not tagged with location or stack trace. So I often find myself looking for string errors, while in Java/C# in 99% of cases I know exactly where shit happened. In Go I know in 20% of cases or so.

Speed. Go manages to be slower than Java, except in startup. For a compiled language, that's an accomplishment.

Besides the reactions to Go seem rather typical: it's simple and very, very limiting. Operations people are beside themselves. Predictable (although the ignoring of errors, channels and difficult to localize errors plus a number of mistakes in the standard library detract from that more than a little bit). Programmers don't like it.

Re: Seven years of Go

#269

Post by candiodari »

the_af wrote: post #135
cdelsolar wrote: post #119

Earlier quoted context omitted.

It's more concise, but certainly not more readable. You lose a few seconds writing it the second way. It's fine.

To me the ternary operator is more readable. It has way less extraneous symbols, it is expression-oriented and lets you focus on what's really happening: that something gets assigned to a based on some condition. It expresses intent better than the if-else . Sure it can be abused and nested beyond human comprehension... just like if-else ! So that's a non-argument.

This is the typical operator vs programmer argument. If you're working with difficult concepts compactness trumps simplicity. Plus Go makes it such an enormous chore to write programs with a lot of features.

If you're the one trying to figure out what went wrong in production, both properties are big plusses. Simplicity means scanning code quickly will yield an answer. And the fact that Go makes writing code a chore means there usually isn't that much code.

And of course the fact that Go is so young, means there aren't that many libraries that behave differently. People actually use the standard library features, unlike in Java/C#/C++/Python/... It's becoming less true for net/http, less true for log (all companies I know have their own version, I wonder if Google has it's own version internally too). Go's still in it's honeymoon stage where the standard libraries can actually be used for real projects because they're so young they could implement modern web features without having legacy cruft, nor have they made wrong choices yet, like supporting a dead-end standard or practice.

Re: Seven years of Go

#270

Post by di4na »

weberc2 wrote: post #265
wtetzner wrote: post #259

Earlier quoted context omitted.

Have you tried hiring Erlang or Haskell developers? It's not like they don't exist. In fact, there are likely many developers that would love to take an Erlang or Haskell job, but there aren't that many opportunities.

I don't dispute that they exist, I dispute the economics of finding them compared to finding or training new Go developers. Frankly, no one is going to replace their entire team and start a hiring campaign because Haskell or Erlang (arguably) make concurrency slightly easier than Go.

You would be surprised by the result. Economically it make sense. And i would argue that production ready Elixir/erlang is easier to teach than production ready Go.
Post reply on HN