Gopher Academy publishes community articles about the Go language, covering servers, parsers, dependency management, and garbage collection.
HN links it for guides like exposing Go directly to the internet, which its author says is somewhat dated, and a Go versus Rails piece.
There is a project called Peermaps that is building a full P2P stack for OSM-based maps:
They convert Planet OSM and Natural Earth OSM dumps into the storage format used by their geospatial DB [1] and then distribute them using P2P file storage tools like IPFS [3] or hyperdrive [4].
Because those storage tools make use of content addressing [5] and clever chunking [6], you can download only changes to the (converted) OSM dump.
Because those tools are inherently P2P-focused and come with pluggable transports, the data representing the changes in the (converted) OSM dump don't have to be sent via the internet. For example, Mapeo [7] allows syncing "local" changes to OSM via USB sticks [8].
[1] https://github.com/peermaps/eyros
[2] https://github.com/peermaps/data
[3] https://ipfs.io/#why
[4] https://hypercore-protocol.org/guides/modules/hyperdrive/
[5] https://docs.ipfs.tech/concepts/how-ipfs-works/#content-addressing
[6] https://blog.gopheracademy.com/advent-2018/split-data-with-cdc/
[7] https://www.digital-democracy.org/mapeo/
[8] https://docs.mapeo.app/complete-reference-guide/mapeo-desktop-use/using-mapeo-desktop-to-manage-mapeo-mobile-data/syncing-data/synchronizing-with-a-file
I'm one of the Core authors of the Kite library (library for writing micro services). I wrote an extensive introduction here on GopherAcademy: http://blog.gopheracademy.com/birthday-bash-2014/kite-microservice-library/
I think Gotalk and Kite have a lot of common (for example we have also kite.js, to talk with browsers). The mission of the Kite library is the same as with Gotalk, mainly to communicate two pieces of software in an easy way. However in order to achieve this Kite also has an inbuilt service discovery mechanism. I think this is really important because with time you are app number will increase and service discovery is a must have. There are many differences too, for example protocol (we use JSON).
Congrats on shipping this, I'm really looking forward to see how it evolves and how you solve upcoming problems (such as poor network conditions where Websocket badly fails).
crypto/tls is designed and developed to be fit to be exposed directly to the Internet. The advice I wrote here is mostly dated (I really need to write a follow-up), but it's still indicative: https://blog.gopheracademy.com/advent-2016/exposing-go-on-the-internet/
[Updated to add] TLS 1.3 is opt-in because despite years of improvements, it can still hit compatibility issues with broken or legacy peers. (Search for "TLS 1.3" on the Go issue tracker if you are curious.)
0-RTT is blocked on figuring out good, safe APIs for it. I feel like I am 80% of the way there for servers (just have to figure out how to make it opt-in per http.Handler instead of opt-out), while for clients I have no idea how to fit resending in io.Writer.
Well, the parameter of a Timer is of type Duration:
A Duration represents the elapsed time between two instants as an int64 nanosecond count. The representation limits the largest representable duration to approximately 290 years.
Which is not really good because we have to calculate the time between now() and Saturday. If "wall time" changes, the scheduler will not be triggered when expected.
In that case I would not rely on Timer to use it in a cron-like fashion, or trigger a Ticker every second, check the _current_ wall time, and decide if anything needs to be done.
You can read more about Timers, Tickers and Sleeps in this (pretty interesting) article[1]
[1] https://blog.gopheracademy.com/advent-2016/go-timers/
Re: showing bottlenecks, the Go latency tracer may be a neat reference point; it doesn't find serial parts automatically, but it shows the execution timeline so that you can see them. Besides serial bottlenecks, it can be useful for seeing where you blocked waiting on I/O and so on:
https://blog.gopheracademy.com/advent-2017/go-execution-tracer/
There might already be similar tools for Rust; I know less about what's available there.
(Go folks also added some tools for tracing across RPCs, which is less relevant to what you said but just kinda independently neat: https://medium.com/observability/debugging-latency-in-go-1-11-9f97a7910d68)
I like Go, and I am replacing aspects of Rails apps with Go, but for a lot of web app uses, Rails is really, really good.
Hashicorp, who has a very high Go competence, migrated away from Go to Rails for their web service.
http://blog.gopheracademy.com/advent-2014/atlas/
> Once we decided to evaluate other technologies for our web service, we had a few choices. Based on having Rails experience and the maturity of that tooling we saw it as the most pragmatic option. As we began our initial port, we realized that over two weeks worth of work in Go had been replaced in just a few hours in Rails. We were sold.