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

What Golang Is and Is Not

danmux.com

Post reply on HN
Print view View original

81–90 of 279 posts

Re: What Golang Is and Is Not

#81

Post by lbn »

dominotw wrote: post #18
bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?

Rust is not an alternative to Go. Go is significantly easier to learn as it's very simple. Crystal and Nim come close but they do not have the backing of a large tech company and their ecosystems are not as mature.

Re: What Golang Is and Is Not

#82

Post by snaky »

Jtsummers wrote: post #77
knucklesandwich wrote: post #74

Earlier quoted context omitted.

FWIW I'm not trying to strawman the argument behind not having features like this. Rob Pike said this in a talk about Go: "The key point here is our programmers are Googlers [...] They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." I'll concede there's the possibility for…

Ouch. That quote is incredibly unkind to his colleagues. I remember back when Google practically required at least a masters degree for their new hires. Throwing out Georgia Tech grads with 4.0 GPAs and only a bachelors. Guess they don't think so highly of their hires anymore.

We are yet to be convinced a degree or GPA have any correlation with an actual abilities related to programming with regard to quality, performance, abstractions, languages, tools or anything.

By the way, http://www.deathandtaxesmag.com/200732/google-admits-its-fam...

Re: What Golang Is and Is Not

#83

Post by pjmlp »

dominotw wrote: post #18
bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?

Almost all static compiled languages have AOT compilation to native code, even Java and .NET ones, although many tend to ignore it.

So all the ML languages, Java, .NET, Pascal dialects, Modula-2, Modula-2, Oberon and its descendants, Ada, Crystal, Nim, D, Rust, Swift, Objective-C, ...

Re: What Golang Is and Is Not

#84

Post by stcredzero »

knucklesandwich wrote: post #13
catnaroek wrote: post #11

Earlier quoted context omitted.

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taki…

The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric t…

What they lack is the ability to let programmers introduce their own parametric types and functions, presumably because we're too dumb to be anything but consumers of this functionality.

Here's what my experience is with certain features in languages: They enable some programmers to do great things, while also enabling a few programmers blinded by hubris to do maddening things. Over the life of a large project, the unfortunate coincidence of different pieces of hubris driven code sometimes causes an outsized amount of frustration.

Analogy: Most people, most of the time, have the good sense to operate cars, drones, and high powered laser pointers without becoming a dangerous nuisance. However, there is a potential for a minority of users of such devices to cause far more than their share of public nuisance. Therefore, there are rules and restrictions about how such things are used by many people at scale.

So yes, as an individual you are probably just fine. But you aggregated with a whole bunch of other programmers is likely to be a different story.

https://en.wikipedia.org/wiki/Tragedy_of_the_commons

Re: What Golang Is and Is Not

#85

Post by bad_user »

As some people like to point out, I'd also like to remind that in 1968 Algol had:

    - user defined record types
    - user defined sum types
    - switch/case statement with support for sum types
    - unified syntax for value and reference types
    - closures with lexical scoping
    - parallelism support
    - multi-pass compilation
Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go developer might thing that "nothing is new under the sun" since the 80's. After all, Go ignores all progress in programming languages for the last 40 years.

I recommend watching "Growing a Language", a legendary presentation by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0

I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.

Re: What Golang Is and Is Not

#86

Post by pcwalton »

xyproto wrote: post #30
soulbadguy wrote: post #7

Earlier quoted context omitted.

Golang is only 'near cpu' when compared to python or ruby. Golang is much closer to java/c# then c/c++

Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the langua…

> The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++)

Go 1.7 performs nowhere near the set of optimizations that GCC and LLVM do. GCC/LLVM have a huge number of algebraic simplifications (InstCombine), aggressive alias analysis, memory dependence analysis, instruction scheduling, an optimized instruction selector, a highly tuned register allocator with stuff like rematerialization, SCCP, etc. etc. It will take years and years for Golang to come close.

> Go (the language) can be made just as fast as C (the language), for many cases.

No, it can't. The M:N scheduling model will always have some overhead relative to 1:1 if you don't need the performance profile of C10K-style servers. The dynamic semantics of "defer" is an unavoidable performance tax over RAII. Unwinding is mandated by the language, inhibiting some optimizations. There is little control over allocation: language constructs allocate in ways that are not immediately obvious. The fact that interfaces result in huge numbers of virtual calls results in a good amount of overhead that (unlike Java) Go can't even eliminate with inline caching, because it's AOT compiled. This is just off the top of my head.

> Go has the advantage of making it much easier to use multiple processors, though.

Not really. Go's parallelism primitives are just as low-level as those of C. The "one size fits all" scheduling algorithm is a poor fit for getting the most performance out of multicore. The lack of generics is a real problem: it prevents you from using optimized concurrent data structures without paying the tax of interface{} or going through code generation hoops.

In any case, the lack of SIMD basically kills Go's applicability in these domains.

Re: What Golang Is and Is Not

#87

Post by pjmlp »

bluejekyll wrote: post #32
namelezz wrote: post #20

Earlier quoted context omitted.

> This is a huge improvement over Java, and something every language should have an option for. I am not sure what improvement you are talking about. Deploying Go apps requires recompiling for the target platform. On JVM, you only need to install the JVM. There are also tools to wrap JVM apps in executable files that will automatically download and install a suitable JVM.

I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I'm a longtime Java engineer, it's a great language, but I do think the compile once thing isn't as big an advantage anymore. With the advent of the LLVM, it's easy to target specific machines. rustup, even makes it possible to build binaries for every target environment you have. And let's be hon…

> I'm a longtime Java engineer, it's a great language, but I do think the compile once thing isn't as big an advantage anymore.

So you surely should be aware of the existing options to compile Java to native code, just like Go.

Re: What Golang Is and Is Not

#88

Post by pcwalton »

dilap wrote: post #48
vvanders wrote: post #36

Earlier quoted context omitted.

Until you have control over stack/heap and data locality you're never going to be able to approach C/C++/Rust speeds. Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.

Go allocates on the heap unless it can prove something doesn't escape, in which case it's on the stack. Not explicit programmer control, but I think you can reasonably make it do what you want. Because it exposes pointers as a first-class concept, you also have good control of how data is laid out in memory (=> locality). It's not like Python or Java where everything is a pointer and gets spread out all over memory.

> Not explicit programmer control, but I think you can reasonably make it do what you want.

Escape analysis, like any such analysis, gets much more difficult in the presence of higher-order control flow. Currently the Go compilers punt on higher order control flow analysis. And Go uses higher-order control flow in spades, due to its heavy reliance on interfaces.

The end result is that lots of stuff is heap allocated.

> Java where everything is a pointer and gets spread out all over memory.

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!)

I think the HotSpot approach makes the most sense: instead of trying to carve out special cases that fall down regularly, focus on making heap allocations fast, as you'll need to make them fast anyway. After that, add things like escape analysis (which HotSpot has as well).

Re: What Golang Is and Is Not

#89

Post by amelius »

codygman wrote: post #24

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…

> Nim is a very good language that actually accomplishes the simplicity Go wanted imo.

Does it have "cheap threads", like offered by Go?

Re: What Golang Is and Is Not

#90

Post by knucklesandwich »

stcredzero wrote: post #84
knucklesandwich wrote: post #13

Earlier quoted context omitted.

The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric t…

What they lack is the ability to let programmers introduce their own parametric types and functions, presumably because we're too dumb to be anything but consumers of this functionality. Here's what my experience is with certain features in languages: They enable some programmers to do great things, while also enabling a few programmers blinded by hubris to do maddening things. Over the life of a large project, the u…

You can make this argument with nearly anything we naturally accept as a feature of a programming language. The ability to name things has a long history of abuse. The ability to define types, implement programming patterns, define new syntactic features via high order functions, use concurrency primitives. Hell, simply the idea of programming is rife with potential for abuse.

This is a narrative without specifics, and unfortunately always where the conversation seems to end with gophers. We accept some amount of features that can be abused because they offer utility that outweighs their potential for misuse. So how exactly are generics a worse offender than these other features or a worse tradeoff for their utility? Because from my perspective, being able to define parametric data types and functions is a huge win for safety and terseness of code without a lot of downside.

Post reply on HN