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

111–120 of 155 posts

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

#111

Post by preseinger »

kraig wrote: post #55
autarch wrote: post #32

Earlier quoted context omitted.

I feel like strong typing _helps_ when exploring a new domain, as it forces you to really think about the data you're operating on. In a language like Perl or Python, it's so easy to just throw around a bunch of hashes/dicts and that can get messy really quickly. I don't miss _exceptions_ in Go but after using Rust for a while I've come to really love Rust's `Option` and `Result` types. They're more ergonomic and exp…

With generics around the corner I am really hoping we see some flavor of Option & Result coming to Go. But I won't hold my breath for ?.

> I won't hold my breath for ?.

Good idea :) `?` hides a control flow that Go takes great pains to make explicit. Adding it to the language would be a disaster.

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

#112

Post by nauticacom »

sangnoir wrote: post #109
LandR wrote: post #95

Earlier quoted context omitted.

I don't find go readable in the slightest, the syntactic bureaucracy is just too high. There is a forest full of code hiding a trees worth of business logic, always. Go is one of the least expressive languages I've ever used.

> Go is one of the least expressive languages I've ever used That is by design, and when it comes to "programming in the large" - a winning formula. I keep repeating this response: I worked on a Perl codebase with a medium-sized team. Perl is very expressive, and my teammates did not hold back. I can tell you that is a nightmare to debug or add a new edgecase to a "clever" Perl 1-liner, usually it involved making the…

It's a spectrum, though. A language can be between 0 expressiveness (Go) and 100 expressiveness (Perl, maybe Lisps), and claiming that the only way to avoid the mysterious evil team member who will wreck your codebase is to patronizingly limit them "for their own sake" is insulting

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

#113

Post by preseinger »

LandR wrote: post #95
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 don't find go readable in the slightest, the syntactic bureaucracy is just too high. There is a forest full of code hiding a trees worth of business logic, always. Go is one of the least expressive languages I've ever used.

> the syntactic bureaucracy is too high.

Huh? What do you consider syntactic bureaucracy? Go has like 25 keywords and no sigils -- the least "syntactically bureaucratic" language I'm aware of!

> Go is one of the least expressive languages I've ever used.

This is definitely true. Of course expressiveness is not strictly a virtue!

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

#114

Post by nauticacom »

preseinger wrote: post #106
nauticacom wrote: post #90

Earlier quoted context omitted.

Not really? I suppose what I meant by that was that, if you make a struct, it should represent a concept that makes sense outside of the context of passing it to one function in particular; you're signalling that this collection of data represents a concept in your program

Why isn't "the collection of input parameters to this function" a concept in my program? I understand it's applicable scope is smaller than a e.g. DTO, but does that matter categorically?

I suppose it could be, but imo it starts diluting the value of domain modeling if everything is given the same weight. A bundle of inputs to a function just doesn't have the same weight as a struct representing a repository or a commit or something, so modeling them as the same concept just doesn't sit right with me. It could be a personal thing, though.

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

#115

Post by nauticacom »

throwaway894345 wrote: post #96
nauticacom wrote: post #88

Earlier quoted context omitted.

Even if you're not doing OOP you're modeling your domain in one way or another. Whether those models are explicit and expressive or not, and how you define those qualities, is another question. In neither case are the arguments to a particular function typically a concept in your domain

> Even if you're not doing OOP you're modeling your domain in one way or another. Using structs to bundle function parameters doesn't preclude or inhibit using them for domain modeling.

Sure, but there's a purpose-built tool that doesn't overload an already existing concept, and it's called keyword arguments

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

#116

Post by preseinger »

nauticacom wrote: post #110
throwaway894345 wrote: post #93

Earlier quoted context omitted.

> it should represent a concept that makes sense outside of the context of passing it to one function in particular Why? What's the utility? Fewer characters?

Because concepts in programming languages mean things. A discrete, named entity (a struct) is a distinct concept from a way to increase readability of a function call (keyword arguments). Overloading them with the same language construct is compressing disparate concepts. It's the same thing when "Go has no set type" comes up and people say "map[T]struct{}!" You might implement a set using a map, but they're fundamen…

> A discrete, named entity (a struct) is a distinct concept from a way to increase readability of a function call (keyword arguments).

If you take

    func NewServer(addr string, certKey, certCA []byte, ...) (*Server, error)
and coalesce the input parameters into

    type ServerConfig struct {
        Addr    string
        CertKey []byte
        CertCA  []byte
        ...
then that type is still a meaningful domain concept in your program. There is no minimum scope requirement for discrete, named entities, is there?

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

#117

Post by nauticacom »

preseinger wrote: post #113
LandR wrote: post #95

Earlier quoted context omitted.

I don't find go readable in the slightest, the syntactic bureaucracy is just too high. There is a forest full of code hiding a trees worth of business logic, always. Go is one of the least expressive languages I've ever used.

> the syntactic bureaucracy is too high. Huh? What do you consider syntactic bureaucracy? Go has like 25 keywords and no sigils -- the least "syntactically bureaucratic" language I'm aware of! > Go is one of the least expressive languages I've ever used. This is definitely true. Of course expressiveness is not strictly a virtue!

> What do you consider syntactic bureaucracy?

I would assume "amount of syntax required to express a given concept," with the use of the word "bureaucracy" implying that some concepts require too much syntax relative to their complexity (something that depends on your values). The classic example being mapping over a slice.

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

#118

Post by preseinger »

nauticacom wrote: post #62
CGamesPlay wrote: post #60

Earlier quoted context omitted.

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.

> Only if you allow default values, which is a separate discussion.

Keyword args practically require default values, I think? In any case, while this feature (like every feature) definitely delivers value, it's the considered position of the Go authors that this feature, over time, has a net negative impact on program maintainability.

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

#119

Post by preseinger »

nemo1618 wrote: post #73

What I really missed was generic map-function-over-slice, which could be handled by adding a much narrower feature. If one graded possible Go point extensions by a figure of merit in which the numerator is "how much Python expressiveness this keeps" and the denominator is "how simple and self-contained the Go feature would be", I think this one would be top of list. So: map as a functional builtin takes two arguments…

> a real missed opportunity for Go to explore new PL territory

But Go was not intended to explore new PL territory. Is that not OK?

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

#120

Post by preseinger »

nauticacom wrote: post #114
preseinger wrote: post #106

Earlier quoted context omitted.

Why isn't "the collection of input parameters to this function" a concept in my program? I understand it's applicable scope is smaller than a e.g. DTO, but does that matter categorically?

I suppose it could be, but imo it starts diluting the value of domain modeling if everything is given the same weight. A bundle of inputs to a function just doesn't have the same weight as a struct representing a repository or a commit or something, so modeling them as the same concept just doesn't sit right with me. It could be a personal thing, though.

> A bundle of inputs to a function just doesn't have the same weight as a struct representing a repository or a commit or something

That's true. But IMO a language primitive can carry a wide variety of semantics.

Post reply on HN