I trust Linus from the fact that he put the user at a level of priority more important than anything esle in a time when few people did it, and this decision makes userspace solid as a rock to me over the years
Yeah sure, and if you like I can also clean the bathrooms because I know how to do it...
Off-time is for your own not for your company regardless off what you do with it.
There makes no sense to comparing goroutines with os threads, they are totally different things, this is like comparing apples with oranges, of course both of them can be used
to solve the same problem, but they are totally different.
Like others have mentioned, is well known that a thread-per-connection solution does not scale well, a quite better approach is having a pool of threads with fixed size and using an asynchronous non-blocking event driven model.
Actually in our company we did some benchmark messuring golang (1.9 with well known http servers) and java 8 with Netty, and the latter always won.
What does "won" mean here? Better throughput? Lower latency? Less variance in latency? Better efficiency? re: the last one, I'd be shocked if Netty could match Go stdlib http in memory usage even if you benchmarked higher throughput. I'd expect the Go server to have lower variance too due to its GC design.
Yes, this sentence is quite vague and does not give proper info about the topic, you only have to believe me or not, I'm not writing any blog about this, sorry.
Means higher throughput with lower jitter, that in our case was what we were looking at that time. For go defense we were using PooledByteBufAllocator for recycle Output Streams but memory usage was not a concern in benchmark as much as GC does not affect throughput. But I also believe that go http stdlib memory usage is better than netty, sorry for not being more helpful with this topic.
Thanks for going into more detail, I'm interested that you got lower jitter. My experience with high performance JVM networking stacks is that they achieve incredible throughput but are quite hungry (with a hungry baseline too) and that 99P can be not so great due to GC. I'll have to give Netty another look. I'd be interested in the RSS of each process after warmup.
In my experience tunning a jvm application in order to gain better throughput is far from a trivial job, although jvm ecosystem's requires a much more experienced developer on the platform to reach some levels in comparison to go simplicity which results in really high performance solution easier.
For instance deciding an appropriate concurrent algorithms and measuring it. e.g. using AtomicInteger vs a per-thread-counter-based is not easy (specially in more complicated scenarios)
We have both java8 and go, high throughput critical microservices with excellent 99pctl, and in general memory is not a concern (as much as we do fine tuning on gc and don't have any memory leak) and generally for the really critical and portable solutions we choose java over go (unit testing and library versatility is a big player in this discussion)
It does make sense. These are all techniques for dealing with async events (I/O). Thread-per-client, cooperative multitasking / co-routines with co-routine-per-client, ... all the way to C10K-style thread-per-CPU callback hell.
As I said both can be used to solve the same problem, but since they are totally different and works very different, to me it makes no sense doing a comparison and expecting similar results, if comparision's were analyzing the same technique in different languages then this will be fare.
I think code review is the async way to share thoughts about the code and managers (in my experience) tend to be busy with many meetings making 1 on 1 code review more difficult therefore in this case pull request might not be the best option but a good one.
I would argue that in 95 was recently the first jdk 1.0 release, it was until 2004 which came java 5 with java.util.concurrent which was such huge improvement for that time, since then is easier to write concurrent software, and since java 8 is a wonderful experience!
I would insanely choose ruby rather than javascript for the major advantages that has to offer. Performance in most of cases is not a real needed over consistency. Also Ruby 2.6 has jit, would be great to see some bench tests. :P
2.6’s JIT is entirely at the method level currently, and unfortunately for certain types of workloads (e.g. Rails) this means the performance benefit is largely outweighed by the call counters and deoptimization checks on every method invocation.
There’s definitely room for improvement, and the inclusion of JIT infrastructure is awesome, it’s just not making much of a performance impact. Yet.
The overheads from the call counters and deoptimization checks are tiny. The real problem is that right now MJIT doesn't allow much optimization beyond generating native code equivalent to simply executing the instructions. It's ridiculously simple compared to V8.
I do not agree with that, this is not just syntactic sugar, for example in case of large 'else if' statements the complexity to choose proper branch is O(n), instead with pattern matching the chosen branch will be at constant time.
While the article mentions Pattern Matching, it seems to be something for the distant future. I was referring changes of Java 11, which seems to me the focus of the article.
