Live data from Hacker News

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

fasterthanli.me

401–410 of 477 posts

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

#401
post #105

Earlier quoted context omitted.

"there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data." In theory, this is a big deal. In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it. A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another fu…

> A lot of error handling procedures are based on reacting to C, which was awful Go's design decisions in general make a lot more sense from this perspective. "X was horrible to deal with in C, how can we make a (reactively) better version?" The problem is a lot of these choices (willfully?) ignore the decades of language innovation that have happened since C. They are incremental, reactive improvements, where it doe…

> it doesn't feel like the designers necessarily stepped back and looked at the bigger picture

I get the sense that the designers have a huge amount of ego from making C what it is today.

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

#402

Earlier quoted context omitted.

I think it's a matter of different goals. What you describe is pains of a very senior developer who has worked on a lot of very subtle bugs and never questioned their desire to deliver the best software possible. Parent comment, however, talks about a situation where you have to hire dozens (if not hundreds) of $10/hour developers to ship software that is just good enough. I mean folks who may be great people and des…

I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers. If Go makes it easier for bad programmers to write decent code, it also makes it easier for good programmers. Good programmers aren't good because they're insanely clever and whip up brilliant combinations of abstractions. They're good because they write maintainable, understandable, simple, and effective cod…

> I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers.

Right, go is for inexperienced programmers.

> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software.

Or so Rob Pike thinks. However, as I get more and more experienced, the shortcomings of go become too much to bear.

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

#403

I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decade…

> I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. Counterpoints; was the concept of generics a thing before Java implemented it? That is, could they have known? Second, a ton of the Java spec and compilers and stuff is dedicated to generics; would it have been less complicated and voluminous if Java had it from the start? With Go, they took their t…

> was the concept of generics a thing before Java implemented it? That is, could they have known?

You can literally google "X lang feature" and it gives you a date. ML/Ada have had generics since the 70s.

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

#404
post #264

Earlier quoted context omitted.

Yes, but that is definitely not achieved by checking for errors every second line.

I think checking for errors every line makes my go programs easier and faster to produce at a higher level of quality.

Sure, but is writing the error check by hand what creates the benefit? Or is it having the error check?

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

#405
Go is interesting because it has a cult like following of advocates who spout the same sound bites all the time, yet seem completely oblivious to the larger world out there.

Go seems to be in this weird space where it is not particularly suited for anything that its proponents say it is. As a systems programming language it gets a lot of flack for being garbage collected. As a web programming language, it is not ergonomic at all. The process of simply formatting a string is ridiculous compared to the string interpolation of Python or Scala. Furthermore, if I was a web developer, why would I want to deal with the cognitive overhead of Arrays vs. Slices or pointers?

The type system also takes a lot of heat, mainly for generics but that seems like something that is coming soon to the language. Nevertheless, it is sort of telling that Kubernetes decided to implement its own internal type system instead of leveraging the OO paradigm provided by the language.

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

#406

Earlier quoted context omitted.

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…

So the purpose of a programming language is to spark joy in developers? I mean, I get it, but it's a very selfish position to take and it's not in the interest of a business, in the end. I mean, Java makes me feel dead inside, but I appreciate it for being ubiquitous and reliable, and that a business will be able to find half-decent Java developers any day of the week.

Workers who enjoys their job tends to do better at it.

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

#407
post #105
post #47

Earlier quoted context omitted.

It requires several additional lines of code just to bubble up an error, for starters, and there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data.

"there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data." In theory, this is a big deal. In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it. A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another fu…

In practice, it's been a pretty common problem at organizations I've worked in.

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

#408

Earlier quoted context omitted.

Agreed. I just want to make clear that Rust/Ada/etc. don't give correctness guarantees! Their compiler is just more enforcing. It's all not black and white. Rust is promoted for its correctness, but those correctness related bugs Rust prevents are an extremely low fraction of real world bugs (comparing to managed memory languages). I mean, how many type-system related bugs are there in real world projects with Java,…

Null pointer bugs are prevented by idiomatic use of Option in Rust, so that’s at least one case where Rust’s focus on correctness prevents memory-safety bugs.

Yet many Rust code bases are littered with .unwrap(), which undoes that benefit.

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

#409

Earlier quoted context omitted.

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…

> I'd like to see Go require return values be dealt with or explicitly ignored.

Ever use the return value from fmt.Println?

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

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

I like Nim or Zig so far as my home project alternatives to Go...
Post reply on HN