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

Problems with Go's design

medium.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Problems with Go's design

#81

Post by ngrilly »

deepnet wrote: post #76
ngrilly wrote: post #72

Earlier quoted context omitted.

The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?

I beg to differ: the guarantees functional programming and data immutability offer are exactly the sorts of guarantees needed for scalable parallelisation. LOC is not a useful metric for the utility of a program, in fact the reverse is true in terms of maintainability and places for bugs to hide. This chap claims to write very robust programs, entirely functionally that are worth billions in their operation. http://l…

I agree that "the guarantees functional programming and data immutability offer" are very useful for "scalable parallelisation".

But this is not what I was answering to.

I was answering to the idea that FP and immutability are useful when you scale from 200K to 2M lines of code:

> the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines

In my opinion, this argument is irrelevant.

Re: Problems with Go's design

#82

Post by deepnet »

ngrilly wrote: post #81
deepnet wrote: post #76

Earlier quoted context omitted.

I beg to differ: the guarantees functional programming and data immutability offer are exactly the sorts of guarantees needed for scalable parallelisation. LOC is not a useful metric for the utility of a program, in fact the reverse is true in terms of maintainability and places for bugs to hide. This chap claims to write very robust programs, entirely functionally that are worth billions in their operation. http://l…

I agree that "the guarantees functional programming and data immutability offer" are very useful for "scalable parallelisation". But this is not what I was answering to. I was answering to the idea that FP and immutability are useful when you scale from 200K to 2M lines of code: > the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines In my opinion, this argu…

The argument being that non functional programming has fundamental limits to its scalability, seems like a very important question as the complexity of code begins to grow exponentially.

Large imperative codebases are inherently fragile, hence the need for test driven development - good batteries of tests offer demonstrable reliability.

Functional programming offers provable reliability.

Provability is not just for scaling complexity but also for much simpler software that absolutely must not fail.

Imperative code becomes hard to reason about before 200K LOC is reached.

Re: Problems with Go's design

#83

Post by ngrilly »

deepnet wrote: post #82
ngrilly wrote: post #81

Earlier quoted context omitted.

I agree that "the guarantees functional programming and data immutability offer" are very useful for "scalable parallelisation". But this is not what I was answering to. I was answering to the idea that FP and immutability are useful when you scale from 200K to 2M lines of code: > the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines In my opinion, this argu…

The argument being that non functional programming has fundamental limits to its scalability, seems like a very important question as the complexity of code begins to grow exponentially. Large imperative codebases are inherently fragile, hence the need for test driven development - good batteries of tests offer demonstrable reliability. Functional programming offers provable reliability. Provability is not just for s…

The counterargument is that very large codebases tend to be composed of multiple services. Each service lives in its own process and maybe in its own machine, and communicate with other services through IPC. At that point, you've lost the benefit of functional purity and immutability, because each service can maintain some "hidden" state.

You're right, above some threshold, it becomes hard to reason about imperative code with mutations. Your preferred solution is to adopt functional programming and immutability. Another solution is to decompose your system in multiple communicating services. Google's codebase is a very well known example of the latter approach.

Re: Problems with Go's design

#84

Post by spion »

ngrilly wrote: post #72
spion wrote: post #65

Earlier quoted context omitted.

I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern. Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional program…

The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?

Do they, now? Or do they only evaporate in Erlang?

Since most FP codebases do the same with a few orders of magnitude less code, no, I'm not aware. Though I imagine that if they had to copy their code for every single instance of their generic typeclasses, they would quickly amass many millions of lines.

Re: Problems with Go's design

#85

Post by Jemaclus »

spion wrote: post #79
Jemaclus wrote: post #74

Earlier quoted context omitted.

You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the nex…

Like I said, other code reformatting tools exist, the team lead picks the tool and tool settings, and that should be the end of it.

Yes, this is true, but you're overlooking a few of the things I mentioned earlier.

Gofmt is extremely opinionated -- you can't customize it. Most other tools involve customizing to fit your own style conventions. Gofmt doesn't allow that.

Gofmt also ships with Go, so it's a built-in language tool, not a third-party tool. That's a huge benefit right out the gate, meaning that everyone's code will look the same. You don't really appreciate how nice this is until it's actually true

Finally, gofmt is dead simple to use. `gofmt `. Boom. Done. Compare with, say, PHPCS, which is like: `phpcs --standards= --autofix=true --exclude=` and so on. Gofmt is just stupid simple to use.

Yes, you're right that other tools exist, but gofmt is the one that really makes it click for developers, and they think "Man, THIS is how code formatting should work." And then we take it over to the other languages, to C or Python or Javascript or PHP, and we introduce tools that are similar to gofmt. That's why gofmt in particular has "changed my life" (hyperbole, sure, but the point remains that I code completely differently now). Without gofmt, it's doubtful I'd ever adopt code formatting tools to the point that I have today.

Re: Problems with Go's design

#86

Post by sacado2 »

spion wrote: post #79
Jemaclus wrote: post #74

Earlier quoted context omitted.

You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the nex…

Like I said, other code reformatting tools exist, the team lead picks the tool and tool settings, and that should be the end of it.

I have already used one such tool for C++ in one of my teams (aastyle ? Something like that). It's only the firs step. Then you have to wonder/discuss: what actual style to use? There are many C/C++ styles out there (stroustrup, linux, gnu, OTBS, etc.), so you have to discuss about that. Now, when you have chosen one, you have to discuss about minor fixes: "ok, so OTBS is cool, but what about line lengths? Should we choose 80 cols? That's silly, why not 120?" etc. All in all, you end up taking a whole hour (even more) about this issue.

With go, that doesn't happen. You call gofmt and you're done. Another side effect: when you get external source code (open source, code written by another team, etc.), you know it will be formatted exactly the same way as yours.

Re: Problems with Go's design

#87

Post by spion »

sacado2 wrote: post #86
spion wrote: post #79

Earlier quoted context omitted.

Like I said, other code reformatting tools exist, the team lead picks the tool and tool settings, and that should be the end of it.

I have already used one such tool for C++ in one of my teams (aastyle ? Something like that). It's only the firs step. Then you have to wonder/discuss: what actual style to use? There are many C/C++ styles out there (stroustrup, linux, gnu, OTBS, etc.), so you have to discuss about that. Now, when you have chosen one, you have to discuss about minor fixes: "ok, so OTBS is cool, but what about line lengths? Should we…

I'm afraid that may be your fault. What style you pick doesn't matter much (consistency does though) so you should just pick one.

It really baffles me that anyone could spend so much time on something like that. I'm sure there are lots of more exciting (or more pressing) problems to solve on the projects you're working on...

Re: Problems with Go's design

#88

Post by spion »

ngrilly wrote: post #83
deepnet wrote: post #82

Earlier quoted context omitted.

The argument being that non functional programming has fundamental limits to its scalability, seems like a very important question as the complexity of code begins to grow exponentially. Large imperative codebases are inherently fragile, hence the need for test driven development - good batteries of tests offer demonstrable reliability. Functional programming offers provable reliability. Provability is not just for s…

The counterargument is that very large codebases tend to be composed of multiple services. Each service lives in its own process and maybe in its own machine, and communicate with other services through IPC. At that point, you've lost the benefit of functional purity and immutability, because each service can maintain some "hidden" state. You're right, above some threshold, it becomes hard to reason about imperative…

This is false. Well, it may be true in Erlang, but its false in Haskell, where there is always clear separation between equations and effects/state no matter the source (IO to other services or local state). Not to mention that there are tools such as STM that let you deal with state in a much safer and less error-prone way.

Separating the state between multiple communicating services is basically the same strategy as OOP (objects that communicate via messages and encapsulate state) but with stronger encapsulation requirements (access only via API, you can't just "reuse" methods willy-nilly all over the place but you have to come up with a sensible library or a third service, etc etc).

It works, yes but it works about just as much as OO does. Which is... not very much. And it also comes with its own tradeoffs (good luck getting atomic changes over multiple microservices)

Post reply on HN