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

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

#221

Post by Ace17 » Thu, Jun 13, 2019, 6:23 AM UTC

Animats wrote: post #179

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

When was the last time you checked the return value of 'printf' ?

Would you consider it a good thing to be forced to do?

Moreover, there are functions for which "not ignoring" the return value isn't the same as "checking it" (e.g malloc, fopen, etc.).

(CppCon about error handling: https://www.youtube.com/watch?v=GC4cp4U2f2E )

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

#222

Post by fileeditview » Thu, Jun 13, 2019, 6:26 AM UTC

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…

I love go and all but append has some serious problems in my opinion. Look at this code for an example.

https://play.golang.org/p/qWCnF7d7Fl9

This is unexpected behavior at best.

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

#223

Post by astrange » Thu, Jun 13, 2019, 7:22 AM UTC

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)

Variable-argument macros, function prototypes (well, modules would be better…), // comments, stdatomic instead of 'volatile' hacks, _Bool, aligned_alloc, …

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

#224

Post by astrange » Thu, Jun 13, 2019, 7:27 AM UTC

didibus wrote: post #215

jstewartmobile wrote: post #117

Earlier quoted context omitted.

One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". From a lot of what I've seen, that is a useful description.

I think Go will suffer the same fate as Java. Any enterprise language that becomes too popular will slowly devolve into an enterprise monster. If you come to Java with a blank slate, and try using it with simplicity in mind. There's not much wrong with it. But once people add design patterns, layers of layers, reflection, annotations. Etc. You get a monster. And somehow, the enterprise world seems to always create th…

The problem with Java is that there isn't enough of it to have anything wrong with it. The programs have all those design patterns because the language lacks so much power that you have to write it all yourself. For instance, having value types would really help.

The one thing they should take away is namespaces. You can't write unreadable enterprise software if you can't put every 10-line class six packages deep for no reason.

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

#225

Post by astrange » Thu, Jun 13, 2019, 7:34 AM UTC

blablabla123 wrote: post #19

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…

Half of these issues are solved by linters which are also well integrated into virtually all common editors/IDEs. Also regarding warnings/errors: time-travelling back into the 90s it was normal that C/C++ code - also in Open Source Projects - was full of warnings and often not portable across compiler/library versions. That was a major pain, I remember myself experimenting a lot with compiler flags (-Weffc++, -strict…

Warnings are part of the compiler not the code, and if your project is complicated enough you'll always hit false warnings in some version of the compiler, because some gcc contributor just snuck in a false positive, or a library you're using deprecated something.

Everything being an error makes this worse not better; if -Wdeprecated turns into an error you're just not going to be able to fix everything in someone else's code. Unused code being an error is easy to fix, but it's so disrespectful. I shouldn't get compile errors as I'm editing when I haven't done anything wrong.

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

#226

Post by astrange » Thu, Jun 13, 2019, 7:45 AM UTC

trpc wrote: post #128

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.

That's not true, C# is a far more mediocre language. At least top 5.

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

#227

Post by kstenerud » Thu, Jun 13, 2019, 7:45 AM UTC

blablabla123 wrote: post #19

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…

Half of these issues are solved by linters which are also well integrated into virtually all common editors/IDEs. Also regarding warnings/errors: time-travelling back into the 90s it was normal that C/C++ code - also in Open Source Projects - was full of warnings and often not portable across compiler/library versions. That was a major pain, I remember myself experimenting a lot with compiler flags (-Weffc++, -strict…

Yes indeed. Hatred of projects full of warnings is one of the hallmarks of a good programmer.

Except that it only happens in C and C++.

Why? Because C and C++ were designed to have sharp edges for you to cut yourself. The default behaviors are absolutely bizarre and stupid, and the breadth of things that are undefined behavior guarantees that any given program is non-conformant. Warnings and -Werr and linters were the only possible ways to keep any semblance of sanity and code quality.

But we're not talking about those dangerous languages and their sordid history. We're talking about the here and now and modern languages, where an unused import NEVER causes bugs, and where unused values aren't flagged as errors in any other language for good reason: we debug code far more often than we write it, and slowing the debug process for the sake of cleanliness is stupid.

And it still astonishes me how unused values are treated as errors in a language that happily allows variable shadowing that is literally one colon away (= vs :=), and doesn't allow file-level variable and function isolation. Those are FAR more dangerous and bug inducing.

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

#228

Post by astrange » Thu, Jun 13, 2019, 7:50 AM UTC

throwaway34241 wrote: post #96

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.

The modern aggressive undefined-behavior based optimizations ruins any remaining appeal of the "simplicity" of C for me. The extremely broad definition of undefined behavior may allow the compiler to, for example, silently delete explicit checks for signed integer overflow [1] among other things and still claim standards compliance, but I don't think that programming model can reasonably be described as simple. It ma…

Lots of programs don't need efficiency in "hot loops". You want efficient code size everywhere (usually smaller is faster), and realtime programs like games are CPU-bound everywhere not just in one loop.

Undefined behavior is a great way to help the language help you; for instance, most loops look like infinite loops without it. All you need to do is test with ubsan to see if you're dynamically undefined anywhere.

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

#229

Post by [deleted] » Thu, Jun 13, 2019, 8:03 AM UTC

jeremyjh wrote: post #103

cr0sh wrote: post #60

Earlier quoted context omitted.

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

[deleted]

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

#230

Post by winrid » Thu, Jun 13, 2019, 8:24 AM UTC

tomohawk wrote: post #89

jayd16 wrote: post #62

Earlier quoted context omitted.

You can write small Java services. You really don't need Spring or anything. You should try it some time.

You can, but you can't deploy them. If you really want to keep your services separate, you need a separate JVM installation and jars for each service. Go gives you this automatically with a simple binary. Go's standard library is an order of magnitude (at least) better than Java's, much more comprehensive, much more cohesive, and much more capable.

Can't deloy them how? You would still use gradle or maven and package/deploy the same way.