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

241–250 of 297 posts

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

#241

Post by masklinn »

fileeditview wrote: post #222
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…

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.

At a fundamental level, it's not so much append as slices being shareable and doubling up as vectors (being appendable). That's the core sin.

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

#242

Post by blablabla123 »

kstenerud wrote: post #227
blablabla123 wrote: post #19

Earlier quoted context omitted.

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

Not sure, I mean there are clear workarounds for the debugging stage, before pushing into a public branch one would probably remove those the same way one would remove other ad hoc debugging code. Of course there are official reasons for this: https://golang.org/doc/faq#unused_variables_and_imports

Speaking of myself, in various programming languages both ancient and modern I've run into the situation where debugging is difficult because of hard to read code. Code written by others (or written by myself 6+ months ago) is always more difficult to read. Even more so when there are unused artefacts ("dead code").

So often it happens that people have to work under a lot of time pressure and write 300 lines for something that can be solved in 30 lines in the same language. It doesn't matter so much usually but when there is a difficult bug, sometimes the only way to solve it is to thoroughly understand the code. For me it's often easiest to just remove dead code/compactify existing code so there is less code I have to reason about.

Probably a lot of Go's design is about simplicity, its spec can be read in 1-2 afternoons if you're already familiar with the language.

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

#243

Post by GenericsMotors »

astrange wrote: post #226
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.

Nuh-uh!

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

#244

Post by amedvednikov »

baby wrote: post #163
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

Options :) But generics :( I'm really hopping that Golang finds a way to either not add generics, or add them in contrained ways. Your example code for generics are very hard to read for example. Rust somehow tackles that with associated types, but since generics are still allowed it's not great imo.

Always interested in feedback, thanks.

Why do you find them unreadable, because of the angle brackets?

I've considered using

  struct Repo ⟨T⟩ {
    db DB
  }
Instead of

  struct Repo  {
    db DB
  }
The conversion would be done automatically by vfmt.

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

#245

Post by Rotareti »

hannofcart wrote: post #213
_fx6v wrote: post #57

Earlier quoted context omitted.

I can comment on this on my own: 1. Java - did not want to adopt the entire ecosystem. This is very much wanted a banana and got the whole jungle with a gorilla type of story. 2. Python - dynamic. Don't want that. Go's minimal typing is perfect. It's easy to deploy (binaries). It's fast. It can scale well. It's opinionated (love this). Python and Java both encourage and allow developers to flex creative solutions tha…

Python with type annotations and use of the mypy typechecker is really darn great. I work on Golang stuff at work where we made the switch after the troubles associated with refactoring Python. Recently though, I 'typed' a personal project of mine that was fairly large, and it's become a pleasure to work on. IDE integrations of mypy warn you as soon as type errors occur. The fact that the type annotations are first-c…

> mypy makes Python a pleasure to work with again.

This is my experience as well. I love that I have the option to use Python typed and untyped. For little scripts, fiddles, prototypes, etc. it's often convenient to omit type annotations. For solid software that runs in production it's nice to have them.

Another thing that I'm excited about is nuitka [0], a Python to C compiler that allows you to create binaries from Python code. It cut start-up time of a command line tool that I compiled with in half.

[0]: https://github.com/Nuitka/Nuitka

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

#246

Post by kstenerud »

blablabla123 wrote: post #242
kstenerud wrote: post #227

Earlier quoted context omitted.

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

Not sure, I mean there are clear workarounds for the debugging stage, before pushing into a public branch one would probably remove those the same way one would remove other ad hoc debugging code. Of course there are official reasons for this: https://golang.org/doc/faq#unused_variables_and_imports Speaking of myself, in various programming languages both ancient and modern I've run into the situation where debugging…

Yes, the workaround for unused things is:

- comment out a line of code to check something.

- compile, get an error about unused variables because a variable is unused now that the line that used it is commented out.

- go back to the code and comment out that other line.

- compile, get another error because there's another two variables that are now unused.

- comment those lines out.

- compile, get another error because an import is now considered unused.

- repeat ad nauseum.

- Fix the bug.

- Uncomment everything you commented, and try to undo any changes you made to get around unused variables so that your code is mostly back to where it was, plus the bugfix.

- Last compile to make sure everything works.

--

I prefer this method:

- Install a custom go compiler from https://github.com/kstenerud/go

- comment out a line of code to check something.

- go test -gcflags=-warnunused

- fix the bug.

- uncomment the line.

- go test

--

This has nothing to do with the difficulty of debugging the code, or the complexity of the code you are debugging. This is about getting the compiler to stop fighting you.

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

#247

Post by jsjolen »

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

If the size of a struct is changed through hot-code reloading then how does the runtime react?

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

#248

Post by norswap »

diamondo25 wrote: post #38
norswap wrote: post #21

Earlier quoted context omitted.

One of the praised functions in Scala 2.8 was postfix operators, allowing things like: Seq(1, 2) map _ + 100 They are getting rid of it: https://contributors.scala-lang.org/t/lets-drop-postfix-oper... Unit functions were a thing, just write: def A() { ... } This is inalid since 2.13. You have to specify its a unit: def A(): Unit = { ... } Most of the ideas in scala were to remove boilerplate, but they backfired. The…

I was referring to the first sentence: "Most of the items explained are non-issues and part of why Golang is how it is today."

It's an objective fact they removed features in Scala (I think that's a good thing). But dismissing the pointed issues as non-issues without explanation is what rubbed me the wrong way.

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

#249

Post by scroot »

masklinn wrote: post #212
ben-schaaf wrote: post #73

Earlier quoted context omitted.

Ruby actually went one step beyond: there are no attributes. `attr_reader` just generates a 0-arg method, while `attr_writer` just generates a 1 argument `name=` method.

TBF that's pretty directly inherited from the Smalltalk ancestry: just like Smalltalk, Ruby simply doesn't have public (data) fields. Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does. Funnily enough, Self opted for the opposite tack of not having private data fields (although it does have readonly and read/write slots), but you can trivially swap "data…

> Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does.

Most Smalltalk browsers do actually offer this capability

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

#250

Post by gerbilly »

50 wrote: post #193
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…

To piggyback this comment, does anyone know of any co's building something interesting mainly w/ the C programming language (and maybe even w/ Rust)? Also, that are usually open to interns/entry level programmers?

I don't know about companies, but the linux kernels is C, git is written in C.
Post reply on HN