211–220 of 238 posts
Earlier quoted context omitted.
Go's stdlib is a tiny portion of what Java and .NET offer.
Yes those are two bloated stdlibs.
Naturally turning into name calling is easier when running out of arguments.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
> 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()` met…
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…
It’s weird seeing all this post-hoc rationalising when there is a perfect explanation for why go doesn’t have generics: Rob Pike didn’t bother to look into any of the research into type theory and programming language technology. Hence his understanding of types were restricted to Java and C++ and similar (whose type systems are an abomination), and he could not separate subclass polymorhism with inhertance from para…
Or maybe the academics and type theorists are philistines about the software that runs the world and their arguments have mostly been about hand-picked toy examples? Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time?
Software that runs the world utilizes parametric polymorphysm in C++, Java, Ada, D, Swift, OCaml, Haskell etc, hell, even C [1].
I also tend to consider some mission critical Ada/C++ software a real engineering, not some webshit.
[1] https://github.com/jiixyj/libebur128/blob/master/ebur128/ebu...
Earlier quoted context omitted.
So, we would seem to have two key statements being pitted against each other here: 1. Rob Pike doesn't have a strong grasp of type theory. 2. Rob Pike is an accomplished programmer. To me, this conflict of opinions is structurally indistinguishable from 1. That shape over there is a square. 2. That shape over there is blue. IOW, there is no argument to see here.
No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.
What do you mean by "real world software engineering experience", Acme or Plan9? These are silly academic projects with tens of installations at best.
Earlier quoted context omitted.
> Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time? What are the credentials to back this up? Otherwise, the languages he makes fun of actually are used to deliver large scale systems in real time. Google is built on C++ and Java, so are most of the other top tech companies, not to mention bank…
He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project, before joining Google. That's probably more than most of us will ever achieve.
So his only "serious engineering project" is a toyish academic operating system? No mission-critical software, no application software with millions of installations (except Go compilers).
This article highlights very well why designing a programming language without generics is a mistake. Adding it after the fact is not trivial, especially if you have high standards wrt simplicity and non-redundancy.
I don't think so. The article explains also that generics as implemented in other programming languages bring a lot of complexity and that generics aren't mandatory.
interface{} is already promoted to heap, they are pointers, all you need is to swap interface with type parameter and add a couple of hundreds lines of code to the type checker. The theory is all in the books and there are dozens of compilers implementing it in practice.
Earlier quoted context omitted.
Nobody uses ravendb or akka.
Everyone here would like some numbers, after all you must have a solid source to make such statement.
Ravendb...
Earlier quoted context omitted.
Yes those are two bloated stdlibs.
On the contrary, they are feature rich with capabilities that Go still hasn't found a proper way to support, like something comparable to Swing. Naturally turning into name calling is easier when running out of arguments.