Hey, I'm the author of Jocko. I've been working at Confluent the past four years.
I just finished writing a book that shows how to build similar distributed services from scratch, it walks though building a simple distributed commit log with built-in consensus and service discovery from nothing to deployment: https://pragprog.com/titles/tjgo/distributed-services-with-g...
I'm not sure, I haven't heard of that happening before. I've asked my editor if she knows what's up. You can email me at tj at my HN username dot com if you want to follow up.
People that are interested in this blog post will interested in a book I wrote: Distributed Services with Go (https://pragprog.com/titles/tjgo/distributed-services-with-g...). The book walks the reader through building a distributed event service from scratch that uses Serf as a library for its service discovery.
This issue has been open since 2017 and it's not panacea since it comes with its own -substantial- tradeoffs which is why as far as I know, magit is not "switching to libgit2" but planning to offer libgit2 as an additional option. Also for such an important feature, rather than going with FFI, it would be much better if Emacs linked with libgit2 (similarly to the improved JSON support in 27). That way the core Emacs development team would review all code and have a say in its design. That also implies magit being bundled with Emacs (or at the very least available in ELPA) which may not be realistic in terms of copyright assignment / code quality concerns.
Performance issues aside, a pure Lisp magit is the simplest and more universal setup which is why an attempt to fix the process spawning problems there should be made.
They would be reviewing the C interface to libgit2, not Magit itself, since -you know this- C code written either to work through FFI or as part of Emacs can potentially corrupt memory and destabilize Emacs in serious ways. Code written in Emacs Lisp, even low quality code, does not generally suffer from these issues.
So yes, I'd much prefer C code that Daniel Colascione / John Wiegley / Eli Zaretskii / Stefan / Paul .. have reviewed over newly-written FFI code that hasn't been through that thresher. Everyone that jumped on the emacs-libvterm train early knows what I mean.
I keep Emacs running for months at a time and it's the foundation of pretty much everything I do on a computer. Other than the OS, it generally is the most stable, continuously running, continuously stressed piece of software that I have ever used.
I'm currently writing a book for PragProg called Building Distributed Services with Go (though it mostly applies to other languages too) that's walks you through building a distributed database from scratch. You can sign up on this mailing list to know when it's available: https://travisjeffery.us4.list-manage.com/subscribe?u=1e3ff7....
Yeah I'm discussing with my editor now about when to put out the beta it'll be out either after we finish editing the chapter I just finished writing or the next one. So pretty soon. I hope to have the whole book finished by July but that's a bit more TBD up to how soon I finish writing the last few chapters.
I'm currently writing a book for PragProg called Building Distributed Services with Go (though it mostly applies to other languages too) that's walks you through building a distributed database from scratch. You can sign up on this mailing list to know when it's available: https://travisjeffery.us4.list-manage.com/subscribe?u=1e3ff7...
Yeah---each chapter begins with background on the chapter's topic, some theory, covers how and where you'd use what's we're talking about in the chapter and then we use it to build a part of the project we're building throughout the book. For example, in the consensus chapter we talk about what problems it solves and how you can use it in your projects,and then we implement Raft in the service for leader election and replication.
First of all I think it's cool enneff read my post.
But pkg doesn't only make your import paths unwiedy. I'ts more like that's the only---or at least main---issue with pkg. But you get benefits from it that I talked about: consistent layout structure; know what directories are packages; separate your packages from examples, docs, etc. If pkg only made your import paths unwiedy then no one would use it.
Hey, I'm currently writing a book for PragProg that's going to announced soon. It's tentaively titled "Building Distributed Services with Go", and the Go part is secondary if it's not your language of choice. It guides you through building a distributed service from beginning to end. I don't have anything to point you to at the moment other than my mailing list and I'll let you know when the book is in beta: https://travisjeffery.us4.list-manage.com/subscribe?u=1e3ff7.... Thanks.
Here's a list of prominent Go infrastructure projects and by no means a complete list: Kubernetes, Docker, Etcd, Consul (and the rest of Hashicorp's projects), CockroachDB, Prometheus, TiDB. Maybe I'm just blind to C# but I don't remember coming across a single similar project that's written in C#.
None of this is relevent and or even close to be as popular as the previous tools mention in Go, just k8s and Docker crush your entire list. Another very popular one is Grafana also written in Go.
In correct English one would state fully, completely written in X.
Modern stacks are seldom pure blood language X, thus if 5% of it is written in Y, the product is written in a mix of X and Y.
Which I also mentioned on my comment, "Yep, they aren't pure C#", naturally overseen when one intends to champion its language as "Year of Desktop Linux" on IT infrastructures.
I just finished writing a book that shows how to build similar distributed services from scratch, it walks though building a simple distributed commit log with built-in consensus and service discovery from nothing to deployment: https://pragprog.com/titles/tjgo/distributed-services-with-g...