I really like this proposal. It is simple, minimal and addresses the main point of complaint which people have about error handling in go (verbosity).
I have no problem with encouraging errors to bubble up, as there is a clear flow of control and errors must be handled at the appropriate place in the chain (usually one or two levels up).
Wow, impressive work. Thanks for posting this. For the curious there is more detail about this standard over here:
https://facebook.github.io/zstd/
It seems to focus on small data, and can be trained for specific data which is really interesting (and potentially useful for things like image or html compression specifically) - sounds similar to brotli in that sense:
To solve this situation, Zstd offers a training mode, which can be used to tune the algorithm for a selected type of data. Training Zstandard is achieved by provide it with a few samples (one file per sample). The result of this training is stored in a file called "dictionary", which must be loaded before compression and decompression. Using this dictionary, the compression ratio achievable on small data improves dramatically.
How would you compare the two, brotli and zstandard? I see they have a table where zstd edges out brotli in speed, but brotli seems to have browser adoption.
An interesting perspective - I'm not sure I agree with some of these examples though, I think they run counter to the culture of Go, which is mostly based on simplicity. To take one example:
Wrap all primitives and Strings in classes
I don't think it's useful to wrap integers and strings in types, it's a level of indirection that's not required except in very extreme cases. Defining a type for productID would be a very odd thing to do in most cases I imagine, especially if it only has one or two methods. Why not have methods on the containing type instead which manipulate productID as required?
This comparison is a little thin. I'm not sure it's a compelling case for Go, or even if one could be made against these other languages - the advantages of Go as opposed to other languages are mostly down to the reduced possibilities, culture of simplicity and simple code rather than capability.
This looks really interesting - using Go to construct pipelines for processing biological data (DNA Sequences etc), a fascinating field which is seeing huge transformations as technology is applied to it. Thanks for posting, are you using sci-pipe at the moment?
I really like this proposal. It is simple, minimal and addresses the main point of complaint which people have about error handling in go (verbosity).
I have no problem with encouraging errors to bubble up, as there is a clear flow of control and errors must be handled at the appropriate place in the chain (usually one or two levels up).
Wow, impressive work. Thanks for posting this. For the curious there is more detail about this standard over here:
I don't think it's useful to wrap integers and strings in types, it's a level of indirection that's not required except in very extreme cases. Defining a type for productID would be a very odd thing to do in most cases I imagine, especially if it only has one or two methods. Why not have methods on the containing type instead which manipulate productID as required?
This comparison is a little thin. I'm not sure it's a compelling case for Go, or even if one could be made against these other languages - the advantages of Go as opposed to other languages are mostly down to the reduced possibilities, culture of simplicity and simple code rather than capability.
They're planning releasing the source code at some point, but it's not available yet.
This looks really interesting - using Go to construct pipelines for processing biological data (DNA Sequences etc), a fascinating field which is seeing huge transformations as technology is applied to it. Thanks for posting, are you using sci-pipe at the moment?