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

221–230 of 279 posts

Re: What Golang Is and Is Not

#221

Post by oconnor663 »

divan wrote: post #174
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…

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

Examples that bother me sometimes. YMMV of course.

Writing to a closed channel panics, but writing to a nil channel blocks forever.

Appending to a nil slice works fine, but inserting into a nil map panics.

If you have a function that returns an error struct, and you wrap it with another function that returns the error interface, nil returns from the inner function will no longer test equal to nil.

Defining a method with a receiver type of Foo, rather than Foo, means all modifications to the Foo get silently dropped. This can also happen to methods that correctly take a pointer receiver, if their caller incorrectly takes a value receiver.

Maps are not threadsafe/goroutine-safe.

Expression evaluation order is not defined, and varies between compilers. (https://github.com/golang/go/issues/15905)

Re: What Golang Is and Is Not

#222

Post by pjmlp »

snaky wrote: post #207
pjmlp wrote: post #168

Earlier quoted context omitted.

It is a small thing because there are other languages that offer the same safety with more features and lets face it, if a C coder is willing to embrace a GC enabled language there are lots to chose from, with AOT compilation to native code. I just expected more from Google, specially if one compares to the other company sponsored languages.

Comparing apples to apples, the first compiler sponsored by 'other company' was PHP, so Go looks not that bad in comparison. Reason is second, and maybe Google's second language would be 1ML.

Actually I was thinking in all languages that had commercial compilers, which goes way back than just PHP.

Re: What Golang Is and Is Not

#223

Post by tomjakubowski »

TillE wrote: post #16
catnaroek wrote: post #5

Earlier quoted context omitted.

C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.

I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.

I certainly wouldn't say these are "simple features" in C++. Overload resolution in particular is one of the most complicated parts of the language. Default arguments can get weird since the right hand side of the default, more or less, just gets inlined at the call site; I do recall there were a couple bugs in the last year at work because of C++ default arguments, though I don't remember their details.

It's also fun when you don't realize a particular function has a default argument until you make a function pointer to it and assign/pass it to something that you mistakenly think is compatible. Depending on how nasty your codebase's use of templates and overloaded functions is, this can be a nightmare to debug.

Re: What Golang Is and Is Not

#224

Post by cjrd »

xiaoma wrote: post #116
jksmith wrote: 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…

Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

How did you determine the adoption curve?

Re: What Golang Is and Is Not

#225

Post by AdieuToLogic »

mixedCase wrote: post #143
bad_user wrote: post #85

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

>After all, Go ignores all progress in programming languages for the last 40 years. I've seen this meme being spouted so much every time Go's mentioned it's ridiculous. No, piling up feature upon feature is not progress otherwise we wouldn't be using anything but C++. Go is a language you pick for the right situation. If it's not enough for what you're trying to do, go for a different one instead of trying to expand…

  >After all, Go ignores all progress in programming
  languages for the last 40 years.

  I've seen this meme being spouted so much every
  time Go's mentioned it's ridiculous.
Is it a meme when it is true? To support this question, witness the statements of Rob Pike[0] below.

---

Regarding the utility of supporting first-order functions[1]:

  I wanted to see how hard it was to implement this sort
  of thing in Go, with as nice an API as I could manage.
  It wasn't hard.

  Having written it a couple of years ago, I haven't had
  occasion to use it once. Instead, I just use "for" loops.

  You shouldn't use it either.
---

Regarding progress in programming languages[2]:

  One thing that is conspicuously absent is of course
  a type hierarchy. Allow me to be rude about that for
  a minute.
And[2]:

  Programmers who come to Go from C++ and Java miss
  the idea of programming with types, particularly
  inheritance and subclassing and all that. Perhaps
  I'm a philistine about types but I've never found
  that model particularly expressive.
---

The part about "particularly inheritance and subclassing and all that" is ironically a meme spouted by Go's community so much it is, if you'll pardon my borrowing your description, ridiculous. For the curious, there are many community "Go-isms" explainable by the Pike talk[2].

Even a casual reading of the "list of significant simplifications in Go"[1] (35 in all) is enough to reasonably support the "ignoring all progress" position.

Of course, YMMV.

0 - https://en.wikipedia.org/wiki/Go_(programming_language)

1 - https://github.com/robpike/filter

2 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Re: What Golang Is and Is Not

#226

Post by dilap »

vvanders wrote: post #56
dilap wrote: post #48

Earlier quoted context omitted.

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.

Can you do an arena allocator in Go with disparate types? If not then you're really missing out on data locality. In also not a huge fan of a compiler "automatically" performing escape analysis. Makes a single change causing cascading perf problems very easy and hard to catch.

no, not with disparate types (maybe if you resort to weird tricks with unsafe). i'd be curious to hear a use-case for this that ends up being different than just 'normal gc allocation' (not doubting you, just curious).

Re: What Golang Is and Is Not

#227

Post by _ak »

jacques_chester wrote: post #165
_ak wrote: post #159

Earlier quoted context omitted.

And where is Algol now? It's dead. Theoretical superiority on paper is worth absolutely nothing when there is no usable implementation for modern computing environments out there. This article was written to make Go look bad and unoriginal, but it inadvertently proves that Go is Algol's legitimate successor exactly _because_ it has all these features _and_ a working implementation that is available for wide variety o…

I think Pascal (and Modula and Oberon) are more legitimate successors to Algol. I wasn't aware that all of those working implementations had stopped working. Popularity is just one dimension a language can be placed on. Java utterly dominates the volume of new code being written in regular industry and has most likely done so for the entire lifetime of Go. And this says little about their other relative virtues.

Fun fact: one of the Oberon-2 developers is also one of the principal developers of Go. Learn your PL history.

Re: What Golang Is and Is Not

#228

Post by mattdeboard »

olalonde wrote: post #211
xiaoma wrote: post #116

Earlier quoted context omitted.

Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

What leads you to believe Elixir is on a much steeper adoption curve? I'm a bit surprised by that statement because I've seen a lot of open source projects written in Go (Docker, IPFS, Kubernetes, etc.) but none in Elixir.

> What leads you to believe...

Marketing.

Re: What Golang Is and Is Not

#229

Post by grey-area »

20yrs_no_equity wrote: post #162
unsignedqword wrote: post #50

I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.

Multiple return is great, though sending a tuple back is how we've been doing it in erlang for 20 years. Not much difference between {foo, bar} and (foo, bar). Go's error handling however is terrible, absolutely the worst and its tendency to panic is atrocious. Especially without supervision or restart capability. HEre's a spot where elixir has it right and is vastly superior.

I have large go programs in production for several years which have never panicked from the first line of code written. Go's error handling is perhaps simplistic but it doesn't encourage the use of panic, quite the reverse.

I'd be happier if panic didn't exist, but it is extremely rare in real world programs and the std lib.

Re: What Golang Is and Is Not

#230

Post by mafribe »

snaky wrote: post #111
mafribe wrote: post #101

Earlier quoted context omitted.

Another problem with 1ML is that it's only a research prototype for now, so we can't take it "for a spin". Given the 1ML inventor's main job, this is unlikely to change any time soon, unless some kind soul takes on the 1ML project lead.

OTOH maybe we will be surprised by the name of first language with working compiler to web assembly.

Ohhh that would be amazing, have you got inside information that you can share?
Post reply on HN