Personally I don't hide it, and I do type each token by hand. Since the parent brought up tedium, I wanted to mention that there are solutions to it. IDEs hide bloat, but code review and other tools often don't.
It cannot. The syntax bloat forces structural cleanliness.
A lower level problem is addressed with a higher level fix. It would be better of course to not have bloated syntax, but not at the cost of better program logic.
As for tedium: Java programmers rely heavily on IDEs to "write" most of the boilerplate for them. The IDE fills in tokens automatically, and hides them visually with +/- boxes to the side.
Java is commonly criticized for being too verbose, but I never understood why. I agree it is verbose, but verbosity isn't really that bad of a problem. Programs aren't harder to write, they aren't more bug prone, and they aren't harder to understand. On the contrary, high verbosity means less information per token, making it easier in my opinion to read.
A good example is the anonymous class. They are portly and wasteful of vertical space, often costing 5 lines when one would due. But, the amount thinking per line is greatly reduced. In order to visually afford anonymous classes, logic must be simplified or structured, commonly by splitting up a larger function in order to fit it on a single screen. An arguable misfeature of the language has a convenient side effect of forcing best practices.
Having high numbers threads and switching between threads are different things. There is still a huge constant in front of that O(1) scheduler that makes it unattractive.
Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
Obeying traffic lights decreases tail latency and increases throughput. By not obeying them (as a society, rather than individual), India is only hurting itself.
> The whole western world is in for a rude awakening in the coming years with regards to retirement.
No kidding. Who will pay for all the people who didn't save? The people who did. I have very little expectation of keeping most of my money as I get older.
Lip service benchmarks like this don't help anyone. They just add fuel to the ignorance fire. Why was the Go version faster? Without profiling the code being benchmarked it doesn't really mean anything, since any number of unrelated factors could have affected it.
For example, did you know that until recently Go's HTTP/2 client didn't do flow control? Sending cross continent requests could easily result in slowness. Did the Go program in this test use the updated code? If not, it may have been much faster. See how not understanding why it's slower leads to not understanding?
.NET may actually have been faster, but we won't ever know because the author didn't really understand what was going on.
The numerous overloads of 'this' is one of the things that turned me off from JS. It's great that bloggers explain the usages and how it works in different scenarios, but really the better solution would be to not have the problem at all. I would trade overloading for verbosity. An editor can easily squash the latter, where as a human has to train for the former.
Compare Go fuzz to a java fuzzer and there are some interesting differences. For example, in the Go fuzzer, it is looking for panics, not errors. An error is okay, it just perhaps isn't interesting. With a Java fuzzer, it is looking for Exceptions, which aren't as clear. If you get an IOException, is that working as intended, or an actual failure? It's much harder to tell. I attribute this not the the fuzzer, but to the language design decisions.
I tried using Go Fuzz on a small parser I wrote, and was surprised that it found a bug. I was quite pleased, but the input was actually valid, my code was just wrong. One shortcoming of Fuzzing is that it doesn't find Type II errors. It can't find invalid inputs that do succeed. For example, if the input to my parser was actually invalid, but the code didn't crash, the fuzzer would happily continue on. I'm glad I fuzzed my code, but no errors found doesn't mean no errors present.
Adding on to this: iOS doesn't play mp3 for mp4 containers either. Encoding media to play on an iDevice means resorting to AAC, which doesn't have as good licensed codecs.
It's called out in the post: most applications are not written to deal with reads / writes suddenly dropping in throughput. How are you supposed to rate limit the IOPS of a program you don't control? Can you make `docker' do exponential backoff if it notices some operations are taking too long?
In a network scenario, the remote service could say something like Quota exceeded, please try again later. read and write syscalls don't really work like that. They instead remain in uninterruptible sleep, which means they can't wake up, or be killed or stop.