bokwoon

[19:14] why not C#?

Dimitri: Was C# considered?

Anders: It was, but I will say that I think Go definitely is -- it's, I'd say, the lowest-level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In C#, it's sort of bytecode first, if you will; there is some ahead-of-time compilation available, but it's not on all platforms and it doesn't have a decade or more of hardening. It was not geared that way to begin with. Additionally, I think Go has a little more expressiveness when it comes to data structure layout, inline structs, and so forth. For us, one additional thing is that our JavaScript codebase is written in a highly functional style -- we use very few classes; in fact, the core compiler doesn't use classes at all -- and that is actually a characteristic of Go as well. Go is based on functions and data structures, whereas C# is heavily OOP-oriented, and we would have had to switch to an OOP paradigm to move to C#. That transition would have involved more friction than switching to Go. Ultimately, that was the path of least resistance for us.

Dimitri: Great -- I mean, I have questions about that. I've struggled in the past a lot with Go in functional programming, but I'm glad to hear you say that those aren't struggles for you. That was one of my questions.

Anders: When I say functional programming here, I mean sort of functional in the plain sense that we're dealing with functions and data structures as opposed to objects. I'm not talking about pattern matching, higher-kinded types, and monads.

[12:34] why not Rust?

Anders: When you have a product that has been in use for more than a decade, with millions of programmers and, God knows how many millions of lines of code out there, you are going to be faced with the longest tail of incompatibilities you could imagine. So, from the get-go, we knew that the only way this was going to be meaningful was if we ported the existing code base. The existing code base makes certain assumptions -- specifically, it assumes that there is automatic garbage collection -- and that pretty much limited our choices. That heavily ruled out Rust. I mean, in Rust you have memory management, but it's not automatic; you can get reference counting or whatever you could, but then, in addition to that, there's the borrow checker and the rather stringent constraints it puts on you around ownership of data structures. In particular, it effectively outlaws cyclic data structures, and all of our data structures are heavily cyclic.

(https://www.reddit.com/r/golang/comments/1j8shzb/microsoft_r...)

EdgeQL:

    select Child {name}
    filter .<child[is Parent].name = 'Uma Thurman';

    select child.name
    from child
    join parent_child_rel using (child_id)
    join parent using (parent_id)
    where parent.name = 'Uma Thurman';

- Neovim's native LSP (with the neovim-lspconfig plugin) handles completions, go-to-definition, linting, formatting and refactoring. (Here's my init.vim config for the LSP https://gist.github.com/bokwoon95/d9420fce4836f6b518b02bd60a...).

- Instead of trying to get an autcompletion plugin to work, just use vim's native omnicompletion <C-x><C-o>.

- Instead of a plugin manager, use Vim8 native packages (https://vi.stackexchange.com/a/9523). I use a custom shell script for updating plugins via git (https://gist.github.com/bokwoon95/172ecc04039afdbe9425678946...)

- I use Fern.vim for a file explorer.

- I use Telescope.nvim for fuzzy jump-to-file.

- Dynamic statusline is just a few lines of config (https://gist.github.com/bokwoon95/d9420fce4836f6b518b02bd60a...), no statusline plugin needed.

- No debugger support, I'll use a CLI debugger or an IDE if I need one.

I've been using this setup for very a long time, and I barely touch my init.vim anymore. Here's a recent thread from the neovim subreddit where the OP talks about how much effort it takes to properly setup a configuration framework https://www.reddit.com/r/neovim/comments/11p6iiu/i_love_vim_...:

> I want to fix my problems and consolidate my environments BUT setting it up is too painful and I don't another hobby as a job (I already have servers and a 3d printer lol). I've tried multiple times this week to setup either pure neovim, lunarvim, nvChad, astrovim and LazyVim starter and there's always something that I can't find how to change even after searching online and not even taking into account that setting it up takes like a day for each. I don't really want to dedicate a whole month to reading docs, debugging and discovering plugins to fix issues that i'm hitting and I don't wan to blindly learn some commands to then throw them away because that distro didn't work out.

Hmm you've certainly given me something to think about. Thanks.

BTW joins are not challenging, but you made me realize I didn't show any joins in my basic examples. Here is an UPDATE with JOIN in the meantime: https://bokwoon.neocities.org/sq.html#postgres-update-with-j....

Example of a query builder with built-in mapping capabilities (it’s mine):

https://github.com/bokwoon95/sq

I feel some exasperation when I see query builders that throw a query string back to the user and ask them to map the results themselves. That’s easily the most tedious and mistake-prone part of using SQL queries. In the case of my library, projection and mapping are handled by the same callback function so in order to SELECT a field you basically map it and it’s automatically added to the SELECT clause.

GitHub doesn’t use foreign keys, the cascade delete must have been manually implemented.

https://news.ycombinator.com/item?id=21486494

In the older version of the proposal, -> was identical to ->> except -> returned NULL on malformed JSON (while ->> raised an error). Both -> and ->> would automatically convert a JSON-encoded SQL string '"like this"' into an SQL string 'like this'. This is not how the -> operator behaves in Postgres and MySQL, and my examples were simply trying to point out that incompatibility.

NoSQL can model relational data, but it is not a relational model (as understood by E.F. Codd).

Also, NoSQL data access patterns are pretty much set in stone, which is kind of what the relational model explicitly avoids.

https://gist.github.com/bokwoon95/4fd34a78e72b2935e78ec0f40e...

OOP inheritance does not belong in this pattern, even if you could hamfist it in (which you've already observed as unwieldy).

That's a feature for developers, not consumers. Consumers will be unhappy if you tell them your mobile app doesn't exist on the app store and must be downloaded from some third party website.

I would love to be able to "sleep" while preserving consciousness. Willingly losing consciousness terrifies me. It's like death. You are physically unable to observe the moment you transition from consciousness to unconsciousness, because observing inplies consciousness. Sleeping is basically leaping into the void.

If you want a coherent mental model of git, just do https://learngitbranching.js.org/ and never look back.

"You want one layer to handle user input and get it into a normalized form. You want one layer to do your actual task. And you want one layer to handle formatting and output to the user. Those are the three layers you always need."

The "do the task" layer can be abstracted again further. But starting it off as a monolithic layer, separated from input and output, is always the right call.

https://github.com/bokwoon95/go-structured-query

It was created to solve one of my pain points about scanning columns into deeply nested structs. You have full control over what columns gets mapped to what struct field, no annotation-based reflection needed. The type safe query building part was inspired by jOOQ (https://www.jooq.org/doc/latest/manual/getting-started/use-c...)

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction.

This is like those literature memes where the teacher conjures up a fantastic narrative trying to guess what the author meant when he really just meant that "the door is red".