1. 2

    I was originally planning on working on the open-sourcing my framework for building distributed systems, Encore. Unfortunately my MacBook display broke down (a bunch of purple lines across the screen) so need to spend the weekend getting it repaired and setting up my dev environment on another machine. Fun times!

    1. 1

      I’m basically the least lucky guy on the planet and have computer issues constantly, the best thing I ever did was migrate to using a VM for a Dev environment. I can get a more or less full dev-laptop experience, but it’s easier to back up, easier to replicate to other machines if my main one dies, and generally just pretty much the-universe’s-attempt-at-a-better-idiot-proof. Heartily recommended.

    1. 9

      Entertaining article, and whether the author intended it or not I definitely feel there is some truth to it! We can all use a “complexity check” every once in a while. A bit sad with the proliferation of paywalls on Medium, but what can you do :)

      1. 2

        ignore their cookies :)

        1. 4

          Yeah, it’s easy enough to get around; it’s more about what it represents. I’m curious to what degree the authors who post on Medium have a choice in the matter? If it’s entirely up to the article I’m perfectly fine with it, but I’ve been under the assumption that it’s Medium deciding and not the blog authors?

          1. 2

            The author can decline the paywall, but then medium won’t make it findable except by direct link.

          2. 1

            Ctrl-shift-n ftw

        1. 2

          Working towards open sourcing www.encore.dev, the Go framework for rapid backend development I’m building. Many steps to go, but exciting nonetheless!

          1. 1

            I’ve been thinking about this a lot in the context of building cloud-based software, as I’m working on a product specifically to drastically improve developer productivity in backend development.

            There’s an almost endless amount of improvements we could make to the developer experience. I think the real question is: why haven’t we? I think the answer comes down to this: our tools are too general-purpose. The big players are cloud providers, that want to support any application regardless how it’s built. As a result we end up with innovations like containers that further push us towards the “applications are black boxes” end of the spectrum.

            I think we could 10x the developer experience if we started from the opposite end: if we built our developer experience around purpose-built tooling (backend development in my case), and we added constraints to how you write your application, we could infer so much more about the application than what is possible today.

            For example, all of these things you should get for free, with no work needed other than writing your business logic:

            • Build & deployment orchestration, with your whole app running “serverless”
            • Setting up databases, managing connections, passwords, backups, and DB migrations
            • Automatic API documentation based on static analysis of your API function declarations
            • Generating type-safe client code for calling your API for any language
            • Expressing API calls between backend services as function calls (that get compiled into real API calls), and getting compile-time validation
            • Automatic distributed tracing of your whole application
            • Automatic management of production & test environments, and preview environments (for each pull request)
            • Run everything locally with no code changes needed
            • Cross-service debugging
            • Error monitoring, graphing & alerting (observability)

            I could go on :)

            1. 1

              I’m with you on that one :)

              https://m3o.com

              1. 1

                Very cool, I hadn’t seen that one! Will have a look, thanks for sharing!

            1. 12

              FWIW GitLab uses a gRPC based solution (Gitaly) for all Git repository interactions, including Git wire protocol traffic (the Git protocol data is treated as a raw stream). See the protocol definition at https://gitlab.com/gitlab-org/gitaly/tree/master/proto. This allows GitLab to abstract the storage of Git repositories behind a gRPC interface.

              Fun fact: this is how Heptapod (https://foss.heptapod.net/heptapod/heptapod) - a fork of GitLab that supports Mercurial - works: they’ve taught Mercurial to answer the gRPC queries that Gitaly defines. GitLab issues gRPC requests and they are answered by Mercurial instead of Git. Most functionality “just works” and doesn’t care that Mercurial - not Git - is providing data. Abstractions and interfaces can be very powerful…

              1. 2

                That’s interesting! I’ve looked at doing remote Git operations by creating an abstraction over the object store. The benefit is that the interface is much smaller than what you linked to. I guess the downside is higher latency for operations that need several round-trips. Do you know if that has been explored?

                1. 5

                  GitLab’s/Gitaly’s RPC protocol is massive. My understanding is they pretty much invent a specialized RPC method for every use case they have so they can avoid fragmented transactions, excessive round trips, etc. The RPC is completely internal to GitLab and doesn’t need to be backwards or forwards compatible over a long time horizon. So they can get away with high amounts of churn and experimentation. It’s a terrific solution for an internal RPC. That approach to protocol design won’t work for Git itself, however.

              1. 2

                Interesting article!

                The article ponders the hypothetical implications of such a design, and states “There would be no distinction between JSON and html. (What would have been the downstream consequences to API design?)”

                I think this conflates JSON and JavaScript. This would have no impact on JSON as I see it. And even if you had extended JSON to support this, I don’t think it would have changed API design much at all. API design is really about structured, semantic data. Since HTML is so presentation-centric I doubt it would have much impact on API design. There is a reason almost all serialization formats are effectively equivalent to one another.

                In fact, if JSON had such a strong coupling to HTML it might have led to JSON not being widespread for APIs, and a new serialization format winning instead. That might in turn have reduced the popularity of JavaScript as a language.

                1. 3

                  This weekend I was experimenting with building a gitremote-helper using gRPC, to align the authentication with the rest of my infrastructure that’s also built on gRPC. It worked really well! I really appreciate git’s overall architecture and how easy it makes plugging in different components (in this case a transport protocol).

                  This week I’m experimenting with building a web-based debugger using the Debug Adapter Protocol.

                  1. 12

                    I think the whole conversation around “runtime” or “no runtime” is largely a distraction. What matters more to me is: does it allow me to structure my application in a better way, that is more maintainable?

                    In my experience Svelte provides a higher-level abstraction than React or other web development frameworks. It successfully abstracts away from exactly how it works, and provides a logical mental model for how to build web components. Being able to use it for server-side rendering, client-side rendering, or a combination of the two with client-side hydration with no code changes is a breath of fresh air.

                    The concern about inspecting the runtime is mostly a matter of: how buggy and how leaky an abstractionn is it? The fact that we have to do such things regularly is an indictment of the brittleness of most JavaScript frameworks (admittedly the fault is mostly not theirs). It’s extremely rare to have to dig into runtimes for non-web languages (Java, Go, Rust, etc). In my experience Svelte has been unusually stable in this regard, too; I think I’ve had to dig into the runtime just once so far (in several months of daily work with it).

                    1. 3

                      How is it a distraction? Being able to debug live is a serious benefit.

                      1. 1

                        I tried to elaborate in the comment, but you can absolutely debug live with Svelte. The reason I think it’s a distraction is because Svelte succeeds quite well in providing a non-leaky and reliable abstraction, which means I don’t have to dig into the “runtime” or generated code; the bugs are at a higher level. The same way you rarely need to step into standard library functions in Go, Rust, Java, or C++, because they mostly just work.

                        1. 1

                          The same way you rarely need to step into standard library functions in Go, Rust, Java, or C++

                          Hm… But don’t we often have to step into our own functions? Svelte seems pretty water-tight to me when it comes to the actual separation of concerns, but low-level bugs in code can still occur. In my view, either debugging or something equivalent is required for these scenarios.

                    1. 1

                      Working on a better onboarding experience for Encore. I’ve gotten feedback that the product is really simple to use, but many people never actually try it out because you aren’t guided through the process.

                      1. 2

                        Playing some board games today with friends and working on secrets management for Encore.

                        1. 1

                          Hey, I’m the sole author of this project! Happy for any and all feedback, and of course happy to answer any questions!

                          1. 2

                            I literally discovered it yesterday. Looks super interesting and ambitious.

                            1. 1

                              Thanks, that’s really nice to hear :) I’m hoping to open up for the first wave of beta invites next week!