Hacker News Reader

Comment by spion | Hacker News Reader

> Go strikes me as one of the most conservative programming languages available today. It’s small and simple, and every detail is carefully thought out.

This article is wrong in many ways, but I thought I'd point out this particular one. There are many really weird warts in Go, in fact its about average in "wartiness". Here is one example https://dave.cheney.net/2017/08/09/typed-nils-in-go-2

Go biggest advantage isn't the language, its the decent documentation and standard library design. The language is a bit mediocre. I wish the Go community accepted this and moved on - a mediocre language with good documentation and well done standard library is still an acceptable contender since so many other languages get those two wrong.

View on HN

There are some weird parts in the Go language, yes. But since it's so small, a lot fewer than other languages.

> Go biggest advantage isn't the language, its the decent documentation and standard library design

Which, ironically, Java is just superior in every way when it comes to documentation of the standard library. Large open source Java projects are well designed and very well documented, unlike golang projects.

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying.

The Go documentation as well as standard interfaces are tastefully and minimally done (for an imperative language): https://golang.org/doc/ - e.g. https://golang.org/pkg/io/ ... To my knowledge there is no equivalent of this for Java that comes close.

Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm...

Java has pretty nice generics. With Java 10 the language is now decent too.

> Java also lacks green threads

Green threads are not the be-all-end-all solution for concurrency. They have their place, but so do event based async io.

That being said, Java is getting green threads in the form of Fibers.

> Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm....

Obviously Java's Reader interface does more work, and has a `close()` method, which golang lacks. Golang is forced to go with this way to write interfaces due to how they are implemented (sacrificing usability to get nominal typing, which is a very questionable design decision). Languages like Kotlin, Rust, Scala among others have superior solutions.

Can Quasar fibers be efficiently used with other (popular) Java libraries that build on top of the standard libraries? If not, I don't consider that to be good developer experience. That is more of a mistake that cannot be rectified.

Async IO is also fine. The question is, what is your current ecosystem built on top of. AFAIK the answer with Java is definitely not async IO or fibers.

Yes, structural interfaces in Go are implemented poorly. But the standard library uses them very tastefully, putting most standard libraries to shame :) Go also has Closer, and its a separate interface - interfaces are minimal which makes them much easier to implement and more generally applicable.

From Loom talks it appears that fibers will also be able to consume Runnable and Completable.

Loom is still WIP. Remains to be seen how easy / performant it is going to be adopt in practice with the existing ecosystem.

> Java also lacks green threads.

So weird. Java used to only have green threads. The very name, "green threads", comes from the fact that's what the JVM called them. Literally invented the name.

Too bad they were removed. I don't see why a non-system language should use anything other than green threads nowadays.

Because Java also runs bare metal and in those scenarios, it is indeed a systems language.

The HN community is too focused on OpenJDK/Oracle when talking about Java, when there are as several JDKs toolchains across the industry, some with very specialized deployment scenarios.

The lesson from that being, the extreme of "write once run anywhere" is not necessarily a good idea. Sometimes its best to implement specialized libraries and runtime (green threads) for specialized environments (servers) that are not available in others.

I'm under the impression that Java implements generics via type erasure.

Thats not an entirely bad way to do it.

Sucks for you, considered very good by plenty of other people who use it daily.

I use Go daily and I agree with the general sentiment that it's a janky language full of warts and could really benefit from features like generics.

Maybe go back to java or c++? I'd rather have less people complain about a feature I don't want in the language.

Just curious: why don't you want generics in Go?

The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}.

It's not as if Go is a language without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself.

This is a legitimate question, btw. Legitimately looking for other points of view

Keep in mind that many golang programmers just parrot what the golang authors say, without fully understanding it or even realizing the golang authors are wrong (not saying that's the case in this specific instance).

They hear the golang authors complain about Java, that it's the only way to do things, so they think that the only other solution is to go the extreme opposite way, not even looking at real modern languages (which golang isn't) like Kotlin or even C# for instance.

It's very evident that the golang authors have no experience designing language, and didn't look in depth at what other languages did.

Unfortunately I am not parroting. If you are used to read code, and you read c++, you will see that templates are abused. No generics force devs to make their code clearer and thus more secure.

It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.

for sure i can abuse Go's language features as well in unintended ways.

Language abuse happens when the feature is the only available feature to implemented a particular and no other language feature allows for a better implementation.

in C++ most abuses of template are related to the missing feature "concepts". which took quite a while to get their.

If language switching is not an option, and your application requires generics and you are also required to use Go, you do have a problem. You need abuse the language and work around re-implement generics for Go.

Which can result in a very ugly development process, difficult to maintain code etc.

They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.

I think generics in C# are really well executed and solve a lot of problems in C#'s problem domain.

I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java. C++ abuses templates and has dozens of ways to do anything that also don't interact with each other well. Java abuses inheritance, abstractions, and OOP.

go uses generics under the hood, probably the designers fear that generic's will also get abused if released into the wild. On the other hand I've never heard anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.

> I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java

Now that you mention it, I can't really blame them!

> On the other hand I've never heard anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.

That's my opinion as well. Generics are quite pleasant, simple and a great tool to have when they're well designed.

I would suggest a Go programmer give ReasonML an honest try (as an example language where "generics" are done right), but the getting started / documentation situation is still not at Golang level so thats a bit annoying.

Maybe F# would be a better choice. .NET Core and its tooling are pretty well done. C# and NET Core would be another nice alternative.

Agreed. I find C# and F# surprisingly refreshing. ReasonML is a bit unfinished, but it's a sign of great things to come.

golang authors seem to only have experience with C++ as they keep talking about C++'s deficiencies, as if it's the only other language that exists when it comes to generics.

Sure. Seems like they have the same experience than me then.

The point is that they are not familiar with the solutions other languages have. So it's either the C++ way or don't look elsewhere.

Because they are easily abused (look at c++) and makes code unreadable. Working around generics usually make the code clearer and thus more secure

Go has interface{}, which can be abused as much as generics for the same purpose, but without the type safety, hence, less secure.

And nobody is advocating C++ style template metaprogramming. There are much better implementations of generics, as acknowledged by Russ Cox himself.

Usually interface{} is abused by java programmers. I agree that it's not great, but if you don't come from java or c++ chances you won't follow these patterns at least.

I'd love to get away from Go again, but unfortunately it's the hot thing that people see on your resume and then they don't want to talk to you about anything else. I'm very concerned that in a few years it's going to be the terrible low-paying boring thing that people see on your resume and don't want to talk to you about anything else.

Its the hot thing for a reason. Adapt or be left out.

I've been using Go in production for 5 years now, I don't think there's a lot of adapting left to do. From the other side of a few years of experience I think I see the reality of the situation pretty clearly. Go isn't a good language by any means. It's the hot thing because it's a marginally less painful blub than python or java and cheap entry-level developers can be onboarded to it quickly and be left to churn out boring but largely unharmful code. On top of it's programming with mittens mentality it had the force multiplier effect of becoming the devops language dejure. I think the staying power of Go is largely dependent on whether or not the industry finds the current state of devops a local maxima that it sticks on for a while, or whether things push further into PaaS territory and the current devops tooling becomes irrelevant for everyone except the big cloud platform implementers.

Same

There are plenty of people who consider C++ good too and its used by people daily. Doesn't mean that Rust isn't a better language, even though there are less people that use it daily.

I think we need to be real about what are the strengths and weaknesses of each platform instead of drinking the coolaid. Otherwise we don't learn anything and the bad parts are going to find their way in the next one.

Reply on news.ycombinator.com