Wow, impressive work. Thanks for posting this. For the curious there is more detail about this standard over here:
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?
We found Go to be an excellent choice for this type of tool, as we could make very good use of the built-in concurrency primitives, and also of course benefit from the general robustness, performance and the tooling around the language.
We have used SciPipe in our latest study at pharmb.io , on building machine learning models to predict hazard in drug molecules (see dx.doi.org/10.3389/fphar.2018.01256). I have since transitioned into industry for the moment, but plan on using SciPipe on some research projects on my own, and also my colleagues at pharmbio are interested in applying it on some upcoming projects. Hoping to see some more people play with / adopting it. :)
Btw, I should also mention that although SciPipe was created out of needs in bioinformatics and cheminformatics, I have found it to be a handy tools also for tasks that are very general in terms of data processing, especially since it allows an easy way to mix and match various GNU *nix commandline utilities with components written in Go. One example of this is how we wrote a small pipeline to download, unzip and parse a somewhat large XML dataset, using commandline tools combined with Go code for the actual XML parsing (See the code example at the bottom of this post: bionics.it/posts/parsing-drugbank-xml-or-any-large-xml-file-in-streaming-mode-in-go ).
This is a really interesting article as it points out some of the differences between Java and Go - doing a port of a large codebase will really show up which areas, though of course it will also lead to writing Java in Go to some extent. It would be interesting to know the reasons for the port, did they want to replace the java version, or is it to sit alongside it?
Shows how important testing is to be confident that a port like this is working, and how it can help guide you through a big project.
The query builder was interesting as I've taken a different approach to this. I like the chaining approach to building queries, but it's perfectly possible to do this while returning an error for the functions that matter (the ones which fetch the data). You just have to separate out the query building (which returns a query) from the error returning functions (which typically return results, error). Then the stateful error is not necessary.
Interesting note on getters and setters - I've found this refreshing coming from other languages where this is the norm (Java, Ruby, Obj-C) - it's more a cultural thing than a requirement, and I can count on one hand the number of times I've truly needed a getter or setter, in which case I can make the field private and write one. Getters and Setters seem like unnecessary encapsulation to me given the amount of ceremony required.
Function overloading - I can't say I miss this much, if functions become too verbose it's usually a sign there is something wrong and you're trying to do too much with too many variables. Another approach you can use if passing pointers not types is to allow a nil pointer.
Thanks for posting, I really like this series, even if I haven't used PHP much.
Often people have trouble adapting to a new language if they're really familiar with another one - the idioms, libraries and built ins are all so different, and it makes you realise a language is more than just a syntax, it's the culture, the libraries available etc.
Another area people might want isset is params coming in to a web endpoint, so yu might want to cover that in your examples.
Came here to submit it but have found this old story.
This is a really good summary and is similar to my reaction to the Go Generics proposal - nice to see it being added, but it feels a little obtuse in the current incarnation, and not as simple as other parts of the language. I'd rather see them explore extending interfaces rather than introducing an entirely new metalanguage to describe relations between types.
The article is not very good, as some of the points made are just wrong ( the whole part about VMs for example). It seems that this is just the result of a short internet search without much in the way of understanding.
I guess it is notes from someone without a great deal of experience with the language, so in that sense it is useful, but I agree it could do with a lot more depth, in particular if the author had built something significant in Go before writing it would help. I'm not sure it aspires to the level of an in-depth language critique though, it's more a light gloss on the language from the point of view of a beginner.
Re VMs, yes I'm not sure what that section is about, I guess they took the fact it doesn't use a VM then ran with that, but came to the wrong conclusions, as a quick comparison of Java programs with Go programs would tell them.
It's interesting that many of the cons can actually be considered pros if seen in the right light, for example 'too simplistic' is not how I see go, at all, it is certainly radically simple in that it jettisons a lot of features deliberately as they are harmful (foremost among them inheritance, which I think was the right call), but it also misses out things which are seen as features in some other languages (like generics or tail calls). I would like to see them tidy it up for Go 2 though, and make it simpler, rather than more complex. Simplistic is not the right word for the deliberate simplicity of Go IMO.
Seems to be a lot of drama around dep. I don't like the way that rsc handled that situation at all (he would have been better not pretending to consult, and not trying to bring dep into the fold as a semi-official experiment). Calling it an official experiment and holding meetings with Sam made it seem like there would be significant input from the dep team, but that never happened. So lessons to learn for everyone, but give the structure of the Go team and Russ's place in it, it seems unlikely dep has a significant future.
a very fast persistent real-time key-value store, that uses the same RESP protocol and capable to store terabytes of data, also it integrates with your mobile/web apps to add real-time features, soon you can use it as a document store cause it should become a multi-model db. Redix is used in production, you can use it in your apps with no worries.
It does look like the vendoring stuff is only there to satisfy backwards compatability, not for new usage. It's supported but now I've gone to look there are some caveats in the docs and on the wiki, hinting that you shouldn't use it. Files in vendor are ignored it seems unless you pass a special flag, so a lot of people are going to be very confused (including the author of this article). The communication around this tooling change have not been great, and that's why guides like this are springing up. Now that it is getting more complex, Go could definitely do with some more short and simple getting started guides from the Go team, for specific topics like versioning, where people also bring in their assumptions about how things work from other tools.
Since this is still in beta, and seems pretty half-baked, I'm not going to touch it for at least another version of go, but hopefully once they have the kinks worked out it'll be a reliable method to specify dependencies that everyone uses.
Thanks for posting the video. I haven't experimented with go modules yet, waiting till it stabilises before moving over to using it. Have you see any problems with it at all?
I've edited the title to use 'Video:', and to fix the issue with the # character - we use that for tags, so I'm afraid it breaks if you try to use that in a normal title, as it turns the word afterward into a tag instead. Hope that's ok.
Not sure I understand the need for this - if you are using containers it should be for instances which can die and you don't care what happens to them after. People sometimes put stuff in containers that they shouldn't (document storage, databases), which would be better hand-managed or using a central service for.
How many mobile apps are there now? There are very few really good ones. But the best are selected in the tops. Sometimes even bad bad apps are very popular. This is all thanks to services for the promotion of mobile applications. They help them to do it. I know ios app marketing service. I once used it and liked the result. Everything was very high quality and fast. After a few months, the money spent was back. All thanks to their help.
Thank you so much. Development is our future. It's hard to create something new, but it worse all spent. My friend created really great mobile app, but it wasn't popular. Then some people recommended him to buy app reviews ios in the service. After that, his business became better and this helped him to attract customers.