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

I Want Off Mr. Golang's Wild Ride (2022)

fasterthanli.me

Post reply on HN
Print view View original

21–30 of 41 posts

Re: I Want Off Mr. Golang's Wild Ride (2022)

#21

Post by Joker_vD »

afavour wrote: post #12
gnfargbl wrote: post #4

I have created and maintain a 130k SLOC Go codebase over the last four years or so, and there are a number of things about Go that irritate the shit out of me. I still get bitten by taking the address of a loop temporary on a surprising basis, for example, even though I am acutely aware of the issue. Or, I haven't really found any use for generics yet, because (as best I can tell) it's impossible to specialise and pr…

> seems to be an extended complaint that Go isn't as portable between Linux and Windows as the author would like it to be I don't think that's true. The author is using that lack of portability as an example of what they think is wrong with Go: > And they're symptomatic of the problems with "the Go way" in general. The Go way is to half-ass things. > The Go way is to patch things up until they sorta kinda work, in th…

> The issue isn't that file permissions don't work consistently cross-platform in Go, it's that they can't work consistently cross-platform in anything but rather than add complexity Go has papered over the cracks.

Interestingly enough, C of all languages had enough sense to not require permissions as an argument for fopen(3).

Re: I Want Off Mr. Golang's Wild Ride (2022)

#22

Post by tikhonj »

frodowtf wrote: post #17
tikhonj wrote: post #9

The April 2022 update at the end of the article has a good short summary: > If you're looking to reduce the whole discourse to "X vs Y", let it be "serde vs crossing your fingers and hoping user input is well-formed". It is one of the better reductions of the problem: it really is "specifying behavior that should be allowed (and rejecting everything else)" vs "manually checking that everything is fine in a thousand t…

I don't see how creating abstractions reduces the cognitive load. You create new concepts before you even need them + once you notice that the abstraction was wrong, now it's much harder to reverse.

Abstractions reduce cognitive load because they let us consolidate multiple bits of information into a single concept.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#23

Post by CoastalCoder »

boarnoah wrote: post #10

Doesn't rust suffer from the same, way too wide dependency web? I feel like its an unfortunate consequence of having a good package manager which encourages proliferation of too many very small dependencies.

I'm new to Rust, and I noticed this just the other day.

I was playing with some Rust-based blockchain system, and the number of external dependencies pulled in (recursively) to build the code truly amazed me.

I don't really know, but I'm guessing that a similar C++ project would have required many fewer dependencies.

Maybe a C++ code base would tend rely on a small number of big libraries?

Or maybe a C++ code base would (for some reason) be more inclined to use binary libraries provided by already-installed Debian packages?

Re: I Want Off Mr. Golang's Wild Ride (2022)

#24

Post by tikhonj »

Agingcoder wrote: post #20
tikhonj wrote: post #9

The April 2022 update at the end of the article has a good short summary: > If you're looking to reduce the whole discourse to "X vs Y", let it be "serde vs crossing your fingers and hoping user input is well-formed". It is one of the better reductions of the problem: it really is "specifying behavior that should be allowed (and rejecting everything else)" vs "manually checking that everything is fine in a thousand t…

This is interesting. I think though that the first option eventually leaks though, and that (unfortunately) you will have to spend time debugging things, sometimes at great cost for really sophisticated abstractions. The tradeoff, and the tipping point are clearly not obvious though!

You can't get away from some debugging, but I've certainly seen massive differences in how much debugging I've had to do between different codebases!

Re: I Want Off Mr. Golang's Wild Ride (2022)

#25

Post by nvy »

Meta: does flagging and vouching work differently for links than for comments?

This account has enough karma for flagging, and I can see the title of this submission is prefixed with [Flagged] but I don't have an option to Vouch.

How does that work? I flag/vouch pretty rarely so I'm not always sure.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#26

Post by no_wizard »

winstonprivacy wrote: post #14

Ah, Go. I wrote a whole networking stack in it a few years back. I admit, I did get an incredible amount of performance from a very limited bit of hardware with it. However, it was dependency and module hell. Even the Go expert couldn't get it figured out enough to make it compile every time. I'm really glad I got off that ride.

I wonder if proper vendor support helps with this or not, its relatively recent to Go

Re: I Want Off Mr. Golang's Wild Ride (2022)

#27

Post by jsnell »

nvy wrote: post #25

Meta: does flagging and vouching work differently for links than for comments? This account has enough karma for flagging, and I can see the title of this submission is prefixed with [Flagged] but I don't have an option to Vouch. How does that work? I flag/vouch pretty rarely so I'm not always sure.

I think vouch not appearing might be a bug when somebody flags + unflags (I accidentally flagged, then unflagged, and it didn't revert the "flagged" state. Not showing vouch could be related). I've emailed dang.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#28

Post by Night_Thastus »

The more I read about Rust, the more I've come to respect it. I still think:

* It's a specialized tool not suitable for all (or even most) projects

* It needs a bit more time to both develop as a language and ecosystem

But it's clear that it's not half-assed and a lot of thought went into it.

Interesting to hear about Go's development as well. It was starting to pick up when I was in college, and now it's had a few more years. Bit disappointing to see it's so messy.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#29

Post by moojd »

layer8 wrote: post #13
boarnoah wrote: post #10

Doesn't rust suffer from the same, way too wide dependency web? I feel like its an unfortunate consequence of having a good package manager which encourages proliferation of too many very small dependencies.

This doesn’t need to be the case. It didn’t happen with Perl (CPAN) and Java (Maven), for example.

Do those allow multiple versions of the same dependency? With npm and cargo (as opposed to composer, etc.) you are never forced to resolve those types of conflicts so you can just keep installing dependencies forever without ever having to trim the tree.

Re: I Want Off Mr. Golang's Wild Ride (2022)

#30

Post by Night_Thastus »

CoastalCoder wrote: post #23
boarnoah wrote: post #10

Doesn't rust suffer from the same, way too wide dependency web? I feel like its an unfortunate consequence of having a good package manager which encourages proliferation of too many very small dependencies.

I'm new to Rust, and I noticed this just the other day. I was playing with some Rust-based blockchain system, and the number of external dependencies pulled in (recursively) to build the code truly amazed me. I don't really know, but I'm guessing that a similar C++ project would have required many fewer dependencies. Maybe a C++ code base would tend rely on a small number of big libraries? Or maybe a C++ code base wo…

As a C++ dev, I generally see few but often large dependencies. Boost used to be a large one, but it's less relevant these days with C++11 and onward. There are others like QT, Eigen, GoogleTest, FFMpeg, Intel's OneAPI, etc.

Sometimes I see single-header libraries you can just drop in, other times I see large Cmake projects that you add as a dependency to compile when your project compiles.

I've never seen the kind of dependency chaining that languages like JS or Go show.

Post reply on HN