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

101–110 of 297 posts

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

#101

Post by coder543 »

Herrin wrote: post #50
Thaxll wrote: post #43

Earlier quoted context omitted.

For one Elixir is very slow compare to Go.

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 didn't do.

For another comparison, feel free to click around on the tabs here: https://www.techempower.com/benchmarks/#section=data-r17&hw=...

The plaintext benchmark is about as far from a computationally intensive task as you can get... it should basically be network-bound, supposedly an ideal task for the BEAM VM, yet the results are clear.

If you turn on additional languages and frameworks, you'll note that Elixir or Erlang are significantly faster than, say, Rails, but Elixir or Erlang are a good 5x to 25x slower than Go.

People have built massive, successful companies on Ruby on Rails, such as GitHub, so don't think that I'm discounting these languages wholesale. You just have to accept that you will be paying substantially higher infrastructure costs if your infrastructure needs begin scaling beyond a single server. If you think that Elixir or Ruby or whatever else is the secret sauce to make your company successful, go for it! But those are a lot slower than Go or Rust or other very fast languages.

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

#102

Post by holy_city »

networkimprov wrote: post #12
_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…

My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(

To be fair that's generally good practice since it eliminates a branch in the code, depending on the type of v and overhead of assignment.

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

#103

Post by jeremyjh »

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

This is a solved problem in every compiled language I've ever used - at least 10 of them. Unused variables is a warning, and your CI build compiles with a -werror / --warnings-as-error flag. Thats it. All the benefits you mention, without the "slowing down development" that you mention.

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

#104

Post by throwaway34241 »

jayd16 wrote: post #65
sdegutis wrote: post #56

Earlier quoted context omitted.

The "Capitalization feature" is actually objectively worse because of the reason OP mentioned, of having to rename all semi-local usages when visibility changes. But good IDEs can help mitigate the difficulty of this. But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, C…

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 these refactoring features, instead of through specific capitalization conventions.

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

#105

Post by liveoneggs »

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…

that cpu spike in BEAM is actually a runtime setting and doesn't reflect usage; it's intentionally busy-looping the connection accepts to reduce latency.

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

#106

Post by tx-0 »

lmm wrote: post #52
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…

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.

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

#107

Post by danbolt »

lmm wrote: post #52
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…

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…

Part of me wonders if a lot of that baggage comes from C's background compared to Lisp. Or, especially when C's origins were originally to operate a PDP-8 I wonder if the goals and ideas behind each contributed to why the way they are.

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

#108

Post by jolmg »

lmm wrote: post #52
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…

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…

> You can pass functions but not return them.

  #include 

  char *f(void) {
    return "Yes, you can...";
  }

  char *(*g(void))(void) {
    return f;
  }

  int main() {
    puts(g()());
    return 0;
  }

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

#109

Post by coder543 »

liveoneggs wrote: post #105
coder543 wrote: post #101

Earlier quoted context omitted.

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…

that cpu spike in BEAM is actually a runtime setting and doesn't reflect usage; it's intentionally busy-looping the connection accepts to reduce latency.

huh. that seems like a lot of waste for no measurable benefit: https://stressgrid.com/blog/beam_cpu_usage/

maybe it's beneficial to someone, but I don't think that should be the default.

either way, it doesn't change the picture painted by the TechEmpower benchmarks.

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

#110

Post by DuskStar »

networkimprov wrote: post #12
_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…

My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(

Banning go fmt gets rid of one of the best parts of the go ecosystem, and I am horrified that you would do so.

go fmt may not be anyone's favorite code style, but having go fmt is so much better than dealing with everyone else's favorite (incompatible!) styles.

Post reply on HN