Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

511–520 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#511

I really wanted to like go, and I tried to write a discord bot using it, but the very opinionated brace style (which isn't the one I prefer to use), and the fact that I struggled to much to try and split my code across two files kinda turned me off it. In the end I just went back to python

Genuinely curious, why am I being downvoted? Did I say something wrong?

Probably just your opinion being shallow.

I mean, come on, coming to Go and of all things complaining about brace style? Coming to Python and of all things complain about syntactically significant whitespace? Coming to Lisp and complaining about parentheses? This is so old.

Re: Lies we tell ourselves to keep using Golang (2022)

#512
post #237

Earlier quoted context omitted.

There is Crystal and Nim. With especially Nim, there is GC and generates c in the end.

Unfortunately, Nim's BDFL is... not known for playing well with others. Perhaps the Nimskull fork will grow into something widely useful? https://github.com/nim-works/nimskull

That's total BS btw, I've been part of the Nim community for over 7 years now and never had an bad interactions with the project's lead. But I did witness behavior from certain individuals that was out of line. Some of them went on to blame Araq in other places, I have read their criticism, which I found very hypocritical. You should take their views less seriously.

Re: Lies we tell ourselves to keep using Golang (2022)

#513

I really wanted to like go, and I tried to write a discord bot using it, but the very opinionated brace style (which isn't the one I prefer to use), and the fact that I struggled to much to try and split my code across two files kinda turned me off it. In the end I just went back to python

Of all the things you can complain about the language, how could you choose the thing that Go got right? It's K&R style is probably the best.

Re: Lies we tell ourselves to keep using Golang (2022)

#514

Earlier quoted context omitted.

This. And there is one technique that would help in this. Too often I see code like "xyz := pkg1.SomeFunc(a, b, c)" that makes xyz's type non-evident, especially when interfaces are involved. Please write Go code like var xyz pkg2.SomeType xyz = pkg1.SomeFunc(a, b, c) My 0.02€, YMMV.

That should not be an issue, unless the code is written in notepad. As for interfaces, a better approach is to return struct and accept interface in your functions wherever it is possible.

Sometimes it's better to to return interfaces, like contract style programming.

Re: Lies we tell ourselves to keep using Golang (2022)

#515
post #508

Earlier quoted context omitted.

>So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking. No. You're choosing to write the `?` there to bubble up the error. It's a compiler error if you forget it. Whereas with `throws FooException` you only get forced to remember it the first time, and after that…

> You're choosing to write the `?` ...but you're not choosing to write the `throws FooException`? I can only say that if the `?` weren't around and you had to write more verbose handling each time, having the question "How should this one particular error be handled?" might come up more often and might prevent more bugs than when you can carelessly `?`-annotate your way through a dozen lines without any equivalents o…

>...but you're not choosing to write the `throws FooException`?

Now read the rest of the comment after where you stopped reading. Or reread https://news.ycombinator.com/item?id=42249525 I'm tired of repeating myself.

Re: Lies we tell ourselves to keep using Golang (2022)

#516

Every time I work in a different language I'm always wanting to go back to Go even if it's not the perfect language. I just love the fact that it literally just works. You install Go, you download code, and write code that's it. No figuring out what version, runtimes, configurations, build tools, package managers to use. Just install and Go. I think maybe Rust is the only other programming language that provides the…

This should be the most celebrated aspect of Go, which Rust adopted, along with channels.

Re: Lies we tell ourselves to keep using Golang (2022)

#517

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…

Bjarne said it best; There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Yet somehow his language meets both criteria somewhat and is only saved by legacy code. Not to say that C++20 or above is not good, I personally think it's one of the best but sadly not every org can afford to upgrade easily.

Re: Lies we tell ourselves to keep using Golang (2022)

#518
post #450

Earlier quoted context omitted.

Yeah I feel Go is simple in the way people say "C is simple" (without the footgun part) It was created for one purpose and it kinda works but it's clunky. Like there are no fancy front loaders or backhoes and there's a limit on how much out of that form you can get.

But go has plenty of footguns. For example the most common pattern is to just ignore errors.

Of course. Still way less than C

Re: Lies we tell ourselves to keep using Golang (2022)

#519

Earlier quoted context omitted.

Can you please give me an example of what you don’t like? I’m not sure I understand the “write the code manually to do a struct” bit. You have to define the struct for sure, but beyond that you just pass it to binary.Read and it comes back with the fields populated. I don’t see how you’d avoid defining the struct.

I believe what he wants, is the usual C trick of defining a struct which represents the wire format (with all the usual caveats). Then cast a char pointer to be an instance of a pointer to that struct. Sort of like this: https://github.com/danos/vyatta-dataplane/blob/master/src/ecmp.c#L108-L116 It sort of works on x86 chips, but is not so effective on MIPS, PPC, etc where misaligned access are either unavailable, or…

https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.ht...

If the misaligned access is slow… it will be slow whether the compiler reads the variable or if you hand-write even slower and error prone code.

That said, please show me a protocol that generates unaligned accesses on any architecture. People writing protocols aren't noobs :)

Re: Lies we tell ourselves to keep using Golang (2022)

#520
post #475

Earlier quoted context omitted.

> I have yet to find a developer […] Users care, because that's how all the other commands work. It's the standard whether you like it or not. Of course you can choose to do the snowflake CLI, but that doesn't really shout "experienced dev" does it? > windows oh lol… what % of go programs is used on windows? 1? 2? > Why? So systemd can start the other service that depends on that one? You need to know when the docker…

> Users care, because that's how all the other commands work. It's the standard whether you like it or not. Of course you can choose to do the snowflake CLI, but that doesn't really shout "experienced dev" does it? I have never had a user complain about this. They just read the readme or the `help` and use it accordingly. > oh lol… what % of go programs is used on windows? 1? 2? I am sure it is quite a bit more than…

> Oh I know it

You just wrote in a previous comment that you did. Make up your mind :)

I'm not wasting even more time with this.

Post reply on HN