I want off Mr. Golang’s Wild Ride (2020) • Hacker News Board

Re: I want off Mr. Golang’s Wild Ride (2020)

#151

Post by zozbot234 » Thu, Apr 28, 2022, 4:29 PM UTC

jen20 wrote: post #139

zozbot234 wrote: post #99

Earlier quoted context omitted.

> Go's inane hostility toward FFI calls got in my way several times. All languages w/ obligate GC are "hostile" to FFI in some way or another. The Go default implementation also uses split stacks or something for its goroutines, that cannot feasibly interop with FFI code. But it's usually easy enough to just isolate Go code to it's own process/address space and use IPC or network communication to enable the interop o…

> The Go default implementation also uses split stacks or something for its goroutines This has not been true since Go 1.2, back in late 2013.

The fact remains that you need a separate implementation (cgo) if you want to do FFI. It might be something else goroutine-related that blocks FFI in the default Go implementation, but the issue is still there either way.

Re: I want off Mr. Golang’s Wild Ride (2020)

#152

Post by mcronce » Thu, Apr 28, 2022, 4:31 PM UTC

throwaway894345 wrote: post #137

mcronce wrote: post #102

Earlier quoted context omitted.

Serializing a request structure, making an IPC/network call, deserializing the request structure, serializing the response structure, sending it back, and deserializing it ... isn't really a solution when the purpose of an FFI call is typically to fix some performance issue. Lots of garbage-collected languages make FFI not only easy but plenty fast. Go does neither.

I started out thinking that fast and easy FFI was ideal and being disappointed that Go's FFI was neither. I've since changed my opinion as it's really nice that one can usually get away without pulling any C dependencies into their dependency tree. I wrote more in the sibling comment: https://news.ycombinator.com/item?id=31194347

That would be great if Go provided better performance. With its awful FFI, you have no recourse when you hit its limits other than to rewrite the entire codebase in something else.

As with many things, there's nothing stopping you from just sticking with pure Go if you don't like C toolchains. While C build issues are a valid theoretical concern, in practice I've never had any Python package fail to install because of a C dependency problem that wasn't trivially resolved, nor any Rust project fail to compile because of a C dependency problem at all.

Re: I want off Mr. Golang’s Wild Ride (2020)

#153

Post by nicoburns » Thu, Apr 28, 2022, 4:32 PM UTC

throwaway894345 wrote: post #136

zozbot234 wrote: post #99

Earlier quoted context omitted.

> Go's inane hostility toward FFI calls got in my way several times. All languages w/ obligate GC are "hostile" to FFI in some way or another. The Go default implementation also uses split stacks or something for its goroutines, that cannot feasibly interop with FFI code. But it's usually easy enough to just isolate Go code to it's own process/address space and use IPC or network communication to enable the interop o…

Inversely, virtually all languages with "easy FFI" end up being even more hostile in that a significant chunk of the ecosystem depends on C build tooling which is almost always fragile: C build systems have implicit dependency management, so you don't know what dependencies you need to have installed on your system or where they need to be installed. This means that something which builds on one machine may fail to b…

The Rust ecosystem does one better and packages the C libraries and build configuration (including making it portable across platforms) as part of the crate. So you just add the dependency to your Cargo.toml and the C library will build as part of the regular `cargo build` process.

Re: I want off Mr. Golang’s Wild Ride (2020)

#154

Post by throwaway894345 » Thu, Apr 28, 2022, 4:32 PM UTC

reedjosh wrote: post #110

throwaway894345 wrote: post #77

Earlier quoted context omitted.

Agreed. This was the only nit I was inclined to pick as well. I have a lot of fun writing Go, because it gets out of my way .

I just can't stand taking three lines to unpack a value from a map or to return if error. Why can't I just say `return if err := somefunc(); err != nil` It's mega frustrating on top of the lack of generics and other abstractions. And now that generics are coming about, I'm sure it will take forever until my current project can use them. My current project is in the k8s ecosystem which due to the lack of generics, imp…

I can't relate. Newline characters have never been burdensome to me, and they aid in visual structure (the control flow is represented by the visual structure of the program, not only for "good data" paths, but also for error paths). My programming problems are usually not related to localized keystroke boilerplate, but rather larger issues of abstraction and data modeling.

> My current project is in the k8s ecosystem which due to the lack of generics, implemented its own clever but awful type system.

The k8s ecosystem's type system is unrelated to generics. It has a concept of user-defined resource types, which means that users can provide an OpenAPI document describing their resource type which Kubernetes will then use to validate new user-provided resources of a given type. From the perspective of the Go compiler, these types are dynamic types--they can't be known at compile time. They aren't a candidate for generics in the host language.

That said, it's often tedious to write a controller for these resource types, but that's because Kubernetes' controller frameworks are really complicated. They remind me of enterprise Java code with gratuitous abstraction. Maybe that abstraction serves some purpose, but it wasn't helping me and I ended up rewriting much of it in more standard Go (I didn't release it because it was prototype code and I didn't want to support it) and it was quite a lot simpler. I don't recall seeing many places where I felt that generics would be a significant improvement, but it's been a while.

Re: I want off Mr. Golang’s Wild Ride (2020)

#155

Post by mcronce » Thu, Apr 28, 2022, 4:34 PM UTC

nicoburns wrote: post #153

throwaway894345 wrote: post #136

Earlier quoted context omitted.

Inversely, virtually all languages with "easy FFI" end up being even more hostile in that a significant chunk of the ecosystem depends on C build tooling which is almost always fragile: C build systems have implicit dependency management, so you don't know what dependencies you need to have installed on your system or where they need to be installed. This means that something which builds on one machine may fail to b…

The Rust ecosystem does one better and packages the C libraries and build configuration (including making it portable across platforms) as part of the crate. So you just add the dependency to your Cargo.toml and the C library will build as part of the regular `cargo build` process.

And as a bonus, be statically linked with all the benefits that brings.

Re: I want off Mr. Golang’s Wild Ride (2020)

#156

Post by throwaway894345 » Thu, Apr 28, 2022, 4:35 PM UTC

afdbcreid wrote: post #97

throwaway894345 wrote: post #77

Earlier quoted context omitted.

Agreed. This was the only nit I was inclined to pick as well. I have a lot of fun writing Go, because it gets out of my way .

But programming languages should get on your way while you're doing things wrong . Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity".

> But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity".

Go typically does get in your way when you're doing things wrong, but yes, I'd like to see Go require return values be dealt with or explicitly ignored. That said, there are linters for this, but in practice it's never been a material problem for me so I haven't bothered to wire one into my project. Over time, I've learned not to be so concerned about issues which are mostly just theoretical--there are enough practical problems to deal with first.

Re: I want off Mr. Golang’s Wild Ride (2020)

#157

Post by vrnvu » Thu, Apr 28, 2022, 4:38 PM UTC

mjr00 wrote: post #63

throwaway894345 wrote: post #37

Earlier quoted context omitted.

I mean, all programming language communities are partial to their language, but among Go there seems to be an unusual tolerance for disagreement and discussion of language issues compared to most other programming languages. But yeah, when you come in guns blazing talking about how certain language features are "shit" and there's no possibility of elegance, people are rightly going to think you're not there for any s…

> Note that there definitely are PL communities that generally can't handle any criticism irrespective of civility, but the Go community isn't among them. Indeed, in my experience, Go's critics are very often much more zealous than its proponents. This is because Go is a programming language for people who don't care about programming languages. I mean this in the most positive way possible. If you're using Go, it's…

I've done pet projects in Haskell, Ocaml, Racket, Rust... Now I'm learning Zig... I've worked for years with Java, Python, Javascript/Typescript... Use to work with Z3... Tried plenty of different stuff.

After years my conclusion is that If I want to get a job done I'll choose Golang. Hands down the best productivity programming language nowadays. GC for memory management and productivity, explicit, easy to read, hard to mess up, good performance and efficiency. Get' the job done and really well. End.

I love PL theory. Reading an Idris book an implementing some cool recursive patterns. Building a small project in different languages and compare them... Compilers, type systems and GC papers... But in my experience, the more complexity and "implicitness" a language has to offer, the easier is for "us" to go the wrong way.

Re: I want off Mr. Golang’s Wild Ride (2020)

#158

Post by steveklabnik » Thu, Apr 28, 2022, 4:40 PM UTC

nicoburns wrote: post #153

throwaway894345 wrote: post #136

Earlier quoted context omitted.

Inversely, virtually all languages with "easy FFI" end up being even more hostile in that a significant chunk of the ecosystem depends on C build tooling which is almost always fragile: C build systems have implicit dependency management, so you don't know what dependencies you need to have installed on your system or where they need to be installed. This means that something which builds on one machine may fail to b…

The Rust ecosystem does one better and packages the C libraries and build configuration (including making it portable across platforms) as part of the crate. So you just add the dependency to your Cargo.toml and the C library will build as part of the regular `cargo build` process.

While this is true in many cases, it’s worth pointing out that that is the choice of the package author, and is not always super simple to implement. So yeah, much of the time it is nice, but you’ll sometimes also run into these classic sorts of issues, either because the authors do not put in that work or because there’s a bug in the implementation.

Re: I want off Mr. Golang’s Wild Ride (2020)

#159

Post by throwaway894345 » Thu, Apr 28, 2022, 4:42 PM UTC

mcronce wrote: post #155

nicoburns wrote: post #153

Earlier quoted context omitted.

The Rust ecosystem does one better and packages the C libraries and build configuration (including making it portable across platforms) as part of the crate. So you just add the dependency to your Cargo.toml and the C library will build as part of the regular `cargo build` process.

And as a bonus, be statically linked with all the benefits that brings.

I recall statically compiling Rust to be a big pain (like, actually statically compiling, no dynamic dependencies on libc in Linux). I assume this is all the more true with arbitrary C dependencies?

Re: I want off Mr. Golang’s Wild Ride (2020)

#160

Post by lakomen » Thu, Apr 28, 2022, 4:44 PM UTC

burnished wrote: post #57

throwaway894345 wrote: post #37

Earlier quoted context omitted.

I mean, all programming language communities are partial to their language, but among Go there seems to be an unusual tolerance for disagreement and discussion of language issues compared to most other programming languages. But yeah, when you come in guns blazing talking about how certain language features are "shit" and there's no possibility of elegance, people are rightly going to think you're not there for any s…

Huh, I had sort of found the opposite, that the Go community I had interacted with was more aggro and prone to offense. I'm forming this opinion from the reddit and the discord though, so if there is another community you favor I'd genuinely love to hear about it.

I concur. I was used to a professional tone, then joined discord-go. Showed some of my online code to receive a "shit structure" response by some anime girl avatar youngling. When I started explaining how I don't think docker is the way to go I was met with passive aggressive behavior and plain false responses trying to justify its use. But Go's discord server wasn't to only bad experience. Angular might as well have been called Heil Angular. I worked with it for 2 years and found vue to be more productive. But they didn't want to hear cross worlds experience. Instead they insisted that I had no clue and after a while of back n forth played the "we're the moderators so we're right" card. Then big daddy server owner later stepped up and in the end I was banned, because despite the truth that vue was more productive only their agenda mattered. I have also met hostility in discord's vue server. Insults by by an official name there for saying that it wasn't a good move to require me or anyone joining to provide a phone number for account verification purposes.

All in all discord seem to have the immature unprofessional crowd. It's a gaming chat system after all.

Reddit Go is not as hostile but not very informed either. Although that's not true for all participants.

Compare Reddit to the quality of Go nuts, there is a difference.

But at least Reddit is a more or less open forum, where discord is hidden and a walled pff property.