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

251–260 of 477 posts

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

#251

Post by nicoburns »

dimgl wrote: post #241

I liked the article. I think it was really well written and these are great points. So if not Go, then what's the alternative? I too am starting to feel a bit burnt out by some of Go's deficiencies, but one of the things I really like about Go is its concurrency model. What other languages have great concurrency models? Please keep in mind that I want to keep things simple... having a single binary to deploy is incre…

Rust is the obvious language to consider. It’s concurrency model is arguably better than go’s as it actually statically prevents you from misusing types that aren’t threadsafe.

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

#252

Post by Jyaif »

fasterthanlime wrote: post #191
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…

What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…

Can you see the value in being able to create software more quickly, at the expense of the software's stability?

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

#253

Post by dimgl »

nicoburns wrote: post #251
dimgl wrote: post #241

I liked the article. I think it was really well written and these are great points. So if not Go, then what's the alternative? I too am starting to feel a bit burnt out by some of Go's deficiencies, but one of the things I really like about Go is its concurrency model. What other languages have great concurrency models? Please keep in mind that I want to keep things simple... having a single binary to deploy is incre…

Rust is the obvious language to consider. It’s concurrency model is arguably better than go’s as it actually statically prevents you from misusing types that aren’t threadsafe.

To be frank I really don't want to deal with Rust's complexity.

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

#254

Post by mause_piep »

fasterthanlime wrote: post #191
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…

What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…

>> even seasoned Go developers, keep hitting its many design pitfalls

I'm a professional dev for 14 years. Started with Python, C# (WPF and ASP.NET), Qt, Java (Spring), Kotlin, Frontend with React, Angular, Vue, ... even Rust, so I've seen a lot.

Honestly, in the last 2 years using Go for backend services and some CLIs I never hit any of those design pitfalls you're writing about. Every language has it's quirks. Even Rust. But Go is not decisively better or worth than the other. For example, Kotlin is easier and more fun to write, but writing code is just a small part of a project. The whole spectrum needs to be considered. That's where Go shines.

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

#255

Post by innocentoldguy »

chernevik wrote: post #138
bb88 wrote: post #131

Earlier quoted context omitted.

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.

There are two things I've always wanted out of a comment system that allows up and down votes:

1. I want to know who upvoted/downvoted/flagged a comment so I can identify attempts at censorship, revenge voting/flagging, etc.

2. I want the ability to exclude individuals from the upvote/downvote tally I see.

For example, if I see someone downvoting every post that is favorable to Elmer Fudd, or upvoting every post that is favorable to Bugs Bunny, I want to block that person's emotional bias from the rankings I see in order for my view of the comment section to be as objective as possible.

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

#256

Post by throwaway894345 »

lamontcg wrote: post #243
throwaway894345 wrote: post #224

Earlier quoted context omitted.

> You just did prove my point though which is that this is the only argument that Go programmers consider, and they blindly reject that adding more lines of code can harm readability. Can we lower the rhetorical temperature a notch? Just because someone disagrees with you doesn't mean they're "blindly rejecting" your reasoning. In particular, I'm not just a Go programmer--I've used Java, C#, Python, JS, C++, and C in…

I was never arguing for "minified" code, which is ridiculous. Lower your own rhetorical temperature.

I don't know how you interpreted "minified" in any disparaging way, but that was never my intent. I apologize for any emotion that stirred up.

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

#257

Post by 0xdeadb00f »

mcronce wrote: post #38
0xdeadb00f wrote: post #27

To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of…

"Bubbling up" is common parlance for "exit this function early and return the error we got from our callee" (or "wrap the error we got from our callee and return that") In Go, this looks like thing, err := call() if err != nil { return nil, er } In Rust, this looks like let thing = call()?;

People keep telling me this is common nomenclature but I have never heard of it until today.

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

#258

Post by 0xdeadb00f »

dralley wrote: post #40
0xdeadb00f wrote: post #27

To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of…

>"bubbling up"? What the fuck even is that? When you throw an error and don't catch it, you just let the error immediately propagate up to the calling function. Think "return err" >> Either by panicking on error, with .unwrap() or .expect() This means fatally terminating the program immediately when an error is encountered in this spot. >> or by matching it against Result::Ok / Result::Err Result is an enum can be on…

Thanks. The point of my comment was not to actually ask someone to explain it to me, but again, thank you for explaining it, I appreciate it.

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

#259

Post by mananaysiempre »

ThatGeoGuy wrote: post #250
b3morales wrote: post #176

Earlier quoted context omitted.

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.

This is correct (in that the most simplistic case is try-catch). However, the difference between a try-catch and conditions / restarts is that when one signals a condition (exception), the restart (catch) has a continuation from the condition. This allows you to inject an expression into the location where an exception occurred and "restart" your code from that point. Whether you do such a thing or not depends on the…

> Going farther than this, conditions and restarts are really just a fancy way of packaging delimited continuations. I don't personally know any non-Lisp language that has attempted to package these concepts (maybe Dylan, which is a Lisp-like in its own way but without the syntax?).

Dylan does have a condition system, but it’s basically a Lisp without the parens, so probably doesn’t count. On the other hand, algebraic effects are another fancy way of packaging delimited continuations, so arguably the research languages Eff[1] and Koka[2] tried. (I don’t think either one explored the connection with condition systems, but I’m not sure.)

> I think Result type handling is fine and that most languages would be better served by that than having different types of exceptions. Conditions and restarts are powerful but your language has to be very expression focused (i.e. does not use a lot of statements) [...]

Huh? I don’t know why you’d say that, if anything I think it’s the Either err t / Result style that is more expression-focused (I mean, it even originates in Haskell :). I wouldn’t even call Common Lisp particularly expression-oriented, honestly, not unless we’re comparing with plain old C and not Rust.

[1] https://www.eff-lang.org/

[2] https://koka-lang.github.io/

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

#260

Post by Fritsdehacker »

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…

I think describing this article as a one sided rant isn't really fair. The author shows that Go makes a few design decisions that make it easy to shoot yourself in the foot. This is generally a bad idea. Rust may be the summum of correctness. In my view that makes it an ideal candidate for comparison. It shows the reader what a better solution would look like. And that this can work in practice. Does that mean you shouldn't write code in Go? No of course not. But I think the author has done a great job of showing why they don't want to use Go anymore.
Post reply on HN