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

141–150 of 297 posts

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

#141

Post by synthmeat »

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

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

#142

Post by apta »

jayd16 wrote: post #64
mi100hael wrote: post #61

Earlier quoted context omitted.

I also prefer writing REST APIs in Go. - Compared to Java: Ecosystem is way over-engineered. You might get along just fine without writing a bunch of boilerplate and factories and XML configs, but sooner or later you're probably going to pull in some dependency that does and have to deal with a bunch of clunky APIs and other annoyances. - Python: Possibly the only language that's even worse at dependency management t…

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 being said, the moment you need something more involved, say validation, DB access, pre- or post- endpoint call processing (e.g. for authorization), then golang completely falls on its face. There is nothing in golang that compares to Jooq[4] for instance, and because golang doesn't have annotations, you can't do automatic validation or authorization, and you end up having to do everything manually in a verbose and error prone manner.

For static compilation in Java, GraalVM is supposed to be quite good[5]

[1] http://sparkjava.com/ [2] https://javalin.io/ [3] https://www.dropwizard.io/1.3.12/docs/ [4] https://www.jooq.org/ [5] https://quarkus.io/

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

#143

Post by SilasX »

ryl00 wrote: post #68
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 ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. "const" as well (back ported from C++ ?). And being able to declare variables anywhere (instead of just at the beginning of a block)

Interestingly, the high level language you implement for the nand2tetris course has this constraint, which makes writing the compiler easier

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

#144

Post by earenndil »

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 can have lambda expressions[1]. And clang does even have closures[2].

1: http://walfield.org/blog/2010/08/25/lambdas-in-c.html

2: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)

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

#145

Post by apta »

sim_card_map wrote: post #129
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?

It becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needless changes.

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

#146

Post by tacticus »

sn_master wrote: post #139
losingthefight wrote: post #93

Earlier quoted context omitted.

Aside from what others have said, the single tiny binary and cross-environment compilation is a huge plus. I can compile my largest service in seconds for Windows, Linux, and Mac (we still use Docker, but not for the cross-environment reasons). It's simple, concise, and fast out of the box. I also have been bitten far too many times by the JVM being RAM hungry and, frankly, I focus on startups which don't have time o…

single binary, yes. tiny ? not so much really (compared to C/C++ atleast)

But compared to java, python, node, ruby, c# or similar deployments. It's minuscule

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

#147

Post by apta »

bluquark wrote: post #40
886 wrote: post #28

Earlier quoted context omitted.

you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?

Kotlin and Swift are both currently encroaching on Go's server-side use cases. For example, Go's star feature, goroutines, has recently been cloned by Kotlin. They are at least as equally pleasant to program in, and they're hitched to major client platforms which means they improve faster and will definitely have a pool of trained developers in the long term.

Java is getting a fiber implementation by means of project Loom, which will make golang even less appealing. The good thing is that because the fiber implementation will be built into the JVM, Kotlin and other languages can use them seamlessly.

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

#148

Post by apta »

Boxxed wrote: post #99
gerbilly wrote: post #37

My one line take on this: You don't use Go for the language design, you use it for the tooling.

100% agreed -- it's crazy to me how much stuff you can just sweep under the rug when you have fast compilation, a decent debugger, static binaries, and so on. I always tell people, "I love everything about Go except for the language."

> have fast compilation, a decent debugger, static binaries, and so on.

See Java[1], C#[2]. Both have good compilation speeds (which don't really matter when you have incremental compilation anyway), as well strictly superior debuggers.

[1] https://quarkus.io/ [2] https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...

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

#149

Post by jmspring »

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…

I think one's love/comfort with C depends one's path into software development. It was my first language (aside from Basic). It has it's quirks and you can do some really bad/dangerous things when writing large apps.

That said, given my comfort level and tendency to be more explicit rather than tricky, my C coding ends up surprising me a week or so later when I go back and realize "even at 2am" I did the right thing.

It's also a fun language to mess with junior programmers with.

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

#150

Post by baby »

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.

Same here, people can complain but the reality is that more and more people find Golang a great language to use day-to-day. Honestly I think it's here to replace Java and to stay.

Same as Rust replaced C and C++.

That anyone would want to write C/C++ or Java today is absurd, except if they're old.

Post reply on HN