-
Three.js is a great javascript 3d library, but it’s hardly new. In case you are just discovering it, may I suggest the following:
-
This zero-copy approach to serialization is similar to capn proto, although the latter includes a nice rpc framework. A related comparison blog entry is here: https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html
I’d be interested if anyone has tried them as well as protobuf3. Does the new protobuf3 more efficiently transfer large byte arrays? I’d like to use something like gRPC for syncing servers but assume protobuf3 will add too much overhead for my messages (large % is just binary blob data).
-
-
proto3 should have roughly the same size as proto2. But you can always compress… although, looking through the grpc site, it’s surprisingly difficult to find a succinct description that includes whether compression is available/on-by-default/not-implemented-yet. Anyone know?
-
-
Murat, whose blog I’ve grown to appreciate and wish I had more time to read, reviewed this paper and listed a couple of related works.
-
This is my favourite:
Why should the compiler go to all the trouble of validating an interface implementation when you, the programmer, can do it manually? Compiler time is expensive if you are solving big problems.
There is a lot to like in Go: Channels, tuple returns, fast compile times, garbage collection for example. But there’s also a lot of terrible, and the absolute ubiquity of the empty interface should speak for itself about the need for generics.
-
I particularly disagree with that section on interfaces. If you force a type to declare it implements an interface, it makes it more difficult to reuse a 3rd party package. By having implicit implementation of an interface, which the compiler figures out for you or prints an error when you try to use it as an interface you haven’t really supported, you don’t have to alter the code of that 3rd party package. It’s a feature and one that’s been cited repeatedly for its utility. The compiler does validate whether a type properly implements an interface. Empty interfaces should be used with discretion. Yeah, it would be nice to have generics, but Go does allow code generation.
-
-
Who said anything about forcing a type to declare it implements an interface? This is a completely false dichotomy. There’s no reason you can’t allow implicit and explicit interfaces.
All languages “allow” code generation, so I don’t see why that is at all related to whether or not generics are a good thing.
-
-
-
DocSavage
3 years ago
|
link
| on:
84% of a single-threaded 1KB write in Redis is spent in the kernel
I’ve been watching Seagate’s Kinetic Platform, which is basically a reworking of a disk drive to directly accept an ethernet connection and expose the disk’s native storage system as a more closely-aligned key-value store API. It tries to remove metadata/filesystem handling latency from the I/O.
Among the cool things this system allows: direct transfer of key-values from one drive to another.
-
It is highly likely that I don’t know what this should be used for, but I think some of the limits might be a bit, er, limiting: https://developers.seagate.com/display/KV/Kinetic+Open+Storage+At+A+Glance
“Limits The key/value entries are limited in size to 4-KiB keys and 1-MiB values.”
ie. You can’t store a photo or a music file in a single value.
-
That’s not a problem. Many key/value stores limit the maximum size of values and depend on a layer above it to break down larger files into the 1MB chunks. FoundationDB, for example, has a “blob” layer that does exactly this. Also, the layer above it would want to do some kind of replication or erasure coding in case a drive fails. The fault tolerance is better if you break large files into small pieces and distribute them across a number of drives.
-
-
I’ve been impressed with the recent commit activity for cockroachdb. After FoundationDB got taken out by Apple, it’s clear there’s a need for an open source database with solid distributed transactions. The fact that it’s in Go makes this even better: easier to read the code and possibly extend it at the code-level using Go interfaces, without modifying one line of their code. Hope they host some technical talks as well.
Yes, this is exciting! It’s hard to know how big it’ll be, but it’s got a lot of potential.