morecoffee

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.

print() is a nonstandard function and will be removed eventually.

Why would it be surprising? Manufacturers optimize for cost. The clock in your computer is the cheapest one they can find.

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.

It would have been much more prudent if the committee defined the behavior in a way amenable to optimization, rather than asking for a blank check.

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.

Is the data still Linked In's once it leaves the server though? Hopefully the court will find that the answer is no.

Not justifying, but waterproofing a phone is very hard if it has holes in it.

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.