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

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

171–180 of 297 posts

Re: Why I Don't Like Golang (2016)

#171

Post by kazinator »

jolmg wrote: post #120
User23 wrote: post #115

Earlier quoted context omitted.

Technically passing and returning function pointers is very different from passing and returning functions. This has implications for things like closures.

By the fact that lmm said "You can pass functions", they probably meant "function pointers", since that's the only way you can pass in something that could be referred to as a function in C. EDIT: At least last I heard. The example I gave is C89, and I know C99 and some GNU extensions. I don't know if a new standard introduced something else that could be referred to as a function that can be passed in but not return…

GNU C has "downward funarg" closures, like Pascal. They have the same representation as function pointers, which requires the compiled code to generate trampolines (little pieces of machine code that find a PC-relative environment pointer) on the stack. Invoking them requires executable stacks (a linker-level executable option often now turned off by default in major GNU/Linux distros).

Re: Why I Don't Like Golang (2016)

#172

Post by kazinator »

tx-0 wrote: post #106
lmm wrote: post #52

Earlier quoted context omitted.

Can't say I got that feeling at all. Smalltalk is a tight design. So is Lisp. So is Forth. So is APL. C's design just feels like a pile of... stuff. Arrays are almost but not quite the same as pointers. You can pass functions but not return them. There's a random grab-bag of control flow keywords, too many operators with their own precedence rules, and too many keywords given over to a smorgasbord of different intege…

but you can't pass functions in C, you can only pass pointers-to-functions... and you can return them too. the piles of stuff that C contains are the stuff of 20th century von Neumann architectures, the stuff that defines the undefined behaviors, and that's what has made C indispensible. I'm not saying C's perfect, but you can't swap it out without replacing what it did and does.

That's the same with languages that have first class functions. The code part is still passed by reference, not by copying around the machine code.

Re: Why I Don't Like Golang (2016)

#173

Post by hliyan »

dawkins wrote: post #79

I have been using Go in production since 2012 and I find it a fantastic tool. Except for point 8 ("The sort.Interface approach is clumsy") the rest are features for me. I am so grateful for the Go creators for having made it as it is. What worries me is the recent changes: modules (never had a problem with GOPATH) and Go 2 proposals. I hope they are able to keep their vision as it started.

> modules (never had a problem with GOPATH)

I actually fall into the opposite camp. I never felt comfortable with GOPATH, but found modules extremely natural, perhaps because it's somewhat analogous to how NPM works: go mod init -> nom init; go get -> nom install...

Re: Why I Don't Like Golang (2016)

#174

Post by tzs »

axaxs wrote: post #63
gerbilly wrote: post #31

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…

Same here. K&R C is probably still my favorite programming book. I will admit that most of the examples I had to stop and think about, they all seemed 'cleverly' written. But in each case, it gave me pause, and taught me a new, often simpler way.

At the time it was written, there was a good chance that the person reading it would not be doing so at a computer. Their computer access was quite likely via a terminal on a time sharing system, that they had to share with others. They couldn't hog a terminal while reading a book and typing in examples from it.

So books of that day where written so you could learn a lot just from reading the book and thinking seriously about the examples, and working out the exercises in your head or on paper

It helped if every couple of days or so you could get some computer time and try out the things you learned, but it wasn't actually necessary. In the case of K&R, you could go through the whole book without touching a computer, and then one or two sessions afterwards trying things out could be enough to correct your misunderstandings.

I wish more books were like that today. Nowadays, they assume you are a computer all the while you are reading the book, and often depend on that when writing the text.

Re: Why I Don't Like Golang (2016)

#175

Post by dralley »

simias wrote: post #82
gerbilly wrote: post #31

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…

>To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics. Except that clearly history showed that it wasn't enough, and we ended up with about 50 millions (and counting) different meaning for "static" for instance. I like C but its simplicity is almost by accident more than by design. It's pretty far from "perfect" in my book. There are so many weird features…

Well, there's Golang (despite it's flaws, and the different target audience)

Or Zig (which is less superficially C-like on the surface, but is going for the same simplicity and low-level-ness).

Re: Why I Don't Like Golang (2016)

#177

Post by dullgiulio »

apta wrote: post #142
jayd16 wrote: post #64

Earlier quoted context omitted.

I see this complaint against Java a lot. If you're going to slum it in a language with no ecosystem so you don't feel overwhelmed, why not just use less of the Java ecosystem?

These complaints are usually by people who have not been using modern Java, or who have just been reading or hearing unsubstantiated claims about it. Or who haven't worked in large golang projects to see all the mess it brings with it because of how underpowered it is. Look up libraries like Spark[1] or Javalin[2] and you get something quite light weight. Or DropWizard[3] if you need something more holistic. That bei…

GraalVM is nowhere near production-ready nor is supported by a lot of frameworks. Porting existing code is still a big challenge.

Re: Why I Don't Like Golang (2016)

#178

Post by SomeOldThrow »

weberc2 wrote: post #26
_bxg1 wrote: post #8

Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like la…

> Isn't this just duck typing? Don't other languages renowned for their type systems do this? It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical. > That's horrifying. append() doesn't operate on arrays, it operates on slices. Arrays are fix…

> This is a pretty standard data structure in most languages.

Yes, vectors are common, but they don't typically require compiler modifications to avoid mis-using them. In this case I'd make it super clear whether the method mutates the existing value or returns a new one, and "possibly both" seems like the worst of both worlds. If this behavior is preferred, it seems like `append` should take a handle to a slice pointer, possibly to a slice rooted in the stack, and write to it if replacing the underlying slice.

Re: Why I Don't Like Golang (2016)

#179

Post by Animats »

Being able to ignore return values is something that C had before they had function prototypes. The compiler didn't know if something returned a value, so it couldn't check. There's no good reason for that misfeature in a newer language.

Go apparently does it that way to make "defer" work.[1]

[1] https://github.com/golang/go/issues/20803

Re: Why I Don't Like Golang (2016)

#180

Post by anon121212 »

cr0sh wrote: post #60
kstenerud wrote: post #3

This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think t…

> Stopping compilation with an error for every unused import & variable is particularly annoying It's been a long while since I last touched Golang, but I recall the process of learning it. My coworker and I were tasked with creating an interface for our employer (a cloud service provider) to allow Rancher (or clients of Rancher - I forget) to use our backend system (which was built out of a combination of PHP, Java,…

> Something changed. We understood...

Like having an annoying wife (erm, spouse) constantly tell you you've wrong all the time. In the end, some if not all will understand and adapt their behavior as complaining is of no further use.

Post reply on HN