I’m not in the market, but I’ve actually had similar thoughts of building a project on top of NixOS that’s focused on self-hosting for homes and small businesses. I recently deployed my own router/server on a BeeLink mini PC and instead of using something like OpenWRT, I used NixOS, systemd-networkd, nftables, etc.

DM me if you want to discuss more. I think the idea has potential and I might be interested in helping if you can get the business model right (even if it just ends up being some FOSS thing).

This chart would be more readable if the corruption perception index were explained by having the polarity of the scale labeled. I.e. is green “corrupt” or not?

By following the source link, it looks like green = “clean” and gray = “corrupt”.

Your Git requires a regular flagellation to function properly.

Pays to know how to recover code from the reflog in these cases.

The git push --force is definitely a controversial suggestion, im personally happy with doing that, but I have also personally accidentally force pushed dev/main and seen others do it. Squash on merge is probably a safer habit to have. Also, gitlab and bitbucket both get a bit confused if you forcepush to a branch that is part of a MR.

You can add branch protections that will prevent you from accidental force pushing to main or dev.

IMO when I see a PR with “WIP” commits, I just assume that minimal effort was put into keeping the commits organized, and I squash all commits to review the PR. If I see many meaningful commit messages, I will try reviewing one commit at a time.

When I make a PR, I force push to keep my commits organized. If there are changes I want to make as a result of feedback, and they would create significant churn to rebase all of the patches, then I will apply the feedback in a follow-up commit.

Boo paywall

Yea I should have clarified. Prototypes are a great idea. The problem occurs when you say, “this is good enough we can improve on it as we go.” Yea good luck balancing priorities when everything breaks from tapping your keyboard too hard. You MUST NOT MERGE the prototype.

That a “working” prototype with no tests is just as good as a carefully-designed and well-tested feature. I see this happen so often that a coder puts a prototype in front of a product manager or exec and they are like, “this is exactly what we need, now! Ship that!” And then misery ensues for all of the engineers that need to maintain this piece of garbage. As managers pressure the engineers to build new features on top, they inevitably break fundamental parts of it, and without a confident leader to demand that tech debt is paid off, that product will consume the souls of many desperate coders.

In contrast, if you do it right the first time, there will be significant parts of code that never need to change, and the parts that do need to change will be much easier, because it will be obvious if it breaks the tests.

Some of the solutions it claims to provide would be genuinely great. I can’t tell if it delivers. It definitely looks pre-alpha stage. I really hope it’s not locked-in to their cloud platform.

The cargo culting is always going to happen and turn into elitism. But it stems from real advantages of specific technologies, and sometimes you should actually consider that the tech you’re using is irresponsible when better alternatives exist.

Android users aren’t having kids. /s

Do challenging projects. Read code from better engineers. Work with better engineers. Try new languages that actually solve technical problems instead of just having nice syntax. Contribute to open source projects that you use. Actually read the manuals that come with your tools. Notice when it’s taking you a long time to do something and reflect on it to find a faster way. Constantly tweak your workflow to be more productive.

And the most important of all:

Get a split ergomech keyboard.

So there’s no LSP function to just show all of the multi-methods that accept a specific type? That’s a pretty serious tooling limitation.

Maybe Julia sounds better in theory than in practice, if the tooling still isn’t ready for production use.

What do you find challenging about multiple dispatch? I don’t use Julia for my job, so I can’t say I’ve had enough experience to have a strong opinion. MD seems like a valuable tool though.

If you like Haskell but desire better tooling, you might consider checking out Lean4.

If we’re saying 7% is the bar for mainstream, then Rust is my vote.

C# is not even mainstream by that standard.

I’d also like to see Julia used more.

That’s so weird, I thought everyone had already heard about Helix. Why are people still using neovim?

Is it just a matter of proactive learning and I should know all of them in advance, as well as their uses?

Yes

Oh yea I want to try this out. Just wish it could work with other editors. Also Talon being closed source bothers me.

I have a few that I’ve started using this year.

• NixOs
• Helix
• Cloudflare Tunnel

There is also a pretty good interactive tutorial. Just run the :tutor command.

Helix. Instant startup. Minimal configuration required. Has all of the killer features I want from an IDE anyway.

EDIT: I assumed people would just research this anyway, but a more complete list of features I enjoy from Helix:

• very responsive
• modal editing
• declarative configuration file format (TOML, not Lua)
• language server protocol
• debug adapter protocol
• written in Rust so I am more likely to be able to submit a PR if I need to

Some cons (all known issues on github):

• no plugin API yet
• inline LSP diagnostics are overly intrusive and can overlap your code
• cold-starts the LSP when you start the editor, so you might need to wait for symbol queries in a large project

Javascript can be frustrating because it also has some rare features among popular languages, and uses the same keywords for different concepts.

I don’t think those are the reasons JS is frustrating.

And this is actually important when doing your job. I was reading code just yesterday written like the “left side” and it slowed me down because I was forced to understand everything that was happening in a big paragraph instead of just glossing over a function with an understandable name. These “inline functions” will often introduce temporary variables and stuff that forces the reader to understand the scope of things that really don’t matter at the current level of abstraction.

Just tell your boss it’s Python++.

Yea I’m mostly poking fun. You don’t even need script embedding for Turing Completeness. But I don’t consider DSLs as general purpose languages, as by definition they are not intended to be used that way.

Who’s going to tell them that SQL is not a programming language.

Yea I think I agree with you there, at least theoretically. In practice I’ve found that it’s easier to use a TUI editor over SSH, and they require less resources, but that usually isn’t noticeable on my PC. TUI editors can also run inside tmux, which is very nice if you are a tmux user.

You have a point, devs should be using multiple large monitors. I will often need to have 3-4 files open at once, plus some browser windows. Having some limit on line length helps with this and for fighting code complexity.

scrolling is usually smoother

This is probably the last thing on my mind when editing text, but sure.

Did you know they the jetbrains IDEs have official vim-like key bindings? I converted a windows gvim user to it.

Yea I’m aware, but why would I use an emulator when I can use the real thing?

That really is one hell of a hot take

Yea well most of the comments in here are lukewarm takes so… there you go.

I for one really love the zoomed out preview on the right that has become popular in recent years.

I almost never navigate code based on its order or “shape” in the file. LSP-based symbol tagging or searching is way faster than scrolling. I guess you can click the spot on the preview that you need, but I refuse to reach for my mouse while editing text.

Really hard to do in a terminal. If you have errors you can see very fast where they are located/clustered in the file and can already tell just by the shape of the program where it is.

I use LSP integration to see a complete list of errors/warnings and jump to them.

Another example: GUI color picker directly in my editor as a tooltip above color values in css/html templates.

That’s for design, not text editing ;)

inline preview of latex or Template fragments.

I will use a latex or markdown language server that renders to a browser tab.

To be fair, I don’t do HTML/JS/CSS, so I bet VSCode or other GUI editors are great for that. But that’s specifically because you want to see something rendered. Most of the time you can just see it in an actual browser next to your text editor though.

Not even “controlling the lifespan” but, “being whipped by your machine when you are not careful with the lifetimes.”

The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.

80 character limit is helpful though when you need to have many files open at a time. Maybe 100 is more reasonable. Fighting indentation is important too.

This is why code review exists. Writer’s can’t always see what’s wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.

That’s not to say you shouldn’t try to make it readable in the first place. But reviewing and reading other people’s code is how you get better.

I don’t think DRY or WET or the “rule of 3” can address the nuances of some abstractions. I think most of the times when I decide to abstract something, it’s not because the code looks repetitive, but because I’ve decomposed the architecture into components with specific responsibilities that work well together.

In other words, I don’t abstract from the bottom up, looking at repetitive code. I abstract from the top down, considering what capabilities are required from a system and decomposing the system to deliver those capabilities.

Of course, repetitive code might be a smell, suggesting that there is room for abstraction, but I don’t design the abstraction based (entirely) on the existing code.

I don’t think many large established companies will be taking the risk on newer languages, but there are plenty of new companies that will mature based on a foundation of writing their backend in Rust or some other new language.

Probably some Rust contingents will form on internal teams within large companies, and they will build new products or services in X new language.

I do think it solves an interesting problem where you’re working on your desktop and decide to move to your laptop and continue working on the same codebase, but don’t want to commit early so you can pull down the changes to your laptop.

This has been a solved problem for decades. SSH.

I prefer Rust but I am jealous of comptime.

Definitely hyperbole, but it’s not uncommon for CTOs to be the main author of a company’s tech.