Live data from Hacker News

What Golang Is and Is Not

danmux.com

171–180 of 279 posts

Re: What Golang Is and Is Not

#171
post #78

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide ad…

What we keep missing is that golang is not nearly as widely adopted as the blog traffic level would lead one to believe.

As usual, this depends on the industry. I'm in the cloud infrastructure business (OpenStack, Docker, Kubernetes etc.) and Go is literally everywhere.

Re: What Golang Is and Is Not

#172
post #45

The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language. [*] https://www.infoq.com/presentations/Go-Google

Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish. In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill you…

> In distributed systems, go is fragile and dangerous -- because it will panic.

Do you know when it will panic? Do you know you can recover from panic if you for example want to communicate with other systems that this node is going offline?

> it has the potential for deadlocks

I could write that for most of languages that have mutexes. This is design problem, not language problem.

> When that happens you have no idea why things are broken-- nothings happening.

It's only true if you do not know how to use debugger and don't know how language features you use works.

Re: What Golang Is and Is Not

#173
post #127

Earlier quoted context omitted.

> That's not true for Java. Its generational garbage collector performs bump allocation in the nursery, yielding tightly packed objects with excellent cache behavior. Allocation in HotSpot is like 3-5 instructions (really!) When I see this link I get different impression. http://mechanical-sympathy.blogspot.com/2012/10/compact-off-... It is only heavy use of sun.misc.Unsafe and unidiomatic coding style that give Java…

That post's numbers are entirely based a giant multi-gigabyte long-lived array: the classic worst case for a generational GC. That is not representative of most memory allocations. The generational hypothesis, which has been empirically verified in real world code again and again, is that most allocations are short-lived and small.

There were 3 points mentioned in post with only 1 about GC. Performance and memory efficiency were major points not delivered by standard idiomatic Java code.

Considering the popularity of memory compact Java collections like Fastutils etc I feel that memory bloat of standard Java is very common issue plaguing Java applications.

Re: What Golang Is and Is Not

#174

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

> Go is a language that pushes remembering corner cases and failure conditions onto the programmer

Can you elaborate on this? I write go for 3+ years and I have no idea what corner cases and failure conditions do you mean.

Re: What Golang Is and Is Not

#175

Earlier quoted context omitted.

It was just the first example that came to mind to illustrate the general pattern. We could also make this particular example shorter by using your naming conventions and writing it in a more functional manner instead of mutating the list: function unique(list) { return list.reduce((r, i) => r.includes(i) ? r : r.concat(i), []); } Clearer? I dunno; probably depends on the reader's background and preferences.

I still don't see what you are gaining here. Outside of code golf, the goal should not be to try and write code as short as possible, regardless of the language you are using. But this just seems to validate Pike's assertion that a for loop is more suitable to the problem. Perhaps an example of where map/reduce is a significant improvement to the expressiveness would be appropriate for the discussion?

I wrote an aimbot for a FPS game.

The basic idea:

Take all the players, and all the buildings.

Filter out those that aren't enemies.

Filter out those that are currently invincible.

Transform that into a list of actual points in worldspace- the hitboxes for players, the AABB centers for buildings. (Not all player models have the same hitbox count.) Unless we are holding a weapon that does splash damage- then go for the feet on players (their origin). And if we hold a projectile weapon, do prediction based on the player's velocity.

Now transform each point into a 2-tuple (position, score), based on some heuristics implemented in another function.

Do a raycast to each point. Filter out those that can't be hit.

Take the point with the highest score, if there is one, and set our viewangles to aim at it. Otherwise leave them alone.

The actual implementation of this looked something like this:

  let target = get_players().chain(get_buildings)
               .filter(|e| are_enemies(me, e))
               .filter(is_vulnerable)
               .flat_map(entity_to_scored_aimpoints)
               .filter(|(score, point)| trace(me_eyes_predicted, point).fraction > 0.999)
               .max_by(|(score, point)| score);
  if let Some(target) = target {
     aimray = target - me_eyes_predicted;
     viewangles = vector_to_angles(aimray);
  }
(Note that max_by is just a special case of reduce/fold; in my experience, you rarely want to use reduce directly; there's probably a more ergonomic wrapper. Sometimes you do, though.)

To me, that's pretty readable (stuff specific to the game aside, like the trace.fraction ugliness- fraction is "how far" the trace got before hitting something, 1.0 meaning there's nothing in the way. the comparison is to handle some floating-point inaccuracy there), and handles some really annoying cases properly.

Re: What Golang Is and Is Not

#176
post #134
post #124

Earlier quoted context omitted.

Go 1.0 is released in March 2012 so it is not even half decade old.

By that logic, Elixir is not even two years old! Edit: karma_vaccum123 has greatly edited the gp comment but for the record, Google has been using golang since 2007.

Find me one reference for Go in "use" at Google in 2007. The wikipedia page does not make this claim, it is only stated that this is when Go itself was being created.

Re: What Golang Is and Is Not

#177

I'm not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go. (Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)

Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it. Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain f…

As someone who was there, let me say that the decision to use Java was definitely not made before the Google acquisition. The codebase that came with the acquisition was C++/JavaScript and was completely rewritten.

Re: What Golang Is and Is Not

#178

I'm not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go. (Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)

Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it. Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain f…

[deleted]

Re: What Golang Is and Is Not

#179

Earlier quoted context omitted.

His formulation of reduce() is strikingly clumsy, both in signature and implementation. I daresay I wouldn't have much use for such a function either! Most languages which provide a reduce() permit programmers to provide an initial "carry-in" value. This is a neater and more useful way to handle the cases of a zero- or one-element list. Moreover, it lets you do more interesting things with the reduction. Consider the…

To be fair, even with a well designed interface, it is difficult to see the advantage of your example over using a simple for loop: func unique(list []int) (r []int) { for i := range list { if !includes(r, i) { r = append(r, i) } } return }

well ES6 have Set, const set = new Set(list);

Re: What Golang Is and Is Not

#180
> To provide any solution in Go that needs a dynamic data structure you can choose between hand rolled linked structures or a Slice or Map (or compose with them). As they are quite different the choice is normally obvious. Contrast this to the choice between map, set, hashset, bag etc etc, or rolling your own in a language that makes this a lot harder.

I can't help but think the whole article is filled with bursts of dishonesty.

A language like C++, which let you use the proper data-structure in about two lines of code, is a lot easier when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest.

If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.

Post reply on HN