581–590 of 679 posts
Nice to read all the comments on this story. The story is about the how Go is not truly open source and community driven and the flame war starts on how Java does not implement generics correctly etc. Guys: each language has it's benefits and it's shortcomings. If we want (need?) more control over the language, can't we just fork it? Start a new language that is based on the current implementation of Go?
There are 2 things I like about Go, 1. Compared to most compiled languages the toolchain is very easy. 2. Reduced ways of solving things in the language itself. My main dislike of C and C++ is that there are numerous ways of solutions for the same problems, this forces me to weigh the solutions constantly against things like "Is this a safe way, does it create fast code, will this way fit when my project is further o…
Go made me enjoy the programming again. And of course, managing modules is a very difficult task so it had to be done somehow and somehow really, really good and I think they delivered the working solution. Various previous attempts were bad for various reasons (Kubernetes can tell you).
Earlier quoted context omitted.
> Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency. This has zilch to do with not being community led, so perhaps the complainers should fish for better arguments. Rust makes the exact same call wrt. t…
Rust does support multiple major versions of dependencies in a build. The only thing we don’t allow is multiple copies of dependencies that link to native libraries, and the -sys pattern means that this is rarely an issue in practice.
1. Yay!
2. Yes, native libraries would be difficult. Or impossible.
3. Could you elaborate on the "-sys pattern"?
Earlier quoted context omitted.
Do you need an alternative to GHC?
I would certainly like a compiler that was fast enough to be usable with realistically-sized codebases. I'm writing this while waiting a couple of minutes for ~10,000 lines of Haskell to compile.
Can you create a Haskell compiler that is faster than GHC? Probably. Can you create one that is fast? I'm much more skeptical of that.
Earlier quoted context omitted.
A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.
Reminds of Java modularity debates, where OSGI folks kept railing against approach Core Java people in Oracle were taking. In Java's case it took really long time for Oracle to prevail over self-appointed community leaders and modularity experts pushing OSGI and come up with better solution. I am happy that similar kind of situation did not prevail for that long in Go's case.
And the final Java module system is much less flexible than OSGi (which is much more than a module system, which in turn is both a strength and a weakness in this case). Or do Java modules support multiple versions of the same package?
Earlier quoted context omitted.
Rust is not a suitable replacement for Go.
Why not? I consider Rust to be superior in almost all respects apart from learnability and compile times. So if these two downsides are not more relevant than the downsides of Go (in a certain context), I don't see any reason why Go could not be replaced by Rust.
Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…
You could say the same thing about Linux. If Linus doesn't like what you made, it's not getting into the kernel.
Earlier quoted context omitted.
And Haskell's market success is still very limited. This isn't a very compelling argument for community-driven language design. I think a better one would be Rust (to the extent that we can agree that Rust is designed by community) which seems to be getting a fair amount of market penetration given its age.
Haskell deliberately "avoids success at all costs" though.
Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…
1. All the work is done in public, with a license that gives zero protection to the original authors.
2. The project leder (myself) only does OSS work and has no other roles in the sponsoring company.
3. The roadmap is decided by the community (myself with feedbacks from the community), not a company or some product manager or alike.
4. There are multiple people from multiple companies contributing regularly code to Redis: Redis Labs, Alibaba, AWS, ...
5. The main web site is handled by the community.
In the case of Redis this was possible because of the minimality of the project, otherwise I agree that's a huge challenge. But still IMHO Redis deserves to be listed in such "purely community" OSS projects.