Hacker News Reader

> critics of Go aren't even Go developers

This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released.

If only people continuing to use X could criticise X, we wouldn't get much progress.

Dependency management was always my pain point, but that has suddenly gotten crazy better with Go 1.11, for what it’s worth.

Complaints about gopath always feel like such a nitpick to me. Environment variables are trivial. Few Languages are as simple as Go, when it comes to development environments.

It part of the death by papercuts for me. Sure, it's trivial, but it's the only language that requires it and I can't see any benefit of it. When working with multiple projects, it can lead to weird errors until you remember to change it too.

It's like getting a house where you have to use 2 separate switches to turn each light on/off. Is it a big deal? No. It's just weird and annoying, without an obvious benefit.

The complaint about GOPATH is not that it's an environment variable. It's that it enforces a specific directory structure that does not match how most people organize their code trees.

Instead of a project being in a folder called, say, "foo", you end up with something like $HOME/go/src/github.com/bar/foo. Then, when you install your project's dependencies, they get commingled into this structure. If you do "ls $HOME/go/src", you'll see a ton of stuff polluting your tree, all of which are arguably build artifacts, not primary sources. Very few people manage their codebases like this. At best, you put all your dependencies under a subfolder somewhere so that there's no confusion.

Go 1.11 does away with GOPATH for your project, and relegates all the dependencies to $GOPATH/pkg/mod. We are now using this new module mode, and it's a breath of fresh air compared to the previous system. This way, Go feels a bit more modern and much less gnarly.

I’m so conflicted about this comment because I have made nearly identical comments in the past.

I think I’m going to have to change my stance on this point, however. There have been so many occasions that something about Go bothered me, and I then later discovered was a prerequisite to leveraging a much simpler programming model, that I am humbled by how much more I had to learn about programming. And I have to admit that others before me said as much, but I didn’t believe them.

Sometimes one just isn’t competent to render a useful opinion.

If you haven’t seen the movie, read the book or eaten at the restaurant, the directors, authors, and chefs should rightfully ignore your criticism. And I for one am glad the Go authors ignored criticisms like mine, I am a much better programmer now then I was then because I learned something new.

Although I will admit it was difficult at times. It’s hard to go from being an expert at something to a beginner at something you feel should be essentially the same.

I feel like you're saying the criticism has to turn out right or wrong. I don't feel that's the case. A criticism is just an opinion (based on facts or not). Ignoring them will lead one way, addressing them another. Some people will like either one of them.

I think criticism from people who stopped using X is a valid opinion even if it's ignored and if other people are happy it was ignored. You can't please everyone.

What the GP was saying is that a critique from someone who actively uses something should carry more weight than a critique from someone who doesn't use something because they happen to prefer the goals of something else already available anyway.

This was also the point I was driving at. I do respect the opinions of other developers outside of the Go community as well but as you said, you cannot please everyone. When many of the loudest critics were those who seemed to miss the point of Go or at least we're disinterested in the goals of Go, it got quite irritating to constantly read how "Go is terrible" when clearly it is a perfectly decent language for a great many developers. It's the same thing with the roadmaps, those who criticised it the most were often the developers who werent Go developers and thus didn't depend on the assurances Go offers.

I wish more programmers were as thoughtful and humble as you. Sadly my personal experience is that most developers tend to be full of themselves and their opinions without even questioning them a bit.

>I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2.

They said that occasionally, but always dismissing any kind of proposal that wasn't theirs, including perfectly fine existing paradigms from other languages, and always giving the impression to many people that they were just paying lip service to the idea that they are OK with eventually adding Generics, or stalling for time.

The fact that it took 10 years for this to finally come as a concrete suggestion (and not even with a final delivery date or official roadmap yet), means that they were indeed stalling for time.

>Sometimes it feels like those who are the loudest critics of Go aren't even Go developers and instead just like to shout about how amazing their preferences are because it does xyz differently.

This tired argument has been said again and again. Many seasoned go developers have spoken in favor of generics over the years. And this features was #1 in Go's own developers poll year after year.

Besides, it's not like non-users of a language are automatically wrong. If anything, they could be the ones seeing its faults more objectively (e.g. people calling out Java world's obsession with overusing patterns).

It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust...

Also I see stuff like they should just use "perfectly fine existing paradigms from other languages" on HN all the time. But from the very beginning they said that Java-style generics were undesirable (due to overhead) and C++/Rust style were also undesirable due to code size. In the end, the proposal does not choose either system and tries to enable the compiler to make trade-offs in between. It seems most inspired by CLU and a proposed future C++ feature... I genuinely don't understand why HN views this as an easy thing to just copy in, unless they view the design goals as unnecessary to begin with...

I definitely think it will be convenient to have type safety for collections that are not lists or hashmaps/sets. I also think it's convenient to have multiple return values and slices (so every list api accepts sub-lists without copying). Overall, I didn't find Go to be tremendously less convenient than Java or C#... I'm kind of curious what kind of software HN is working on, where Go is so much worse than the alternatives.

As you say " It seems most inspired by CLU".

Do you happen to know by chance when CLU was created?

To quote the entire sentence, "It seems most inspired by CLU and a proposed future C++ feature".

Note that Stroustrup proposed C++ concepts in 2003, and they still don't exist in C++, but they might be standardized by 2020.

Also note that CLU also didn't implement compile time specialization at all which is one of their core design requirements (for performance).

I don't think this is the particular prior art most of the "generics are easy" people are referring to, anyway.

It's maybe accurate to say that the Go team could have fairly easily done Java-style parameterized types (implemented via boxing everything like Java) and they chose not to do that. They chose not to do that mainly for performance reasons (and the hit would probably be worse in Go than Java since it's more value type oriented and doesn't have a JIT).

A lot of people here seem to value expressiveness above everything, but I think it's unsurprising that that Go didn't want to make those performance compromises, since it's trying to be an alternative to Java and C++ at Google-scale.

Java-style parameterized types is not the only option and they have acknowledged that they ignored us for a long time.

"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

As for being an alternative to Java and C++ at Google-scale, all their major projects, with exception of Kubernetes, are mostly based on Java and C++.

I'm not disputing that there's prior art for their design like C++ concepts (although C++ doesn't do run-time generics and CLU didn't do compile time). I'm just disputing the view designing and implementing it will be easy, like they could have just thrown it in there without taking substantial time away from other priorities and/or delaying the language, so anything short of providing generics day 1 is disingenuous or maybe ignorant.

Take this interview with Chris Lattner (of Swift) for comparison:

http://atp.fm/205-chris-lattner-interview-transcript/.

Some of the things they want in the future but just haven't had time for (more reflection, core networking libraries, etc) are things Go provided day one. If you look at the recommended way of dealing with JSON in Swift for example, it's full of boilerplate. Go also provided green threads and GC which probably adds some implementation work compared to languages that don't have them. They've also prioritized language stability to a much greater degree than Swift.

I don't know to what degree Go has succeeded with its mission inside Google/Youtube (for new projects, obviously they aren't going to re-write everything), but it seems like the Go team has more resources than it did before, which might be part of why they're more comfortable tackling major changes like this now.

If language designers didn't want to make nuanced trade offs in the design space between compile time, performance, code size, ease of use/complexity etc and sweat all the implementation details I'm sure they could operate a lot faster. Javascript might have already cornered that niche though.

> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers

I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bitter taste in my mouth.

Not to mention that Go was sold as a systems programming language, but my last 5 years of experience with the language (developing container runtimes -- which are the most canonical example of systems program you can come up with these days) tell me otherwise.

Yeah I've written some systems type stuff in it as well such as a UNIX shell and FUSE file systems. So Ive played around with syscalls and the sort in Go and frankly I'm inclined to agree with you there. I mean sure you can use Go as a systems language (as we have proven) but that doesn't mean it's the best suited language for that particular type of application.

However I don't think that's so much an issue with the lack of generics nor Java-esk exceptions but rather it's memory management and green threads. You may disagree with me though - the stuff you work on is definitely a level or two up from anything I've attempted in Go.

From a practical standpoint, you're right that the biggest issues are green threads (which had many issues where runtime.LockOSThread didn't actually do what it said on the tin -- making it impossible to use for certain namespace syscalls) and the memory management sometimes having "issues" (I found a bug several years ago where it looked like the memory manager would not free memory but would use MADV_DONTNEED -- which is less efficient than free -- but then wouldn't reuse said memory which meant that the process was killed by the kernel eventually due to memory overcommitment).

The other stuff is mostly icing on the cake in terms of whether the language is painful to use -- and having no generic container types is a perfect example of a day-to-day pain. Every time you have to sort a slice you need to implement sort.Interface (or nowadays you can use sort.Slice -- but that requires casting your slice to the right interface which requires allocating a new slice to get around missing type information).

Why do you think, from your experience, it is not a systems programming language?

You cannot write a single-threaded program in it (GOMAXPROCS doesn't do what you probably think it does), and the green threading until very recently didn't obey runtime.LockOSThread which meant that you couldn't even guarantee that a function would execute on the same logical thread (which is critical for certain syscalls).

cgo (which is unfortunately necessary if you have C library dependencies) has significant issues like not being able to support union conversion to a Go type -- which means that you have to write helper functions in C and call those to access unions. This is part of a more generic problem that the memory safety model doesn't lend well to systems programming (and unsafe.* is just too scary to be usable everywhere).

Oh, and the syscall package is effectively deprecated and you now have to switch everything to golang.org/x/sys/unix in order to use it properly (though one of the maintainers does nicely send PRs to projects often). This indicates to me that not enough people tested that the "syscall" package interface made sense in the 9 years before 1.0 and the stability guarantee set in (which means that the code which is very important for a systems programming language wasn't widely tested).

If you want to (for instance) use AT_FDCMD with openat(2) you won't be able to because all of the syscall bindings require file descriptors to be a uint -- despite the kernel interface using an int (and the fact that AT_FDCMD is -100 or something like that). Yet they use AT_FDCMD internally -- which means they know it is needed but they elected not to expose this to users.

It uses the "int" type for PIDs instead of using pid_t, for crying out loud. No systems programming language should do that.

> Sometimes it feels like those who are the loudest critics of Go aren't even Go developers

Perhaps unsurprisingly, those who didn't like what they saw when taking a look at Go might well have chosen to work in other languages.

This might be a basis on which to prioritize criticism -- certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism.

And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed").

I don't begrudge anyone who likes it their happiness using it. I know people who really do like it. But I know people who gave it a fair shot didn't like it. Mine was 9 months of part-time work on a project before I settled into the conclusion that most of MJD's faint praise of Java (https://blog.plover.com/prog/Java.html ) plus a few extra downsides applied to Go. Including, yes, the arguably generic-shaped hole.

I also don't begrudge the stewards of the language their own solution to that problem or their own timeline for it. Presumably a similarly generous spirit should apply to complaints continuing to register. If the pothole is still in the road, it isn't surprising that observations about it continue to roll in even after plans to develop plans to fix it may have been announced.

> This might be a basis on which to prioritize criticism

Maybe if the language was unsuccessful then yes. But given the popularity in f Go it's fair to say the concerns of its existing user base should take precedence over those that may not use the language regardless.

> certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism.

But as this topic has demonstrated, those concerns haven't been disqualified out if hand either.

> And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed").

I disagree that happens. In my first post I made the arguement about language stability (not breaking things). Others have made the arguement of simplicity and/or readability as well. I think the real issue is some people don't consider those good enough reasons so dismiss the counterarguments out if hand. Which is obviously an opinion you're entitled to but you have to remember that it's the stability and simplicity that has made Go popular in the first place so those points actually do matter to a great many of us.

The thing is, there is already C#, Java, Rust, C++, and a great many other languages out there that have rich ecosystems and expressive semantics, Go has gone in a different direction by being a boring language. This direction clearly divides people though.

> Sometimes it feels like those who are the loudest critics of Go aren't even Go developers

I have been writing Go exclusively for almost 3 years, (I still maintain some legacy J2EE applications, and live in a Java/C# town) -- this has been true anecdotally 99% of the time. There's the one-off who actually does use go regularly.

Then again, I witness this same phenomena in the JS framework battles, even within my own company. Vue vs React, where neither of them have ever used each others and built an actual production application to evaluate it. This is just the editor wars over again.

The Go team should have considered generics for Go 1.0 during the 0.x phase.

It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like dependent and higher-kinded types are a bonus.

We've also done enough computer science to know there are much better ways to relieve the programmer of the burden of doing all memory/resource management explicitly than a tracing GC. So using a tracing GC in an ostensible systems programming language was another huge boner.

Go 1.x was a cascade of bad decisions. It's like Java was in 1995: a language with training wheels that had to change directions entirely when real programmers started using it to build real applications.

> No exceptions

Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.

How much would had it achieved if it didn't had the Google logo to go along it?

Lets say developed at SV startup XYZ instead.

There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart.

I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.

Go is also similar to languages like limbo/newsqueak. None of those are popular(many might not have even heard of them). So part of success definitely goes to being successfully marketed as a google product.

Dart suffered from Google politics, trying to take over JavaScript, and then being dropped by Google's own teams (Chrome and Angular).

Being rescued by AdWords team, and now having Flutter team as their last hope.

Go hasn't suffered from such politics.

Let's not forget that Go is a mix of Oberon-2 and Limbo, both a failure regarding market adoption, in spite of their technical qualities.

Some dart ramblings. Seems to me, that the Chrome team is responsible for Dart demise and its later flutter inspired resurgent.

Flutter was started by people in the chrome team, as an experimental project called sky.

With regards to making it possible to include the dart vm the oilpan project was started.

Oilpan, the replacement of reference counting in Blink, with a tracing garbage collector, this would have made it possible for dart vm to sit along side v8 in chrome.

Oilpan was started in 2013 and instead of taking months, it took years, I think it finally arrived in 2016. Here is a dart video from io 2013 announcing oilpan. https://youtu.be/huawCRlo9H4

Or any of the other languages Pike has been involved with?

The main focus of go is to be as simple as possible.

It's not that they don't known how to write complicated programs under the hood and keep it simple outside.

They want to keep the programming language simple even under the hood where ever possible.

Consider implementing a feature in hurry just because many people were asking, one needs to maintain them for the rest of their life even if they hate it so much, because of backward compatibility.

It can also be the root cause for many problems.

If generics make language complicated, then it's better they don't implement it in the first place.