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

121–130 of 155 posts

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

#121

Post by simion314 »

db48x wrote: post #75
simion314 wrote: post #53

Earlier quoted context omitted.

>My view is that when you develop a product, you have to own everything. The users don’t care if the bug comes from code you wrote, or code in a library, or the language’s standard library, or the OS. You have to fix the bug no matter what caused it. It doesn’t matter if the code came from a vendor or a language designer or stack overflow; you are the one responsible for fixing it if something goes wrong. So then usi…

Sometimes. Using someone else’s code is only a benefit if it saves time overall, compared to writing it yourself. You have to count both the time to write it and the time to maintain it over however long your product is active. You have to assume that you’ll be maintaining it yourself either way. Also, don’t forget that languages with big standard libraries, like Python or C# or Java, always end up with oodles of stu…

>Also, don’t forget that languages with big standard libraries, like Python or C# or Java, always end up with oodles of stuff in there that is deprecated or incompatible. That’s as bad a sign as anything.

This does not happen that much, and in Java and .Net world if some functionality is deprecated there is a replacement, I think I only remember some possible unsafe or ineeficient functions were deprecated so you use the better ones. I don't have experience with Rust , only with node/npm and is a hell , for some reason is decided to split stuff in super small pakcagtes of various quality, today I sepnd hours debugging a npm freeze caused by some package , in the end the cause is probably a shit npm/node implementation that crashes when some specific git version is installed , but debugging this I discovered that the unit testing packages the project uses(I inherited them) instead of beeing one or few packages are a few, and for some reason one of them had a weird dependency that it should not have(a dev only despondency ) and this dependency was also just pulling directly from GitHub ...shit in a few years when GitHub is gone lots of things will stop working (I also had issues with scripts because someone changed master into main because American politics...).

I personally prefer the Java or .Net model, a big standard lbirary and then for most important things you have a small number of options since the community did not wanted to do CV driven development, and most of the time you find all you need in a single library with no or few dependencies. But Rust does not have the Java or .Net money to hire devs to work on the boring stuff of correctly implementing standards like json,XML, date&time and keep maintaining it - (not sure how Python did it) and Rust community seems to be inspired byt node community a lot and this is bad.

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

#122

Post by preseinger »

nauticacom wrote: post #117
preseinger wrote: post #113

Earlier quoted context omitted.

> 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.

Ah, so in this framing, syntax is another way of saying amount of code?

Here's some Rust code

    pub fn read(&self) -> u64 {
      self.counts.values().fold(0, |acc, x| acc + x)
    }
Here's some analogous Go code

    func (w *Whatever) Read() uint64 {
        var total uint64
        for _, v := range w.values {
            total += v
        }
        return total
     }
The former is certainly fewer characters than the latter. But to me it represents _more_ syntactic bureaucracy, not less. There are more sigils, more language concepts I need to understand, more _types of syntax_ to express the same thing. It's 20% of the SLoC, but parsing it requires more implicit knowledge, and takes no less time, versus parsing the latter.

YMMV, of course. None of this is objective.

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

#123

Post by sangnoir »

nauticacom wrote: post #112
sangnoir wrote: post #109

Earlier quoted context omitted.

> 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

Not for their sake - for mine. I avoid people and places that make my life unnecessarily difficult, especially if I have to do support and can be called at 3am to resolve urgent issues.

My needs are pretty basic: I like code that is easy to understand and easy to change more than writing code that leaves a smug smile on my face. I read more code than I write, so YMMV.

The fewer surprises, the better for me, and so far, the collaborative codebases I've encountered the least number of surprises have consistently been in Go (the other languages I've been paid to work with are Javascript, Perl, Python, Java, and Scala).

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

#124

Post by LandR »

nauticacom wrote: post #112
sangnoir wrote: post #109

Earlier quoted context omitted.

> 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

Often times the developers moaning about complex code basically learned if statements and for loops and then were done learning.

But we still have to write code that these people understand. It makes no damn sense.

Sometimes, sure, people write horribly complex code, but sometimes it's just developers who have stopped learning. They see something that isn't immediately familiar and discard it as too complex and make no attempt at trying to learn.

What I don't get is why we have to pander to these people.

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

#125

Post by nauticacom »

preseinger wrote: post #122
nauticacom wrote: post #117

Earlier quoted context omitted.

> 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.

Ah, so in this framing, syntax is another way of saying amount of code? Here's some Rust code pub fn read(&self) -> u64 { self.counts.values().fold(0, |acc, x| acc + x) } Here's some analogous Go code func (w *Whatever) Read() uint64 { var total uint64 for _, v := range w.values { total += v } return total } The former is certainly fewer characters than the latter. But to me it represents _more_ syntactic bureaucracy…

Ah, that's interesting! I'm not the person who used "syntactic bureaucracy" but I did interpret it roughly like that, yes. I'm not sure what phrase I would use to describe "more syntactical constructs" as you're saying, but it's interesting how we saw the term differently.

Similarly, even though I'm not a big fan of Rust, I would personally prefer to encounter the Rust snippet. The way I read code, I'm already building up mental models of things in my head, so adding more (e.g. what fold is) isn't that big of a deal to me. I think I'm a person who is able to look at a function call and not have the desire to dig into its source, though, which I don't think is the way everybody (and most certainly not the designers of Go) feels. Plus once I understand the concept, even if it's a lot less universally applicable than fold, I can reuse my understanding of it throughout the system and possibly throughout multiple systems.

Like you said, I think this is largely a subjective thing. I just find it objectionable when people, on either side of the fence, come in and say "abstracting over concepts and possibly making them first class is always better" or "...always worse."

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

#126

Post by lucian1900 »

throwaway894345 wrote: post #102
pcwalton wrote: post #83

Earlier quoted context omitted.

ESR's proposal here is basically just another way of spelling Python list comprehensions or Perl 5 map (which is likewise a builtin, with special parsing rules). It's not "new PL territory" by any means.

I think the "new PL territory" was referring to a type-safe generic map builtin. Obviously Python and Perl don't have a concept of type safety. That said, I still wouldn't call that novel in the sense that a builtin version of a well-understood generic function doesn't seem like a feat of ingenuity.

Most statically typed languages have a type safe generic map or it can be easily built.

Just like with monomorphisation, Go just stubbornly rejects all PL research younger than 40.

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

#127

Post by dbt00 »

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…

> It's a closer match to Python than Go

I like Kotlin, but I really think of Go as the most probable outcome of someone saying "I'd like a staticly typed, concurrent/parallel Python", and then mumbled "but I hate exceptions". Go is very close to python in many respects.

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

#128

Post by __david__ »

preseinger wrote: post #79
oefrha wrote: post #23

Earlier quoted context omitted.

> But it doesn't take long to get used to it I did get used to it, but all the if err != nil { return nil, err } sometimes taking up half or more of the vertical space of a function is still an eyesore to me, even after writing a quite substantial amount of Go.

Error handling being explicit isn't an eyesore. It lifts what is with exceptions a hidden control flow to the foreground.

Explicit error handling isn't the complaint—3 vertical lines of error handling after every function call is. Rust, for instance, started this way and eventually introduced the `try!` macro and finally the `?` operator. It's still explicit, it just doesn't fill your screen with unuseful boilerplate.

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

#129

Post by throwaway894345 »

lucian1900 wrote: post #126
throwaway894345 wrote: post #102

Earlier quoted context omitted.

I think the "new PL territory" was referring to a type-safe generic map builtin. Obviously Python and Perl don't have a concept of type safety. That said, I still wouldn't call that novel in the sense that a builtin version of a well-understood generic function doesn't seem like a feat of ingenuity.

Most statically typed languages have a type safe generic map or it can be easily built. Just like with monomorphisation, Go just stubbornly rejects all PL research younger than 40.

> Most statically typed languages have a type safe generic map or it can be easily built.

That's my point.

> Just like with monomorphisation, Go just stubbornly rejects all PL research younger than 40.

That's flamebait.

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

#130

Post by throwaway894345 »

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…

> Because concepts in programming languages mean things

Right, but a struct means "a collection of named parameters", not "a concept in your domain model" although a struct can be used to model the latter.

> A discrete, named entity (a struct)

Structs don't have to be named. E.g., `var person struct { Name string; Age int }`.

> 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 fundamentally different concepts

It's not the same thing at all. In your analogy, a map is not a set but the advice says to use the map instead of the set anyway. But we're not talking about using one thing as another, we're talking about using a struct as a struct--one such (common) use for a struct is passing named values into a function.

Post reply on HN