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

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

fasterthanli.me

Post reply on HN
Print view View original

171–180 of 477 posts

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

#171

Post by throwaway894345 »

zozbot234 wrote: post #151
jen20 wrote: post #139

Earlier quoted context omitted.

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

What do you mean "a separate implementation"? CGo is part of Go, it's not another implementation of Go.

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

#172

Post by weatherlite »

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…

> Go is a language that gets out of your way, encourages you to solve your problem

Haven't experienced this yet but I'm a Go noob. I think everything looks easy when you mastered it, I don't think Go is so much easier than JS/Python or even C. Might be easier than Java but Java has so much more community support (e.g Stackoverflow answers) it easily evens out.

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

#173

Post by sfvisser »

Mawr wrote: post #125

The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only m…

The author clearly does understand language design. He probably even agrees with your description of go above, but simply describes it really doesn’t work for him.

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

#174

Post by asherah »

jhoechtl wrote: post #82
nmilo wrote: post #72

Earlier quoted context omitted.

Rust's approach is definitely safer, but my point is that the concerns are overblown. The Go compiler raise an error if a variable (error) goes unused, and just ignoring this error by naming it "_" is obviously dangerous. Yes, Rust makes it easier to never ignore an error, but I don't think I've ever accidentally ignored an error that I shouldn't have in Go.

Golang gives you freedom. Rust gives you seat belts. It depends on you what you value more.

would highly prefer my car to have seatbelts over "simplicity" and "freedom" if i plan to go over 30mph with it

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

#175

Post by jrockway »

erik_seaberg wrote: post #119
rad_gruchalski wrote: post #15

Earlier quoted context omitted.

So they wanted out in 2020 and they’re still on in 2022. So either the language isn’t really that bad or they have an attention deficit?

In https://news.ycombinator.com/item?id=31193260 the author clarified that he’s changed jobs twice yet “It doesn't matter that I don't personally write Go anymore: it's unescapable.” I’m also worried about this because of trends at my day job despite having joined a sharp, experienced Scala/Java team.

I'm someone who wants to write Go 100% of the time at work, and I haven't really found a lot of companies that are doing this. All the cool kids have moved on to Rust. All the legacy code is Python/Ruby/Typescript. There is the niche in the k8s ecosystem, but I've already written all the code I need to integrate with the k8s ecosystem ;) All that's left to do are write 2000 copy-pasted operators for running super legacy apps on OpenShift, it feels like.

But even with that in mind, it's not that hard to find. Whatever tech stack you like, there is a company in every industry hiring software engineers to work with that set of tools. There is just so much software in the world, it's strictly a numbers game. And if there's some industry you like that doesn't have the tech stack you want, why not start your own company? You're reading "startup news" after all ;)

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

#176

Post by b3morales »

the_common_man wrote: post #121
throw10920 wrote: post #104

Earlier quoted context omitted.

Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations. For everything else, conditions+restarts are the correct answer, because errors-as-values restricts you to a single error-handling strategy and couples high-level code to low-level code as a result.

> Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations Not really. It is acceptable for code whose maintainers value readability and simplicity over everything else. I totally agree that readability and simplicity are quite subjective and this is up to the maintainers. I don't really know what "conditions+restarts" is but a few a…

It's probably sufficient for this conversation to just understand it as try-catch. A function is invoked; if it "signals" (throws) then control moves to a handler that matches the signal (exception); the handler runs and resolves the situation. Of course, Lisp being Lisp, the system is extended to announcer voice FULL. GENERALITY. but in its simplest form it's basically equivalent to exception throwing.

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

#177

Post by geodel »

snotrockets wrote: post #126
jitl wrote: post #65

Earlier quoted context omitted.

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

What I wonder, is if by designing a language to enable happy corporates, rather than happy programers, is Go not shooting itself in the foot, as the now less happy programmers (because corp mandated Go) would move to other corps, creating more cost to the corporate than if they had use a more joy-inducing language. IOW, Go is probably great if you're quite big. But like most Google created dev tools, the questions we…

I have asked to myself and answer seems yes. I wrote a tool many years ago in Go. It has saved me at least 100 times the hours I put in to code it. And I put in couple of weeks at max. The point here is I created a tool (my application) using another tool (Go) and I care quite a bit more about my tool, features, usability and so on. Programing language provided few features like single binary so I can install on VMs, desktop and not downloading whole internet to build that project. Its been working fine for half a decade or so.

So it does its job and saved time is spent somewhere else like reading interesting books, cooking or watching documentaries etc.

I can understand people who sweat on perfect error handling, sum type and what not will be eternally unhappy with Go. Hopefully they find whatever suits their taste, considering we are in a new PL boom nowadays.

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

#178

Post by throwaway894345 »

mcronce wrote: post #152
throwaway894345 wrote: post #137

Earlier quoted context omitted.

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 o…

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

I wouldn't know. I've never run into an issue where Go's performance was a real bottleneck, and anyway every mainstream language with easy FFI still has significant FFI overhead (so much so that many programs actually run slower with FFI). This isn't really true for Rust (Rust makes it easy to define types which are essentially C structs and thus require little/no marshaling), but performance also isn't the reason you FFI out of Rust.

> As with many things, there's nothing stopping you from just sticking with pure Go if you don't like C toolchains.

Right, that's my point. You viably can stick with pure Go because such a large share of the Go ecosystem is pure because FFI is rarely worth the hassle.

> 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

Try building a significant Python project on anything except a recent version of RHEL, Debian, MacOS, or Windows. For example, try getting your Python project running on something like a scratch Docker container. Or try packaging a Python package (which depends even transitively on a C library, especially one which isn't already packaged for Nix) with Nix.

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

#179

Post by steveklabnik »

throwaway894345 wrote: post #162
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.

Unless something has changed in the relatively recent past, I think you're overselling a fair bit. Not only does the package author have to understand the C dependency well enough to package it correctly on all platforms (basically by verifying the build in a hermetically sealed environment, and who is doing that?), but also the process for cross compiling is (or at least was) pretty complicated: https://www.modio.se…

> (basically by verifying the build in a hermetically sealed environment, and who is doing that?)

Lots of people run stuff in CI, which isn't exactly that, but is close enough to make it not as big of a pain as it might otherwise be.

It can also help if their docs aren't great; I've looked at CI configs to realize how to install some sort of system dependency before.

> but also the process for cross compiling is (or at least was) pretty complicated

Most of this article is talking about installing and setting up both Docker and a C cross-compiled toolchain. So, you're right, but also not, sorta kinda. That is, this is certainly more hard than Go, but we're not talking about pure Rust at this point, so the fair comparison would be cgo with some C dependencies, which would also involve setting up a C cross-build toolchain, (and maybe docker). But at the same time, it doesn't have to be this way: Zig includes a full C cross toolchain in its compiler, so that you don't have to do this installation. It is, in my opinion, currently best-in-class here, far surpassing both Go and Rust.

It is also worth nothing that, IIRC, Go had to switch to dynamically linking libc on many platforms, since the idea of a "fully statically linked binary" is basically only coherent on Linux.

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

#180

Post by ripley12 »

klodolph wrote: post #84

Yes, the cross-platform stuff sucks on Windows. I’ve seen languages with a few different approaches, I’d like a moment to compare them here. I’m going to talk about some specific aspects of cross-platform compatibility but not attempt to compare one single aspect across many platforms. With C++, you can use the preprocessor to give you a string type which is UTF-8 (nominally) when compiled on Unix and UTF-16 (nominal…

> You can take a look at System.Diagnostics.Process for one of the worst offenders.

Yeah, this is one of my least favourite APIs in all of .NET. My understanding is that the .NET team is planning to redo it in the next few years, but if you want something better right now I highly recommend the excellent CliWrap library: https://github.com/Tyrrrz/CliWrap

Post reply on HN