Why I Don't Like Golang (2016) • Hacker News Board

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

#121

Post by verttii » Thu, Jun 13, 2019, 1:09 AM UTC

coder543 wrote: post #101

Herrin wrote: post #50

Earlier quoted context omitted.

For what purpose? See: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...

I feel like that article just supports the comment you're replying to. I mean, look at this: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi... If the article had gone up to 250K connections, Elixir would have fallen down similarly to what happened to Node... although the reasons for Node being unable to keep up were unclear in the article, and I think warranted further investigation that the article did…

Elixir along with OTP and BEAM is sitting at a significantly higher abstraction level than Go. Everything is built around the distributed stateful soft-real time problem domain. While maintaining fault-tolerance.

You can have that in Go as well, you just need to build all the clustering mechanisms, OTP behaviors, tooling, actor model, embedded monitoring services and such from the scratch. You may well see Go significantly slower than Elixir at this point when you finish baking all that into it.

Developer hours are significantly more expensive than hosting. I'd happily pay double for hosting if it meant I could need half the people to accomplish the same task.

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

#122

Post by Aeolun » Thu, Jun 13, 2019, 1:14 AM UTC

amedvednikov wrote: post #116

I created a new language [0] that is very similar to Go, but it fixes many things people often complain about, including all of the points in this article (except #2, but I don't think it's a drawback, really). It got lots of attention in a couple of months since the public release, and I often hear people say that they feel like this is "Go done right". It'll be open sourced by June 20. [0]: https://vlang.io

This looks interesting. I might give it a go.

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

#123

Post by DaveInTucson » Thu, Jun 13, 2019, 1:15 AM UTC

I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure.

I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.

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

#124

Post by carterehsmith » Thu, Jun 13, 2019, 1:16 AM UTC

ChrisSD wrote: post #75

AlchemistCamp wrote: post #44

Earlier quoted context omitted.

I just started digging into C a few years ago and was struck by the same. It's amazingly simple and the only "flaw" that leaps out at me is the precedence of & and | being higher than comparison operators. Other than that, and maybe the macro system, everything frustrating about learning it was due to the frustration of dealing with the machine rather than anything C itself imposed on me.

C can be quite complex once you get into all the abstractions it's using. And even for newbies I think the whole syntax around pointers is unnecessarily confusing (or at least people are often confused by it in a way they usually aren't when learning assembly). Not to mention how many keywords and symbols are overloaded and depend on their context for meaning.

>> C can be quite complex once you get into all the abstractions it's using.

Perhaps you were referring to C++, or some newer C dialect?

What I mean is, the K&R C had very few (if any) abstractions, other than those defined by preprocessor.

Like, you could look a the C code and pretty much "see" what the assembly code would look like after compiler did its work.

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

#125

Post by maxxxxx » Thu, Jun 13, 2019, 1:17 AM UTC

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…

"The K&R book is worth a read if anyone missed it. It's beautifully written."

Agreed. I read the whole thing in a weekend and had a pretty good idea about pointers and stuff afterwards. I feel a lot of people have trouble with pointers didn't read it.

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

#126

Post by User23 » Thu, Jun 13, 2019, 1:20 AM UTC

losingthefight wrote: post #6

I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I perso…

I've been entirely satisfied with Go when using it to interact with kubernetes and AWS and do what doesn't amount to much more than CRUD and logging. I've never implemented any non-trivial algorithms with it though, which is what the article appears to be about.

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

#127

Post by kbp » Thu, Jun 13, 2019, 1:27 AM UTC

throwaway34241 wrote: post #104

jayd16 wrote: post #65

Earlier quoted context omitted.

WRT renaming, I find that refactoring code is often such an oversight from language designers. I consider C# to be an elegant language in this way. Public fields and properties look the same in C# so you can effortlessly refactor between them, for example. I wish more languages thought about this stuff.

For both C# and Go I use editors that understand the language and can rename all references to a variable with one keyboard shortcut. C# has at least 3-4 of these editors available, and Go has at least 2. I realize that not everyone's preferred editor may support every language yet, but still I think the solution to this problem is probably just having the language designers provide libraries that editors can use for…

It doesn't matter when you're making the edit, it matters when you're looking at the diff and skimming through a hundred identical changes for the things that are actually different.

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

#128

Post by trpc » Thu, Jun 13, 2019, 1:27 AM UTC

it's a mediocre language, in fact it's the most mediocre language I have ever seen, that is being pushed by managers who want to lower hosting costs and faster time to market with good runtime performance.

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

#129

Post by sim_card_map » Thu, Jun 13, 2019, 1:27 AM UTC

DaveInTucson wrote: post #123

I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure. I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.

Interesting. Do you have links? Or maybe a short summary why this is bad?

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

#130

Post by weberc2 » Thu, Jun 13, 2019, 1:29 AM UTC

marcosdumay wrote: post #112

weberc2 wrote: post #26

Earlier quoted context omitted.

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

> append() doesn't operate on arrays, it operates on slices If you go with most languages definition of "slice", that would be pretty horrible just by itself. But, as you said, Go's definition is different (what is also bad, just not much): > Slices are backed by arrays, and if you append to a slice whose backing array is full, it will "grow" by allocating a bigger array elsewhere and copying the original data into i…

> If you go with most languages definition of "slice", that would be pretty horrible just by itself.

Most languages don't have a definition of "slice" at all.

> What would be pretty much like Java's ArrayList, or Python's list if it was designed on a sane way. So, just the name would be non-standard... But the container actually migrates when it is reallocated! That's a broken design in any language.

It's not broken, it's just fast and simple. But yes, it does require you to know that Go's slices are not exactly Python's lists (which do gratuitous copies). Java's implementation does an insert on the original list (both surprising and an unnecessary copy).