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

I want off Mr. Golang’s Wild Ride (2020)

fasterthanli.me

Post reply on HN
Print view View original

451–460 of 477 posts

Re: I want off Mr. Golang’s Wild Ride (2020)

#451

Post by lanstin »

throwaway894345 wrote: post #325
throw10920 wrote: post #322

Earlier quoted context omitted.

> Density divorces us from context a lot more than physical distance on a screen. You mean " unreadable code divorces us from context". "Density" doesn't have anything to do with it until you get to the point where your code is so dense as to become unreadable. Moreover, "physical distance on a screen" is a strawman. The options aren't density and distance, they're density and not being able to see the code on the sc…

> You mean "unreadable code divorces us from context". "Density" doesn't have anything to do with it until you get to the point where your code is so dense as to become unreadable. As density increases, the difficulty of parsing also increases. At a certain, relatively early point, that difficulty rapidly exceeds the costs of scroll-and-scanning. > Moreover, "physical distance on a screen" is a strawman. The options…

A long time ago I would shrink my code (C at the time) with a very small font and then just look at the shape of the important files. It was illuminating. The C and hence to some extent Go philosophy is that well written code has a narrative structure. Each file tells a coherent story about one character of the system.

Re: I want off Mr. Golang’s Wild Ride (2020)

#452

Post by lanstin »

preseinger wrote: post #438
throw10920 wrote: post #316

Earlier quoted context omitted.

> It is acceptable for code whose maintainers value readability and simplicity over everything else. Errors-as-return values are less readable than conditions, not more - there's literally more visual noise on the screen. And if you want "simplicity", don't use a computer. Computers are intrinsically complex devices, users desire features with complex implementations, and our job as programmers is to manage complexit…

> Errors-as-return values are less readable than conditions, not more - there's literally more visual noise on the screen. No. When you make a function call, and that call can fail, then the happy-path and the sad-path are both things that you need to manage as a caller. Happy-path and sad-path are two equivalent states that both need to be accommodated by the program logic. Error handling code is not "noise". It is…

Maybe this is the fundamental argument here. Plenty of cases I have written code where I am trying to do something over a big set of things, e.g. check a file for hard-coded paths, or send a message to a lot of people; it isn’t weird for those things to fail. Maybe I couldn’t open the file. Maybe the file lacked hard coded paths. Maybe the sender lacked rights to send to that receiver, or maybe the receiver is currently offline. But if most of your code is some complex calculation, say weather simulation?, maybe there is by default just one path.

Re: I want off Mr. Golang’s Wild Ride (2020)

#453

Post by kaba0 »

lanstin wrote: post #449
kaba0 wrote: post #264

Earlier quoted context omitted.

Yes, but that is definitely not achieved by checking for errors every second line.

The value here is the few seconds of human attention given to the error at hand. The thought is irreplaceable. Like others mention, 90% of the, end up if err != nil { return nil, err } but thinking about it will, in my experience, make the system more robust to failure. At the very Least for your process you will decide on a goal of carrying on in the face of failures and repairing when things work again vs. just bai…

What if the return nil, err was the sane choice at the time of writing but there are changes downstream that mandate a new error handling mode there? Also, there are plenty of “writing this code at 3AM” where I would question the validity of such thoughts.

Re: I want off Mr. Golang’s Wild Ride (2020)

#454

Post by astrange »

Cthulhu_ wrote: post #394
oversocialized wrote: post #33

Earlier quoted context omitted.

Seems too many devs use go for something it is not meant for. Tried doing math calculations in go - not a good a idea. But for backend stuff like rest api, web servers, networking, sysadmin and devops tasks, it shines.

I mean, a lot of developers have or look for a golden hammer, coerce their favorite language in doing a task. And since every programming language is turing complete, it CAN work, but whether it's the most elegant is not guaranteed. I mean for math, similarly, Java and co wouldn't work very well either.

Java is solidly mediocre at math, like everything else, but it does work. At least if by math you mean numeric/arithmetical programming, not an algebra system. I think I'd prefer Julia though.

Re: I want off Mr. Golang’s Wild Ride (2020)

#455

Post by astrange »

asherah wrote: post #174
jhoechtl wrote: post #82

Earlier quoted context omitted.

Golang gives you freedom. Rust gives you seat belts. It depends on you what you value more.

would highly prefer my car to have seatbelts over "simplicity" and "freedom" if i plan to go over 30mph with it

Personally I like my programming languages to have warnings instead of errors for something like an unused import.

To avoid the car analogy, let's use construction - an in construction building should be allowed to keep the scaffolding up while it's being built.

But maybe you should still clean the floors? Uh oh, it's getting away from me already.

Re: I want off Mr. Golang’s Wild Ride (2020)

#456

Post by preseinger »

dkarl wrote: post #448
preseinger wrote: post #436

Earlier quoted context omitted.

Cognitive complexity is not related to character count. The expression let x = f.a()?.b()?; is exactly as "easy" to parse as the code block of y, err := f.a() if err != nil { return fmt.Errorf("a: %w", err) } x, err := y.b() if err != nil { return fmt.Errorf("b: %w", err) } They are effectively equivalent in terms of cognitive load.

I disagree. These two bits of code cater to different ways of reading. The first caters to a happy-path reading, where the reader has the choice to yadda-yadda the error handling or mentally expand it. The second foregrounds the error handling on an equal footing with the other logic. I like your example, because this is exactly what happened in the application code I had to work with. In an application with complica…

You're absolutely spot-on with this analysis. And it is a core assertion of Go that non-explicit error handling produces less reliable programs. It's a value judgment and it's a subjective assessment.

Re: I want off Mr. Golang’s Wild Ride (2020)

#457

Post by preseinger »

lamontcg wrote: post #441
preseinger wrote: post #433

Earlier quoted context omitted.

Cognitive load is unrelated to SLoC. This expression let a = x.iter().filter(...).apply(...).map(...); is equally or even potentially _more_ cognitively complex than this expression for _, v := range x { if !filter(v) { continue } vv := apply(v, ...) vm := map(vv, ...) ... }

focusing on a pedantic detail that i clearly didn't intend and which doesn't change my point. consider it from a blocks-of-code metric, or some better slightly more abstract metric, that isn't affect by simple things like whitespace transformations, and try assuming that we all understand that we should write code that isn't monstrous to begin with.

"Monstrous" is an opinion, not a metric.

I would personally much rather maintain the code in the second example than in the first.

Re: I want off Mr. Golang’s Wild Ride (2020)

#458

Post by astrange »

throw10920 wrote: post #104
the_common_man wrote: post #42

Earlier quoted context omitted.

> For example, Go error handling is shit What is bad about it?

Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations. For everything else, conditions+restarts are the correct answer, because errors-as-values restricts you to a single error-handling strategy and couples high-level code to low-level code as a result.

Doesn't adding conditions/restarts require your language to have stackful continuations? Those are quite complicated unless you don't bother to make them safe (like C doesn't bother to with setjmp/longjmp). I would be nervous about them for the same reason I am about exceptions.

Also, the restart seems to imply that you should "handle" the error, but I think this is really overemphasized cause what are you actually going to do about it? There's nothing to do about a lot of errors except die, but this encourages programmers to just make something up they think might help.

Re: I want off Mr. Golang’s Wild Ride (2020)

#459

Post by astrange »

klodolph wrote: post #84

Yes, the cross-platform stuff sucks on Windows. I’ve seen languages with a few different approaches, I’d like a moment to compare them here. I’m going to talk about some specific aspects of cross-platform compatibility but not attempt to compare one single aspect across many platforms. With C++, you can use the preprocessor to give you a string type which is UTF-8 (nominally) when compiled on Unix and UTF-16 (nominal…

> You also can’t even roll your own process spawner without great difficulty, because you can’t safely call fork() from C# (not a surprise).

Do you get posix_spawn()? That's a far superior API to the frankly horrifying and slow mandatory use of fork().

Re: I want off Mr. Golang’s Wild Ride (2020)

#460

Post by astrange »

kaba0 wrote: post #272
dragonwriter wrote: post #246

Earlier quoted context omitted.

Go always seems to be to be designed to be simple for the compiler (which, to be fair, has benefits: fast compilation is useful in a compiled language, to keep code-build-test cycles short) more than the programmer.

I never really understood this reasoning. To me the ideal thing would be a fast debug-compile mode that barely optimizes and a don’t care how slow release mode that uses every possible optimization for the end result. Rust is plenty interactive with its similar mode of working. Incremental builds are fast.

I am a performance engineer and recommend against this. Optimizations don't really work that well on their own; to get performance you want an ongoing conversation between yourself and the compiler, which you don't get if the compile time is super long.

If you do have a really long running superoptimizer discovering things, then you'd want a way to write that back into the code so you don't need to discover it again.

Also, most of your program should be at -Os because it's not hot code and the important thing is to stop it from disturbing the fast parts. (Or because the aggressive optimizations actually make it slower. Totally possible with fancy ones like autovectorization.)

Post reply on HN