Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

451–460 of 526 posts

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

#451

Post by guappa »

eru wrote: post #98
instig007 wrote: post #69

Earlier quoted context omitted.

> The industry is still built upon people who can build fast. Correction: the commercial software is, not the industry. The industry and corporations are capitalising on quality open-source software, meticulously written off working hours with a straight head and passion, and a great attention to details. The fact that you can write glue fast enough to satisfy your SLT is predicated on the presence of those quality c…

Lot of open source software is written by people who get paid for doing so.

But most is not. Especially not the libraries that are so used.

Some people in big projects are paid contributors, and some company open source some not so useful things as a marketing tool.

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

#452

Post by guappa »

abenga wrote: post #120
instig007 wrote: post #69

Earlier quoted context omitted.

> The industry is still built upon people who can build fast. Correction: the commercial software is, not the industry. The industry and corporations are capitalising on quality open-source software, meticulously written off working hours with a straight head and passion, and a great attention to details. The fact that you can write glue fast enough to satisfy your SLT is predicated on the presence of those quality c…

What, no quality tools exist written "with passion, and a great attention to details" in Go? *Doubt.

It's a language that is not very used by hobbyists or skilled developers, so the amount of things written on go outside of working hours isn't as big.

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

#453

Post by mike_hearn »

quotemstr wrote: post #322
mike_hearn wrote: post #268

Earlier quoted context omitted.

Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position: https://blog.plan99.net/what-s-wrong-with-exceptions-nothing... > Even junior engineers have a trivial time debugging most go errors Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful i…

I can't agree with you about C++ exceptions being worse than useless. Exceptional C++ is worth it. Safety isn't that hard with RAII and ScopeGuard.. In your map example, just add a scope guard that removes the just-added element using the returned iterator if the rest of the procedure doesn't succeed. It's no different in Java.

Haven't seen ScopeGuard before but it looks like an implementation of defer() in C++?

That sort of thing can help yes. But it's still way harder to get exception safety right in a language with manual memory management. In a GCd language you only have to be careful about cleaning up non-GCd resources, whereas in C++ you have to be ready for the expected lifetimes of things to be violated by exception unwinds at many different points and if you get it wrong, you corrupt the heap. Very few C++ codebases use exceptions vs all of them for Java, and I think that's why.

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

#454

Post by guappa »

Cthulhu_ wrote: post #73
monksy wrote: post #57

Earlier quoted context omitted.

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amou…

I don't even need to open a go codebase to know what's happening. 60% is "if err != nil".

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

#455

Post by guappa »

worldsayshi wrote: post #187
Cthulhu_ wrote: post #73

Earlier quoted context omitted.

Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amou…

The one language feature that I miss in most languages is pattern matching. I wonder if there's any minimalistic language that implements pattern matching well?

haskell?

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

#456

Post by guappa »

CharlieDigital wrote: post #267
poilcn wrote: post #142

Earlier quoted context omitted.

>and the fact it's so tied to windows Dotnet Core is not tied to windows except for certain frameworks like wpf (and there are alternatives for it that work everywhere), credential store. And it's actually really good to use these days.

Yup, common misconception for folks that haven't used it in a decade. Our team uses C#. We dev on Apple silicon Macs. Some use Rider, others just use VS Code. We build on Linux via GitHub Actions. Ship to prod running AWS t4g Arm64 instances. C# to me is like TypeScript++. The language, syntax, and core constructs are close enough that anyone with a good handle on JS and TS can pick it up easily and be productive.

I'm 100% sure your code integrates with the linux ecosystem as an american tourist in europe :D

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

#457

Post by guappa »

guappa wrote: post #383
AnimalMuppet wrote: post #347

Earlier quoted context omitted.

A general purpose language must be one that you cannot cause to segfault? That's a rather... unique perspective.

A segfault is a security vulnerability :) I expect a modern programming language that has a runtime to not do that, correct.

Lol at the people who got angry for some lapalissian truth drop :D

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

#458

Post by guappa »

dfawcus wrote: post #417
guappa wrote: post #151

Earlier quoted context omitted.

Go is very boilerplate. It requires at least 3 lines of error checking every 1 line of actual code. Also it doesn't have packed structs so it's completely incapable of doing low level networking or to handle binary files (you can of course do all the bitwise operations yourself… but is it sensible to use a language that is more error prone than C in 2024?). Also due to its lack of A LOT of system calls, you will need…

How low level a networking use do you desire? I certainly managed to use it to implement a protocol over UDP without any issues, that having byte and bit packed values. Or do you wish to have something similar to C with structs and (endian dependent) bitfields overlaid on packet buffers?

> Or do you wish to have something similar to C with structs and (endian dependent) bitfields overlaid on packet buffers?

endian dependent until you tell gcc which endianness you want :) Which you can't do in go.

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

#459

Post by guappa »

mrbadguy wrote: post #447
guappa wrote: post #384

Earlier quoted context omitted.

Yes it works, but you can't state the endianness and you have no control to decide if the compiler will decide to insert padding. It's undefined. You HOPE it works.

I don’t know about the padding (certainly it never inserted any when I’ve used it) but you can definitely state the byte order upon reading or writing. That would definitely be an oversight. Take a look at the encoding/binary package: https://pkg.go.dev/encoding/binary

I want a struct, not to having to write the code manually to do a struct every single time.

I know you can do that in go but as I already said: "more error prone than C".

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

#460

Post by guappa »

Daegalus wrote: post #287
guappa wrote: post #256

Earlier quoted context omitted.

From go programs at the very least I can expect they won't respect normal GNU getopt command line options, and work terribly with signals and going background in the terminal and so on. If it's a server, of course it won't support any way of communicating it's ready. Not the old fork way and certainly not the new sdnotify things.

why would it have to respect GNU getopt? When did that become the golden standard? I never respect getopt because I really don't care about it and it has no bearing on anything I build. As long as they are documented under `--help`. Almost everyone uses Cobra from command-line options. And it is capable of doing getopt if you want, but I don't see why it would be a requirement. Signals and Backgrounding seem to be ju…

> When did that become the golden standard?

30 years ago?

> Signals and Backgrounding seem to be just developers that have little experience with that stuff.

Yes, go developers have little experience. I see we agree.

> What more are you expecting?

Them to tell systemd they started.

> I don't even know what you are referring to by the `old fork way`

As I said, most go developers have little experience. I see you agree once again.

The old fork way is the portable way to do it with whatever init system (systemd included).

Post reply on HN