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

Just Use Go

blainsmith.com

Post reply on HN
Print view View original

231–238 of 238 posts

Re: Just Use Go

#231

Post by potato-peeler »

dualvariable wrote: post #220
potato-peeler wrote: post #171

Earlier quoted context omitted.

> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go,…

> Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go, rust, etc, want errors to be explicitly handled. I mean I'm explicitly supporting how rust doe…

It’s insane that you are incapable of understanding anything I wrote. It’s even more insane that you seem to be unaware about evolution of error handling and why things are different in modern languages.

Study software engineering. Or study in general. Might improve your comprehension issues.

Re: Just Use Go

#232

Post by ameliaquining »

cloudfudge wrote: post #226
ameliaquining wrote: post #156

Earlier quoted context omitted.

You can make it statically linked using musl. (This is underdocumented because Microsoft thinks it's usually a bad idea: https://github.com/dotnet/sdk/issues/37643#issuecomment-1873... )

Oh that's good to know. I happen to think Microsoft is chasing a bad philosophy with that declaration, and there is no more danger in statically linking ssl if you're continuously rebuilding and deploying your statically linked scratch image, but then again, the Microsoft approach to a lot of things isn't what I want in my datacenter. To each their own, I guess. I happen to love how self-contained Go programs can be…

I agree that this is the best approach if your organization is technically mature enough to be on top of it. I do have some sympathy for Microsoft here because they have to ship one set of safe defaults for all the different distribution and deployment setups that are out there, and statically linking your TLS library has the more dangerous failure mode (shipping a known-vulnerable version) if you don't have a rock-solid continuous-delivery setup, which Microsoft has no way of knowing whether is the case or not. I do think they could formally document this with a "don't enable this unless you've got monitoring set up for vulnerable native dependencies and can quickly ship a new build" security warning, though.

Re: Just Use Go

#233

Post by cloudfudge »

ameliaquining wrote: post #232
cloudfudge wrote: post #226

Earlier quoted context omitted.

Oh that's good to know. I happen to think Microsoft is chasing a bad philosophy with that declaration, and there is no more danger in statically linking ssl if you're continuously rebuilding and deploying your statically linked scratch image, but then again, the Microsoft approach to a lot of things isn't what I want in my datacenter. To each their own, I guess. I happen to love how self-contained Go programs can be…

I agree that this is the best approach if your organization is technically mature enough to be on top of it. I do have some sympathy for Microsoft here because they have to ship one set of safe defaults for all the different distribution and deployment setups that are out there, and statically linking your TLS library has the more dangerous failure mode (shipping a known-vulnerable version) if you don't have a rock-s…

Yes, totally agreed that for a LOT of organizations, relying on a system dependency that will likely get upgraded independent of your service is probably the simpler way to go and the way to make sure your TLS implementation stays current. But when you're building tier zero services that must control their dependencies like their lives depend on it, the opposite approach can be quite beneficial, and I don't need Microsoft telling me I'm doing it wrong because I'm not in the 99% use case.

Re: Just Use Go

#234

Post by jaen »

cloudfudge wrote: post #225
jaen wrote: post #158

Earlier quoted context omitted.

Nah. Go also relies on libc if you do anything non-trivial, like look up a the IP address of localhost. $ go build -o hello main.go $ file hello && ldd hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go linux-vdso.so.1 (0x00007f9c7b404000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c7b1ce000) /lib64/ld-linux-x86-64.so.2 (0x…

Lol well I don't know what the trigger is for pulling in libc there, because I've built massive scale services that did a lot of nontrivial stuff and then the deployment was a single-binary docker container that did not have libc. The only thing needed to be put in the container was a directory full of root certs so it could do TLS. (full disclosure, I don't think I ever had my service look up the address of localhos…

Yeah, I'm fully aware, no point in "works for me"-ing this.

CGO_ENABLED=0 breaks nsswitch etc. and overall makes Go a poor ecosystem inhabitant. Only usable if you only care about your own system.

Re: Just Use Go

#235

Post by Milpotel »

binaryturtle wrote: post #228
Milpotel wrote: post #97

Earlier quoted context omitted.

What language/toolchain/platform are you talking about because C/C++/Python/... all have the same issues?

Bootstrapping a modern/ up-to-date C/C++ compiler works, getting an up-do-date Python onto the system works too. No such issues with either of those. But try the same with Go or Rust and you hit nasty roadblocks (in both cases the older OS was previously supported just fine.)

I'm not sure what C/C++ compilers you have in mind but bootstrapping older GCC and LLVM versions on modern systems is far from trivial and typically requires patching (e.g. older LLVM versions do not compile with modern compilers) and pinning a whole ecosystem (cmake, C lib, autotools, ...). The same is true for the other way around, modern C compilers usually do not compile on older systems and you get lucky if you find a round trip of several versions that get you a roughly working compiler at some point.

Re: Just Use Go

#236

Post by Mawr »

nick_ wrote: post #219
clausecker wrote: post #214

Earlier quoted context omitted.

Go had panic/recover right from the get go. Nobody “caved.” And indeed, you are free to use panic/recover for error handling in your code. That was always allowed. That said, the key insight of the exception craze is that error returns are a normal part of a functions behaviour and as such should not use extraordinary control flow to take place. Exceptions (panics) are used for things that should never happen or are…

You're right about recover being in 1.0 of golang. I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me. That said, the typical performance complaints made against the most common implementations of exceptions are valid.

> I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me.

Then you definitely don't understand the tradeoffs after all, and/or don't know the history of error handling.

Exceptions are an outdated concept that's inferior to explicit error returns for 99% of software.

The tradeoffs are super simple here - exceptions require very little of your input but lead to terrible spaghetti due to hidden control flow. Explicit error returns are seemingly the opposite, but their verbosity issues have mostly gone away thanks to modern language improvements, so they're just better, unless you're writing short scripts and the like.

The situation is very similar to static vs dynamic typing - dynamic typing used to make a lot of sense in the days of extremely verbose Java type declarations, but modern static type systems with inference have made dynamic typing basically obsolete.

> That said, the typical performance complaints made against the most common implementations of exceptions are valid.

This also sounds off and outdated to me. If anything, exceptions typically have better performance, so long as errors aren't common. Indeed, if optimized correctly, exceptions have zero cost if not thrown, which can get you better perf than error returns, which have a low, but constant cost.

Re: Just Use Go

#237

Post by cloudfudge »

jaen wrote: post #234
cloudfudge wrote: post #225

Earlier quoted context omitted.

Lol well I don't know what the trigger is for pulling in libc there, because I've built massive scale services that did a lot of nontrivial stuff and then the deployment was a single-binary docker container that did not have libc. The only thing needed to be put in the container was a directory full of root certs so it could do TLS. (full disclosure, I don't think I ever had my service look up the address of localhos…

Yeah, I'm fully aware, no point in "works for me"-ing this. CGO_ENABLED=0 breaks nsswitch etc. and overall makes Go a poor ecosystem inhabitant. Only usable if you only care about your own system.

> Only usable if you only care about your own system.

Ahaaa, that clicks. Yes, I tend to build software that only cares about my own systems.

Re: Just Use Go

#238

Post by nick_ »

Mawr wrote: post #236
nick_ wrote: post #219

Earlier quoted context omitted.

You're right about recover being in 1.0 of golang. I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me. That said, the typical performance complaints made against the most common implementations of exceptions are valid.

> I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me. Then you definitely don't understand the tradeoffs after all, and/or don't know the history of error handling. Exceptions are an outdated concept that's inferior to explicit error returns for 99% of software. The tradeoffs are super simple here - exceptions requi…

Can you point me to a language that encodes the handling of errors in a less verbose way than C++/Java/C# exception handling?
Post reply on HN