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

251–260 of 297 posts

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

#251

Post by gerbilly »

didibus wrote: post #211
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…

Hum... Sow why did you stop programming in C?

Server side Java paid the bills. :-)

And in some ways the industry stopped programming in C as much.

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

#252

Post by liveoneggs »

coder543 wrote: post #109
liveoneggs wrote: post #105

Earlier quoted context omitted.

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.

I agree it is a bad default since 10 years

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

#253

Post by gerbilly »

WalterBright wrote: post #70
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.

I love C, but it's biggest mistake is clearly the unstoppable decay of arrays to pointers: https://www.digitalmars.com/articles/b44.html A mistake that C++ missed an opportunity to fix.

I read the article you linked. It's too bad they didn't decide to pass a fat pointer with the array dimensions.

But when the article implies that null terminated strings and the problems associated with them are caused by arrays decaying to pointers, I get more skeptical.

I mean it's not as if arrays in C are bounds checked anyway, so how would that have helped implement strings any better?

I guess you could have bounds checked them in the stdlib code, but you certainly wouldn't have gotten it for free just by knowing the array dimensions.

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

#254

Post by Thaxll »

verttii wrote: post #121
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…

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

You're right about the abstraction but Elixir is slow because the runtime is slower, because of immutability and many other reasons, if you don't use all the message passing features and just do pure CPU computation you will find it's still pretty slow.

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

#255

Post by jstimpfle »

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…

> Arrays are almost but not quite the same as pointers.

There's a big misunderstanding here. Arrays and pointers are entirely different things. An array is a chunk of elements that lie next to each other in memory. A pointer is just a pointer.

The only thing that C does that causes confusion is pointer decay. If you use an array in an expression context, other than the sizeof operator, that expression evaluates to a pointer to the first element of the array.

And while it's confusing the heck of many people who never learned it properly, it's very useful. For example, string literals are arrays, too! Would you prefer to write printf(&"Hello, World\n"[0])?

That's it, in a nutshell.

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

#256

Post by synthmeat »

verttii wrote: post #240
synthmeat wrote: post #141

Earlier quoted context omitted.

> you just need to build all the clustering mechanisms, OTP behaviors, tooling, actor model, embedded monitoring services and such from the scratch ...or just use kubernetes, to cover majority of those features.

I've never used Kubernetes so I don't know what it provides. But I doubt it could provide the mechanisms for two application nodes to connect to each other and automatically share real-time state. Or the monitoring services to the underlying virtual machine's green threads. Actually which of the above does Kubernetes really provide as it is in the Erlang VM?

Here is talk that elaborates it. It's obviously not 1-to-1, and there's other gotchas but there's convenient tables comparison linked directly.

https://youtu.be/ScE9TnoWltA?t=1792

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

#257

Post by jstimpfle »

pjmlp wrote: post #187
tx-0 wrote: post #106

Earlier quoted context omitted.

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.

UB is what makes C fast versus what PL/I variants and Fortran optimisers were already able to do without such tricks.

UB is not what makes C fast. A good (and fast) program does not contain undefined behaviour, at least ideally.

The only speed advantage of Fortran, to my knowledge, comes from pointer aliasing information that C compilers have a harder time to infer. But that's more a consequence of the programming domain. Fortran is not a systems programming language. Fortran has specialized data structures for scientific computing built in (I think??). It's an apple and oranges comparison.

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

#258

Post by _bxg1 »

DuskStar wrote: post #110
networkimprov wrote: post #12

Earlier quoted context omitted.

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.

> one of the best parts of the go ecosystem

Is it more powerful in some way than the auto-formatters that exist for nearly every other language?

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

#259

Post by _bxg1 »

randallsquared wrote: post #154
_bxg1 wrote: post #16

Earlier quoted context omitted.

Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.

Go's star feature is straightforwardness. Some people call this simplicity. The upshot is that it is very easy to use Go within teams of inconsistent expertise. Since there is a fairly low ceiling to cleverness, Go rewards just getting started rather than spending time making the code smaller, or more general. Of course, this is not as good for having fun programming, unless the programmer feels having written someth…

This seems similar to one of the main virtues of using Java - there's pretty much just one way to do any given thing and there's a "low ceiling to cleverness". Of course, Go's other features stand out much more when we're comparing to Java specifically.

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

#260

Post by sdegutis »

vips7L wrote: post #186
sdegutis wrote: post #67

Earlier quoted context omitted.

Not OP, but in my experience, it's harder to know how to get from System.out.println("hello world") to GET / in a browser showing " hello world ", without adopting some intensely documented framework and infrastructure, along with obscure XML configuration files. I liked that aspect of Clojure, but I wouldn't have a clue how to achieve the same thing in pure Java.

This is patently false. Getting to hello world is as simple as knowing how to add a dependency, just like any other language and requires 0 xml. See javalin [0], or spark [1]. [0] https://javalin.io/ [1] http://sparkjava.com/

Thanks for sharing these links! My point was that I didn't know how to do this, not knowing these frameworks existed and unable to find them on my own search. You solved that issue for me. If these frameworks get more attention, maybe it'll be solved for more people!
Post reply on HN