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

Notes on the Go translation of Reposurgeon (2020)

gitlab.com

Post reply on HN
Print view View original

61–70 of 155 posts

Re: Notes on the Go translation of Reposurgeon (2020)

#61

Post by nauticacom »

scndrycntct wrote: post #54
nauticacom wrote: post #48

One thing that the people saying "just use a struct for keyword arguments" are missing is that structs should signal intent, i.e. "this is a concrete concept in the system." A Repository, Commit, Message, Person, etc. struct are all concepts in the domain, whereas "the arguments for this particular function" is not. I think Go people are allergic to writing code that does anything other than functionally work.

> I think Go people are allergic to writing code that does anything other than functionally work. I think that's what Go was designed for, as a language. To be readable, usable. It's uncaring for your personal programming philosophies. I think that's why it's been successful.

I'd agree that it was one of their design goals, but I wouldn't go as far as to say that it makes the language "readable and usable." That depends on what your values are.

Go's philosophy (which clearly flows from its creators being C-enthusiasts) is that the only thing that matters for reading, writing, and understanding a program is what it concretely does, i.e. what structures are created, where values are stored, how computations are performed etc. If that's also your philosophy, then of course it's going to jive with you.

But plenty of people also have different philosophies. Maybe you think the main thing that's important in crafting programs is developing a rich domain vocabulary that expresses concepts and how they interact. Maybe you think that what's important is formal proof of both logical and concrete correctness. In those cases, Go's rigorous opposition to abstraction (coming from its philosophy that what's important is concrete operations) will probably irritate and slow you down.

I couldn't say exactly why it got popular. I'd guess that some significant segment of programmers also share its philosophy, but I have no evidence to back that up. Certainly any reasonably uncontroversial language with a large suite of libraries backed by Google is bound to have some level of popularity.

Re: Notes on the Go translation of Reposurgeon (2020)

#62

Post by nauticacom »

CGamesPlay wrote: post #60
nauticacom wrote: post #48

One thing that the people saying "just use a struct for keyword arguments" are missing is that structs should signal intent, i.e. "this is a concrete concept in the system." A Repository, Commit, Message, Person, etc. struct are all concepts in the domain, whereas "the arguments for this particular function" is not. I think Go people are allergic to writing code that does anything other than functionally work.

Well, "Command to Create a Repository" could easily be a concept which contains all of the options necessary to create a Repository, which is a different concept. Now, there is a problem that all of the struct fields have to have sane zero values for this to work, but I think that is a problem which would naturally arise with keyword arguments as well.

Sure, if you're pushing things through a command bus or something. Otherwise you're just stretching it. If you wouldn't use it in a sentence to describe a use-case, I'd say that it's probably not a concept.

Would it? Only if you allow default values, which is a separate discussion. And even then only if your only mechanism for default values doesn't let the definitions specify what, exactly, the default value is.

Re: Notes on the Go translation of Reposurgeon (2020)

#63

Post by colin_mccabe »

mwcampbell wrote: post #17

Personally, I would have gone with Kotlin for a translation like this. It's a closer match to Python than Go, and I think his rule swarm [1] approach to semi-automated translation would have been effective. But then, he might not have liked the fact that, like Python 3 and unlike Go, the Java platform treats strings (particularly filenames) as a sequence of Unicode code points rather than bytes. [1]: http://esr.ibibl…

Go treats strings as a sequence of unicode code points.

Re: Notes on the Go translation of Reposurgeon (2020)

#64

Post by opmac »

nauticacom wrote: post #61
scndrycntct wrote: post #54

Earlier quoted context omitted.

> I think Go people are allergic to writing code that does anything other than functionally work. I think that's what Go was designed for, as a language. To be readable, usable. It's uncaring for your personal programming philosophies. I think that's why it's been successful.

I'd agree that it was one of their design goals, but I wouldn't go as far as to say that it makes the language "readable and usable." That depends on what your values are. Go's philosophy (which clearly flows from its creators being C-enthusiasts) is that the only thing that matters for reading, writing, and understanding a program is what it concretely does, i.e. what structures are created, where values are stored,…

> I couldn't say exactly why it got popular.

Probably because it has the backing of Google.

Re: Notes on the Go translation of Reposurgeon (2020)

#65

Post by jatone »

henvic wrote: post #31
thegeekpirate wrote: post #7

Earlier quoted context omitted.

> Able to have the confidence that we're checking for every situation that could occur on an enum type across the codebase is one less thing I need to worry about. golangci-lint ( https://github.com/golangci/golangci-lint ) is an absolute must, and includes https://github.com/nishanths/exhaustive which will check this for you.

my 50 cents: I'd rather just use go vet + staticcheck. Way simpler, no complex configuration, and no license concerns :) and then you can create a file like the following and add whatever analyzer provides value for your specific case (including this exhaustive), easily. Example: https://github.com/FiloSottile/mkcert/blob/master/analysis.g...

don't let perfect be the enemy of good. =)

Re: Notes on the Go translation of Reposurgeon (2020)

#66

Post by jasonhansel »

nauticacom wrote: post #48

One thing that the people saying "just use a struct for keyword arguments" are missing is that structs should signal intent, i.e. "this is a concrete concept in the system." A Repository, Commit, Message, Person, etc. struct are all concepts in the domain, whereas "the arguments for this particular function" is not. I think Go people are allergic to writing code that does anything other than functionally work.

IMHO, if the arguments to a function are just a bunch of heterogeneous values that cannot be sensibly grouped together, then that's usually a sign that the function needs to be refactored (e.g. because it's trying to do a bunch of unrelated things, or because it couples tasks together in an unnatural way).

Re: Notes on the Go translation of Reposurgeon (2020)

#67

Post by ts4z »

opmac wrote: post #64
nauticacom wrote: post #61

Earlier quoted context omitted.

I'd agree that it was one of their design goals, but I wouldn't go as far as to say that it makes the language "readable and usable." That depends on what your values are. Go's philosophy (which clearly flows from its creators being C-enthusiasts) is that the only thing that matters for reading, writing, and understanding a program is what it concretely does, i.e. what structures are created, where values are stored,…

> I couldn't say exactly why it got popular. Probably because it has the backing of Google.

I disagree. Go provides a low-runtime way of writing programs, like C, without having to resort to managing memory and threads super carefully. No VM, no interpreter, fairly straightforward to imagine what the compiler is doing.

You can do the same work in Java but you can't statically link the JVM. You can sort of do these in Python, but the compiler story is murky at best, and the language isn't as type safe.

Re: Notes on the Go translation of Reposurgeon (2020)

#68

Post by earthboundkid »

opmac wrote: post #64
nauticacom wrote: post #61

Earlier quoted context omitted.

I'd agree that it was one of their design goals, but I wouldn't go as far as to say that it makes the language "readable and usable." That depends on what your values are. Go's philosophy (which clearly flows from its creators being C-enthusiasts) is that the only thing that matters for reading, writing, and understanding a program is what it concretely does, i.e. what structures are created, where values are stored,…

> I couldn't say exactly why it got popular. Probably because it has the backing of Google.

Counterpoint: Dart.

Re: Notes on the Go translation of Reposurgeon (2020)

#69

Post by nauticacom »

earthboundkid wrote: post #68
opmac wrote: post #64

Earlier quoted context omitted.

> I couldn't say exactly why it got popular. Probably because it has the backing of Google.

Counterpoint: Dart.

I thought of Dart as a counterpoint, but if anything it's actually more proof. Dart kinda failed as a language in the browser because Google didn't really push it, and when they did it got pushback. Now that they've repurposed it for building mobile apps, it's surprisingly popular. Sure, not Go-levels of popular, but leaps and bounds more popular than if it were some scrappy OSS project. And it's in a similar camp to Go: reasonably uncontroversial (it's basically Java), large suite of libraries, backed by Google.

Re: Notes on the Go translation of Reposurgeon (2020)

#70

Post by azth »

throwaway894345 wrote: post #42
azth wrote: post #39

It's not surprising that the code base grew when reimplemented in golang. It would have probably been even shorter had it been rewritten in Python itself. Just the other day, I was able to condense over 15 lines of golang code into 3 lines (could also have been 2 lines) in a Python-like syntax, both reducing code length, and substantially increasing readability as it would make the underlying logic clearly stand out…

I think you have to be very careful before claiming readability gains from fewer lines of code. I've done a lot of Python programming and for simple things like mapping a single function over a list, a list comprehension or generator expression can indeed be a tiny bit more readable than a for loop, but combining that with some filtering or flattening and colleagues (and my future self) get frustrated. I've seen the…

I didn't claim that terse is always more readable. It was in the example I gave, and practically every golang program could be written in a more terse, more readable, and less error prone way in Python/Java/C#/etc.
Post reply on HN