why do people support this company still? sorry to be that guy, but i will never use a product from them after the jwz fiasco. and no, new leadership doesn't make up for decades of behavior.
It is really too bad that we can't have things like this in our society. That looks like it would have been a very healthy way to deal with stress and frustration, especially in an otherwise restrained environment like work.
It's not clear if it's the intended result, but that link (for me, and quite unexpectedly) redirects to an Imgur picture of a testicle in a teacup, which is a little funny but which one might not intend to display.
Agree and disagree. The thing I was going for is that compscience advantages don't seem to matter for language adoption. i.e. popularity does not correlate to compsci purity.
Let's name it as The Law of a Decent Runtime, and The Law of Attention to Details, and The Law of a Bazar of Ignorant.))
The Law Of a Decent Runtime is very simple - evolving a decent runtime is very costly and time-consuming. It is also related to the second law and to the inverse of the third - which is a the Law of Dictature of The Most Competent. A decent runtime cannot be produced without talent, time, financing, competence and attention to details.
The examples are what came out of Xerox Parc, Bell labs, Ericsson and the best parts of academia (MIT Scheme culture, Scala, Standard ML, LLVM and Haskell, monads aside).
There are also many in-house (Tensorflow) and sponsored open source porjects (LLVM, Golang, Julia, Torch, to name a few). Basically, it is about resources spent on a talent.
What is important distinction - a decent runtime cannot be produced by the Bazaar of Ignorant (PHP, amateur Java code, SAP, and other "fractals of a bad design").
The Linux kernel is very special example, because it combines the law of big numbers, and all these three - it is a product of a whole planet of competent volunteers and paid developers - unlike PHP or Java ecosystem there is very high barrier to entry, thanks to The Dictature of The Most Competent .)
The law of Attention To Details - is quite obvious, and related to the first. This is why most of successful projects had a passionate and competent leader who sets the standards, be it Linux kernel, Erlang, Nginx, Gambit Scheme, Python, OpenBSD, Redis, Scala, SBCL, PostgreSQL, you name it.
Popularity has nothing to do with it. It is based on the principle of instant gratification (PHP, MongoDB) or Availability Bias boosted by paid content brainwashing (Java, SAP, MS) without understanding and preferably any thinking. Popularity doesn't mean quality at all, be it junkfood or PHP.
No, Go is more simple, in terms of syntax among other things. The threading model in Go is very attractive as well, please refer to this article: https://swtch.com/~rsc/thread/
That's a nice overview of CSP. It's not a selling point for Go over Rust. Rust threads are in fact a purer implementation of CSP than Go goroutines are.
Go offers thread as channels directly expressed in the language Syntax, not as a semantic construct on top of them. That is of course attractive for it's simplicity, but Rust offer a lower level alternative. I don't have much experience with Rust, but maybe a clever macro could be use to express in a higher level the type of things you'd use go channels for.
Going back to my proposed question, maybe people can prefer golang for this syntactic benefit but I don't think that addresses the larger set of differences that usually separate them.
Thanks for the link. It was a great read to understand in more detail what go channels really are from a theoretical perspective and how that could actually be matched within Rust.
