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.

I picked this book up from the library and it is definitely a useful book. About 2/3rds of the book is actual runnable example code.

Also agree totally on Java making concurrency way easier with GC. Russ Cox describes one of these problems here https://research.swtch.com/lockfree

> 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.

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.

Please support FUSE!

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.

The DNA lounge tried something similar, but to the other extreme. They put computers with internet access in their club.

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.

Once we have reproducible builds, will it be possible to have verifiable builds? As in, can we cryptographically show that source + compiler = binary?

Right now we can sign source code, we can sign binaries, but we can't shows that source produced binaries. I would feel much happier about installing code if I knew it was from a particular source or author.

If the perf of gRPC is not good enough, you should file an issue on Github. I'm kind of surprised that gRPC loist by 2x. That's about how much better netperf is.

When you say you used Cap'n'proto, did you mean the RPC and serializer, or just the serializer? I ask because gRPC's serialization is pluggable, and doesn't have a dependency on Protobuf.

> Tech Details

> The SPIF format starts with a header that tells the offsets and sizes of the images in the SPIF. The images are stored smallest first, but there are no image size restrictions apart from that.

So... two HTTP requests per image load? That is probably going to hurt more than it helps. Also, that probably means a Range request, which don't have great support. (For example, the builtin Python http server SimpleHTTPServer doesn't support them.)

For the same reason people use JSON. It's simpler, and there is a fast parser built into the browser. Even non browser clients have optimized JSON coders which is good enough.

That said, JSON is still slower and more bloated than Protobuf, and you get Protobuf for free when using gRPC.

Do you use the Java generated stubs or generate your own? There are several people using gRPC with Scala that could benefit from more idiomatic stubs.

Surprisingly, the reason why gRPC JS web support doesn't exist is because of Chrome. There is currently no way to access the HTTP trailers from Javascript. gRPC depends on trailers to tell when an RPC is complete when doing bidirectional streaming.

Please tell browser devs to provide access to them! They have been part of the HTTP spec for years. Only recently have browsers entertained the idea:

https://bugzilla.mozilla.org/show_bug.cgi?id=1339096

https://bugs.webkit.org/show_bug.cgi?id=168232

https://bugs.chromium.org/p/chromium/issues/detail?id=691599

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

gRPC is slow with Python, but most people don't pick Python if they are serious about performance. gRPC has continuous benchmarks running[1] to track and improve perf. I agree the Python one has some serious problems, but don't let it be the whole story. The C++ implementation is 100x faster.

[1] https://performance-dot-grpc-testing.appspot.com/explore?das...

To be honest, I can put up with the less than graphics. What really got me was the regular hangs that would happen. I spent a fairly long time trying out different things to debug it, and eventually reported the hangs to the DRM list. While they were helpful, their answer was to update my kernel. It worked, but I am not comfortable having to run at head just to play old video games.

Dumb question: the remote side need to enable it too, right?

Intel driver support is pretty bad. If you aren't running with i915 at close to head there are easy to hit graphics bugs. Running most Steam games on Linux yields much worse performance and stability than running the same games on the same hardware with Windows.