Ethan @ firelizzard @programming.dev

Principal Engineer for [Accumulate](https://gitlab.com/accumulatenetwork/)

---

Read more

Posts

7

Comments

207

Joined

2 yr. ago

As my first job out of college (when I didn't know what I didn't know) I was hired to build a bespoke inventory system for a manufacturing company. My prototype became a production system the second I showed it to one of the engineers. The next three months of my life were a living hell as I frantically fixed bugs on a live system. Lesson learned.

Counterpoint: knowing a programming language doesn't matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can't do that as a intermediate to senior developer, you're not a competent programmer IMO.

The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you're only a skilled developer in the languages you know - if you aren't capable of pivoting those skills to another language - you aren't a skilled developer IMO.

Maybe these days. That definitely was not true when I was growing up, or even a decade ago.

I find it very hard to believe that AI will ever get to the point of being able to solve novel problems without a fundamental change to the nature of "AI". LLMs are powerful, but ultimately they (and every other kind of "AI") are advanced pattern matching systems. Pattern matching is not capable of solving problems that haven't been solved before.

Linus might be an asshole but he's actually competent. Elon Musk is a fucking joke of a person. Not to mention Linus hasn't done anything that compares to things like Elon suing his way into being a "founder" of Tesla and kicking out the actual founders.

I could use Google but I’m looking for opinions not just what journals have that kind of content

Of course I don’t browse the web with the command line.

That's my point. Browsing the web with a command line tool is obnoxious - you use a GUI for tasks that you find easier/more pleasant to do with a GUI. The difference is where that line is. When I'm reviewing what work I've done and checking through my code for debugging statements and other cruft I don't want to push, I prefer to have a nice tree view of my change set where I can click on an item, see what I've changed, select lines and stage them, select other lines and revert them, etc. I could do all of that with command line tools (though not that many have mouse support) but I already know how to do exactly what I want with VSC so why would I use anything else?

You’re already programming! Just learn the tool!

If someone is incapable of learning the tool, that's an issue if they're a developer. But your statement implies that everyone should use the CLI for everything. My point is that it's a matter of preference. The CLI is not superior and GUIs aren't superior. They're both just tools and if you can get your job done quickly and efficiently, that's all that should matter.

I have 13 followers on GitHub. A few are friends from college, the rest I have absolutely no clue why.

Do you use the command line for everything? Do you edit with vim, view diffs with git diff, browse the web with links or lynx?

GUIs are useful tools. I’m happy with VSCode’s git integration. It’s just what I need for basic stuff like staging files and committing. I use the CLI whenever I want to do something like rebasing because I can type that command faster than I can figure out the GUI, but it would be stupid to artificially force myself to use the CLI for everything because of some kind of principal.

Part of it is an HTTP/RPC interface, but that's not the party I want to test.

I don’t think you really have a choice TBH. Trying to do something like that sounds like a world of pain, and a bunch of unidiomatic code. If you can’t actually support 4 to 10 languages, maybe you should cut back on which ones you support?

To be clear, the SDKs themselves are hand-written; I'm not trying to do anything fancy there. In terms of designing and writing the SDKs, we can manage that for the 4 we have now. The issue is testing. The main system is a collection of services that are accessed via an API. That API can be accessed directly through function calls, or via HTTP or RPC. Our integration tests interact with the system through that API. The SDKs have a moderate amount of logic so they're not simple HTTP/RPC clients, but maintaining multiple (idiomatic) versions of that logic is not too much of a burden. The issue is that I want a single test corpus that I can use to validate each SDK without having to rewrite that test corpus in each language. Ideally I'd like the integration tests to be that test corpus.

If neither of those approaches works, everything speaks C FFI, and Rust is a modern language that would work well for presenting a C FFI that the other languages can use. You’re probably not hot on the idea of rewriting your Go tests into another language, but I think that’s your only real option then.

I was assuming I'd need to rewrite my tests in Go given that Go's FFI support for anything other than C is not somewhere I want to go again. I have been meaning to learn Rust so I might just do that.

I'm definitely not interested in convincing you to change your mind but I do want to reply to some specific items.

the number of users in groups

The only limitation I can find is that top-level groups on the free plan are limited to 5 users. Granted, there are certainly reasons to keep a group private, but public groups are not limited.

moving some basic free features into premium like protected branches, code owners, issue dependencies, epics, roadmaps

Protected branches are available for all plans. I'm pretty certain the rest of the features you mentioned were never free. You can disagree with that choice, but it is incorrect to say they were moved into premium.

I saw in other comments that you aren't happy with the direction GitLab is going in and feel that they're focusing on business customers at the expense of open source users. Can you expand on that?

The project I am working on joined the GitLab for Open Source program and it was absolutely painless. All we needed to do was submit an application and now we're using Ultimate without paying a cent.

I'm not sure it's what you're referring to, but one of the pain points for me is that open source projects (that don't join the program) no longer have access to lots of free SaaS CI hours. That sucks, but I can't blame them - they had a plague of crypto miners taking advantage of those free CI hours. It's not reasonable to expect them to eat that cost, especially when the open source program is so easy to join.

GitLab already has stellar CI/CD, far superior to GitHub Actions IMO

I’ve been using GitLab for years. I have a GitHub account but at this point I only use it to contribute to other projects.

GitLab. You can use their SaaS offering (gitlab.com) or run the open source version on your own server(s).

The point is that Slack does not take advantage of Electron at all. It’s no better than running it in a browser.

I absolutely prefer using an ORM for querying but I'm definitely never letting the ORM create the schema for me. I will always do that myself and generate the ORM definitions from SQL, and I will never use an ORM that doesn't have that as an option.

In my book, "memory safety" also means avoiding data races. AFAIK Rust prevents most or all races by enforcing ownership and lifetime of pointers.

My entire point is that any CS degree from any university is meaningless unless you know that university's CS program is actually good