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

131–140 of 477 posts

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

#131

Post by bb88 »

recuter wrote: post #118
chernevik wrote: post #54

Earlier quoted context omitted.

Off-topic, but HN needs review of flagging abuse. Maybe assign flagging privileges only to those with X reputation, and revocation if on review the privilege is abused? It seems that flagging is as much "I don't like this" as "this is not appropriate". Likewise downvoting. Maybe instead display both downvotes and upvotes, so people can see if a comment is found controversial?

Lately I've had comments swing wildly dozens of points in each direction and also flagged. Brigadiering has come to HN and is getting worse over time. There seems to be a growing segment of internet users who wish to cleanse perceived wrong think, it is disturbing and not what flags/downvotes are for. It also feels like there is more bots.

Go look at HCQ/Ivermectin/Cryptocurrency for examples of such brigadiering.

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

#132

Post by mseepgood »

fb03 wrote: post #120
fasterthanlime wrote: post #64

Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip some…

Don't fall prey to an ad-hominem argument - I don't think your article negatively hints at any kind of 'this is a Rust fanboy-made praise text' and it saddens me that a genuinely legit article like this needs to have the author defend himself like this. Your points were well explained. Go has several serious warts which, in my own opinion, are showstoppers, and you are comparing it to a language which is somewhat new…

> Rust has its warts as well and the language spec is already starting to become somewhat... large

It doesn't have a spec, so we don't know how gigantic it would be.

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

#133

Post by gmfawcett »

AnimalMuppet wrote: post #127
reedjosh wrote: post #122

Earlier quoted context omitted.

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be th…

If the skill difference among your devs is really high, it may be preferable to have the best programmer leave, or at least change roles (architect, team lead, trainer), as this may increase productivity of the median workers. At least the skill difference should be treated as a risk and properly mitigated.

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

#134

Post by jdc0589 »

baby wrote: post #39

Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other han…

this is a bit part of it for me. Most of the tools you need for average development, triage, perf analysis, etc... are included out of the box.

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

#135

Post by 0xbadcafebee »

I miss Perl. It has everything I like in a language. Mystic runes that do really complex things with just 1 extra character of code. Switch between procedural, OO, and functional programming anywhere. Rewrite the language itself if you feel like it. C/ASM extensions for speed. Reusable, inheritable, extendable modules rather than quirkily-named modules that nobody can build on top of. Extremely thorough warnings, errors, debugging, and documentation. Hybrid and duck typing. First-class regex support. One-liner conveniences.

But an entire generation never really learned the language, and subsequently churned out dog vomit that looked like Perl syntax, so the whole language became a pariah. But I have at least 10x the productivity with Perl compared to any other language.

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

#136

Post by throwaway894345 »

zozbot234 wrote: post #99
mcronce wrote: post #90

Earlier quoted context omitted.

> Go is a language that gets out of your way, encourages you to solve your problem Maybe I'm just too dumb for Go, but this is not consistent with my experience at all. Go's insistence on pretending that complexity doesn't exist would get in my way all the time. Go's extreme hostility toward FFI calls got in my way several times.

> 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 build on another machine (in the case of build-time dependencies) or that it may run on one machine but not another (in the case of run-time dependencies). It's also opaque to the host build system, so cross compilation becomes dramatically more difficult. Lastly, C is inherently unsafe and insecure in ways that most host languages are not.

In practice, whether by accident or design, the Go ecosystem is really, really nice because it avoids FFI to a high degree. An overwhelming majority of programs can be cross compiled into a truly static binary (it may not even depend on libc unless--as is the case with Windows and MacOS--the host platform requires it). It also means that there are very few "C-shaped libraries", by which I mean thin bindings around some C library which exposes idiomatic C semantics rather than idiomatic Go semantics. Moreover, your programs aren't running a bunch of inherently unsafe code under the hood, and are consequently more likely to be secure as a result.

It's kind of nice that C FFI is possible such that libraries which are unlikely to be ported to Go (e.g., ffmpeg) or which cannot be ported to Go (e.g., opengl) are still available, but not so easy that people pull in C libraries for every little convenience.

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

#137

Post by throwaway894345 »

mcronce wrote: post #102
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…

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

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

#138

Post by chernevik »

bb88 wrote: post #131
recuter wrote: post #118

Earlier quoted context omitted.

Lately I've had comments swing wildly dozens of points in each direction and also flagged. Brigadiering has come to HN and is getting worse over time. There seems to be a growing segment of internet users who wish to cleanse perceived wrong think, it is disturbing and not what flags/downvotes are for. It also feels like there is more bots.

Go look at HCQ/Ivermectin/Cryptocurrency for examples of such brigadiering.

The trouble is, you can't -- only the commenter can see their score swings, and then only if they pay attention.

Publishing upvotes and downvotes would allow others to see these effects, and would allow them to register a comment as "controversial" rather than "not worthy of notice".

Data on who made what vote could also be useful.

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

#139

Post by jen20 »

zozbot234 wrote: post #99
mcronce wrote: post #90

Earlier quoted context omitted.

> Go is a language that gets out of your way, encourages you to solve your problem Maybe I'm just too dumb for Go, but this is not consistent with my experience at all. Go's insistence on pretending that complexity doesn't exist would get in my way all the time. Go's extreme hostility toward FFI calls got in my way several times.

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

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

#140

Post by mjr00 »

jhoechtl wrote: post #73
mjr00 wrote: post #63

Earlier quoted context omitted.

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

Well put and I agree with most points but > Go is not a fun language to program in Not having to think about how something should be done in the most elegant way, instead focus on the problem at hand is a lot of "fun"

True, fun is certainly different for everyone! I also enjoy being able to just focus on a real world problem, but I also programmed Scala professionally for many years, and I found it a lot more fun purely from the point of view of writing code. Writing a really elegant for comprehension or using currying in clever ways to make your code "elegant" was just enjoyable in and of itself, regardless of what problem you were actually trying to solve. Rust is pretty similar to me in that regard.
Post reply on HN