The only slightly worrying bit of the article is this one:
This does introduce a chance of key collision, that’s something we plan to deal with later.
So I guess you can't store any sensitive user information in this as yet, as their hashes have more chance of collision. It would be good to know what the chance is.
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.
This is not very well written, but I thought might be interesting for people to pick apart. The main mistake was not closing the response body if performing get requests..
Tired of Makefile hacks? Bazel offers fast, reproducible builds for software of any size. Why is it better than go build? Bazel makes polyglot projects easy, has remote build workers, and shared caching. Get started building Go projects, learn key concepts, and get ready to turbocharge your build.
Thanks for the slides, it doesn't look like the challenges are insurmountable, most of the things outlined in the slides are not so much lirbaries as organising your code to avoid circular dependencies (a good thing anyway), and which data store to use, which is a problem any app faces, I don't think it's esp. hard on Go. It would be nice if we had a better abstraction in database/sql so that this was the only package you used, but it's not bad.
This is a little short. It'd be nice if it had some more detail on the different options for logging and the tradeoffs involved. For example for some apps you want to log to a file so you have something to inspect, for distributed apps you probably want to centralise your logging somewhere - log to stdout and have the logs shipped somewhere else, or send them from the app to another server. This just goes over the basic usage of the log pkg, which is pretty straightforward anyway.
The only slightly worrying bit of the article is this one:
This is a really good article, just came across it after a tweet from Dmitry Vyukov. A little out of date now probably though.
Go is still very popular with its users it seems.
Not much go here? This seems to be more about how to get AWS working with Alexa.
This is not very well written, but I thought might be interesting for people to pick apart. The main mistake was not closing the response body if performing get requests..
Thanks for the slides, it doesn't look like the challenges are insurmountable, most of the things outlined in the slides are not so much lirbaries as organising your code to avoid circular dependencies (a good thing anyway), and which data store to use, which is a problem any app faces, I don't think it's esp. hard on Go. It would be nice if we had a better abstraction in database/sql so that this was the only package you used, but it's not bad.
This is a really fun idea for a website, it's a shame we can't use the avatars here - it'd be nice if each poster had their own avatar automatically.
This is a little short. It'd be nice if it had some more detail on the different options for logging and the tradeoffs involved. For example for some apps you want to log to a file so you have something to inspect, for distributed apps you probably want to centralise your logging somewhere - log to stdout and have the logs shipped somewhere else, or send them from the app to another server. This just goes over the basic usage of the log pkg, which is pretty straightforward anyway.