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

91–100 of 155 posts

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

#91

Post by throwaway894345 »

nauticacom wrote: post #69
earthboundkid wrote: post #68

Earlier quoted context omitted.

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 push back . 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…

Google has never meaningfully "pushed" Go. From Google's perspective, Go is just a backend language that's a good fit for some internal Google applications. I don't think they care tremendously that other people use it, although they certainly don't mind. On the other hand, Google strategically wanted a robust frontend ecosystem (hence investing heavily in Dart and V8) because getting more applications off of PCs and onto the web meant more user data up to collect and more opportunity to serve ads.

In particular, I don't understand how Go is more Java-like than Dart.

    Feature            | Java | Dart | Go
    -------------------+------+------+----
    jit compilation    | yes  | yes  | no
    inheritance        | yes  | yes  | no
    classes            | yes  | yes  | no
    nominal subtyping  | yes  | yes  | no
    native binaries    | no   | no   | yes
    static artifact[0] | no   | no   | yes
    static typing      | yes  | opt  | no
    value types        | no   | no   | yes
What other features do Java and Go have in common that they don't also share with Dart?

[0]: For sanity's sake, we'll assume this means "are static artifacts common/default" and not "is it technically possible to produce a static artifact" because for some sufficiently broad definition of static artifact the answer can be yes for any language (e.g., Docker images).

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

#92

Post by SquishyPanda23 »

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.

> To be readable, usable.

Go doesn't particularly value readability or usability. For example, the short variable name convention makes it harder to read code you're unfamiliar with, and there are a number of noticeable usability shortcomings, some of which are mentioned in the article.

I think Go's design goals were really to (1) reduce compilation time, which explains why Go has human programmers do work that compilers do in other languages, (2) be statically typed and compiled, so you can use it conveniently for microservices, and (3) have syntax somewhat similar to Python.

I think of Go as the successor to Java. Go is to Python as Java was to C++. That, plus the integration with many libraries is why it's taken off in some niches.

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

#93

Post by throwaway894345 »

nauticacom wrote: post #90
preseinger wrote: post #76

Earlier quoted context omitted.

> structs should signal intent Isn't a collection of parameters to a function an intent?

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

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

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

#94

Post by stouset »

db48x wrote: post #27
stouset wrote: post #24

Earlier quoted context omitted.

Appreciate your thoughtful reply! One question. Regarding this bit: > He did investigate Rust to a certain extent, but bounced hard. His chosen program didn’t really show off Rust’s strengths, because he started by trying to call select and write essentially the same program that he would have written in C. That’s a pretty painful way to go. Is this stating that he was writing the Rust version similarly to how he wou…

He went down the wrong path, but at the same time Rust didn’t do anything to make async code easier to write. You just had to call libc::select and std::thread::spawn and whatnot, with all of the unsafe blocks that implies. These days there are about 47 different crates that can help you do it, all of them a lot nicer than that.

That's what I thought, but I just wanted to confirm. Thanks!

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

#95

Post by LandR »

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

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

#96

Post by throwaway894345 »

nauticacom wrote: post #88
throwaway894345 wrote: post #84

Earlier quoted context omitted.

Not everyone is a Kingdom of Nouns purist. Even most OOP proponents that I've spoken with reject Kingdom of Nouns because it's pretty indefensible (in the worst case it leads to banana-gorilla-jungle problems[0] and in the best case it imposes arbitrary and unnatural restrictions on program design). Note also that "modern Java" and "modern C#" and "modern C++" and "modern Python" virtually all reject these kinds of d…

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.

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

#97

Post by saghm »

ts4z wrote: post #67
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.

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.

> No VM, no interpreter

That's not quite accurate; there is a runtime, it just gets statically linked into the binary instead of needing to be externally installed

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

#98

Post by db48x »

brandmeyer wrote: post #87
db48x wrote: post #46

Earlier quoted context omitted.

I’m not sure that’s a great example. mmap(2) is a swiss army knife of a function. There are many crates that build all kinds of things on top of mmap, and they’re not all interchangeable. Allocators, file io, gpio, actual virtual memory mappings. 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 st…

> With that perspective, I don’t think that 23 crates is terrifying. I’m going to look them all over and either pick one, or write the 24th crate myself. The result is the same either way. In a fine-grained ecosystem, the problem is transitive. You aren't just picking one from 20+ for each of your direct dependencies, you are also trusting that they in turn did just as much diligence as you did in picking their direc…

> In a fine-grained ecosystem, the problem is transitive.

Absolutely. You definitely have to own the whole stack. Ultimately, you may have to fix bugs at every level, from your own code all the way down to the OS. Big tech companies do this explicitly, with kernel development teams. Small companies do this by occasionally upgrading to the latest version of Ubuntu and hoping for the best.

> But in this case, a thin wrapper that reflects the system call's semantics ought to be available in a common `posix` crate that others may freely rely upon to build their higher-level services.

It is available. If you want to directly call any function in the C standard library, use the libc crate. Here’s the documentation: https://docs.rs/libc/0.2.109/libc/fn.mmap.html

All the other crates on crates.io that you find when you search for “mmap” are higher level abstractions over the raw syscall. They have specific purposes, like file io, or creating circular buffers.

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

#99

Post by db48x »

stouset wrote: post #94
db48x wrote: post #27

Earlier quoted context omitted.

He went down the wrong path, but at the same time Rust didn’t do anything to make async code easier to write. You just had to call libc::select and std::thread::spawn and whatnot, with all of the unsafe blocks that implies. These days there are about 47 different crates that can help you do it, all of them a lot nicer than that.

That's what I thought, but I just wanted to confirm. Thanks!

You’re welcome.

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

#100

Post by jrockway »

jhawk28 wrote: post #82
danudey wrote: post #57

Earlier quoted context omitted.

Specifically, Go was designed to be effectively and safely writeable and readable by mediocre programmers.

Mediocre programmers can still write bad Go code. Their code is neither safe or readable.

Don't take the obvious flamebait. HN's favorite comment on any Go article is "it's designed for bad programmers", implying that if you like it, you're bad at programming. I'm good at programming and like Go, so that implication is clearly false.
Post reply on HN