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

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

Post reply on HN
Print view View original

411–420 of 508 posts

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

#411

Post by 7532yahoogmail »

I'm c/c++ over 20 years, go 1 year, Python 5+ years. I work at a company with a guy on the c++ standards committee with the internal sdlc and engineering training for large scale, commercial systems to boot.

This article is a rant. Not an engineering take down of go. There's just not much of substance here. Were I to care about windows (I don't) for serious cross platform os interaction, go isn't your hammer of choice.

I've turned to go recently for some I/O heavy apps of a micro-service type which it is fine for. I also turned to go because of God awful c++ build times and bad build systems in the sense that they assume all code is in a single branch. By switching to go I also prevent less experienced programmers from linking in legacy c++ libraries and the evil that comes with them.

Go has delivered. My needs are such that protobuf/flatbuffer are good enough for types and go's lack of generics is irrelevant. I'm pushing bytes across a network pipe in which each message admits simple transforms/operations.

Now I am keeping my eye on three things that I think go could burn me on:

- garbage collection

- channels ... cool but slow

- something unixy/multicore/close to the bare metal ... Like kv store

Those things I'd be reticent about doing in go.

Folks, we need 2-4 languages with their connections to libraries and tool chains in our toolbox.

While we remain dominated by c++ (a complex beast of a language) I am looking to add a functional language to my kit (ocaml/Haskell). Btw good engineers need a formal language too. I recommend tla+ and there's a guy in hacker news here that's got good books on it. Recommended! Highly concurrent code ought to modeled in tla+ first before leaving your app language gun and taking the canolli.

Cheers

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

#412

Post by mntmoss »

scythe wrote: post #396
jerf wrote: post #44

Earlier quoted context omitted.

The problem is... and a lot of people aren't going to like this, including the original author... a lot of those particular gotchas are there for a reason. The author overestimates how much of them are intrinsic to the language, in my opinion. This is a cross-platform file interface, and we've had those for years. What we tend to discover is that if you do write something precisely correct on each platform, you lose…

>It's not the kind of library that Go wants as its standard library. It's a perfectly sensible sort of library. It just isn't what is desired in the standard library. "What is desirable in the standard library" is a very exclusive list. This sounds like a reasonable argument if your language is, say, Julia, or something like Lua, where in the first case you probably don't write code that needs to do a lot of work at…

Yes, and the FFI friction maps to my main concern with Go as it stands: it's a bit like Python in that it wants to be extended rather than embedded. That always creates a "hollowing out" of its core over time as users exceed the capacities of its standard library and try to push it into new environments. In contrast, Lua, for example, has a parasitic quality to it: make the host more powerful and then you can easily give Lua similar powers.

However, the other half of that is that in a lot of cases, the libraries are chosen, not the language. And then why would you choose the janky "worse is better" libraries? Well, there is a reason: at some level all your code is still a prototype or draft and the "real thing" is yet to come. And then Go looks rather successful on that front in that its primitivism works at the outset and ships a lot of software, which in turn creates the demand for the heavier "big-boy" solutions.

That's a thing I often don't see addressed in this kind of rant.

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

#413

Post by taylodl »

bshacklett wrote: post #378
taylodl wrote: post #358

Earlier quoted context omitted.

That's indicative of a serious attitude problem - I am so smart and can handle the power but you can't. Contrast this with C where everybody is on equal footing. Thanks for posting. This tells me everything I need to know to not get on Mr. Golang's Wild Ride.

Unfortunately that's becoming increasingly difficult with the amount of programs written in go that touch developers lives on a regular basis. Kubernetes, for example, is written in go. Want to fix a bug? You're now at least a part-time Gopher. I don't think we've seen the likes of this since PHP.

Kubernetes is always brought up when discussing Go. I wonder if Go might ultimately be its Achilles' heel? If so, I wonder how that might manifest itself?

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

#414

Post by 7532yahoogmail »

nwallin wrote: post #410
nonbirithm wrote: post #221

Earlier quoted context omitted.

Is there a language besides Rust that could be used instead as this example? As in, languages whose standard library was so carefully designed from previous experience that the design of features like Permissions/PermissionsExt and OsString deliberately take into account the design of both Windows and Unix-like internals. The author mentioned part of the reason the filesystem API is so awkward in Go is because Go was…

C++17's std::filesystem is awesome. One of the benefits of C++'s minimal standard library is that when something finally does get added 20 years after it's an established technology the OS primitives have already solidified. (threads and mutexes in C++11 for another example)

Best back handed compliment I've seen in a while ... And right too.

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

#415

Post by int_19h »

ajross wrote: post #387
int_19h wrote: post #373

Earlier quoted context omitted.

It is very much an engineering argument, because writing maintainable software requires respecting contracts. If an escape hatch is private, you can't depend on it, because code doing so will break when the hatch changes (and there's no guarantee that it won't).

The discussion is about Go-internal features, and whether or not dogfooding should be required. There's no contract being broken.

The whole point of OP is that many Go-internal features shouldn't be internal.

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

#416

Post by pdimitar »

dnr wrote: post #335
pmarreck wrote: post #302

Earlier quoted context omitted.

> If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. That's bullshit. When I worked in the Ruby on Rails space, I saw critisms quite often... for example of the "one size fits all" way-too-large-surface-area library design (see: ActiveSupport) or the "fat model" design trend at the time... I even PRODUCED some of these criticisms myself. Heck, the bug that…

I think you might be reading an unintended meaning into that sentence. I'm talking about the experience of using Go vs. what people write about it, not about your experiences with other languages (which I have no intention of invalidating). I was pointing out that sometimes one can get a skewed perspective of the typical experience by reading blog posts and things (which by definition are written by the more vocal me…

Well, you might have the Stockholm syndrome. :D But yeah, we all have to deal with some idiosyncrasies with our languages/tools of choice. It’s inevitable.

For the record, I really love Elixir but it’s quite easy to swallow/ignore errors there as well. (To translate one of the Go’s criticisms.)

So I get what you’re saying. But IMO the outsiders’ perspective is valuable because it outlines stuff we have gotten used to, and they might not be willing to do that.

So such criticisms might be minor for you and me but they add much-needed nuance in the long run, I believe.

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

#417

Post by pdimitar »

ClumsyPilot wrote: post #230
totalperspectiv wrote: post #210

Earlier quoted context omitted.

> And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior If you are being paid to develop software, doing anything other than aiming for absolute correctness seems negligent, at best. I think this is part of what leads to obsession with Rust. We build so many things on a daily basis with a long long list of 'it depends'. But Rust aims to make you write something as c…

You statement about absolute correctness doe snot really make sence -vast majorulity of bugs in all software I've ever used are not due to the language design, but are due to blatant mistakes of the application developers.

Well exactly. You and your parent's comment are in agreement: languages like Rust that give you less ways to shoot your foot, encourage writing a more correct code.

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

#418

Post by jonchang »

dralley wrote: post #353
WalterBright wrote: post #338

Earlier quoted context omitted.

Date & Time need to be baked into the operating system so it only has to be gotten right once, and then every programming system benefits.

So long as they actually get it "right". Compare to Windows' APIs originally taking UCS-2, then UTF-16, when now we would all rather be using UTF-8.

Note that UTF-8 hadn't actually been invented at the time UCS-2 was implemented in Windows: https://unascribed.com/b/2019-08-02-the-tragedy-of-ucs2.html

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

#419

Post by ajross »

int_19h wrote: post #415
ajross wrote: post #387

Earlier quoted context omitted.

The discussion is about Go-internal features, and whether or not dogfooding should be required. There's no contract being broken.

The whole point of OP is that many Go-internal features shouldn't be internal.

And my whole response is that that notion of "shouldn't" reflects an aesthetic or moral argument and not a technical one. How Go is implemented says nothing about whether Go is a good language or not.

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

#420

Post by amscanne »

kevingadd wrote: post #398
rob74 wrote: post #292

Earlier quoted context omitted.

I don't think this example justifies the expression "incredibly broken assumptions", I would rather call it an "incredible corner case"...

Making assumptions about the stack frame size of third-party code is incredibly broken. You have no way to make any guarantees about it and primitives like alloca mean you can't even be sure the stack size will be the same across multiple calls.

The VDSO isn’t really any third-party code. It’s very surprising for it to do a stack probe. Though obviously it’s possible, and falls on the runtime to handle (so it’s a legit bug).

But.. nearly every “runtime” makes stack assumptions. They usually just have enough slack that it doesn’t matter. E.g. musl has an 80k stack by default — is it still “incredibly broken” if the VDSO needs > 80k? No.

While the VDSO doesn’t have an explicit stack requirement, it’s definitely implicit that it will use a small, reasonable amount.

Post reply on HN