jynelson

it says “that’s right” in bold red cursive font. i know what the policy says, i wrote it, you nincompoop.

https://i.imgur.com/129TCNu.png

if an LLM says "I can't open a PR automatically until you solicit a review from a maintainer", i think that's good actually. likewise for proactively following the rest of the rules.

i'm not a man.

Ultimately that's something the hook author has to solve, not the framework which runs them.

correct. i'm saying that hook authors almost never do this right, and i'd rather they didn't even try and moved their checks to a pre-push hook instead.

this completely breaks `git add -p`.

the pre-commit framework does not abstract away “hooks shouldn’t be run during a rebase”, nor “hooks should be fast and reliable”, nor “hooks should never change the index”.

i think you would be interested in demoscene, it’s about exactly this thing: making art out of extremely harsh requirements.

tbh i think you just hate trans people but you're afraid to say it directly

Software should be an engineering field, which exists to help humans, not as some personal art project for your self expression

it makes me sad that you see these things as somehow in conflict with each other :(

it's often that the amount of time i've spent thinking about something (a lot) is totally disproportionate to the time i spend typing my thoughts up (a little)

oh, this is a really good way of putting it! that’s exactly what happened :)

you could build an emacs frontend for this model! the thing i am trying to describe is “getting out of the box”. imagine a terminal session that is shared between emacs, iTerm, and a mobile phone ssh’d in over the network, that’s my vision.

omg i've wanted something like shelter for literal years

it "cheats" a little because it requires the underlying filesystem to support snapshots but it's still really really cool, thank you for the link!

Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly.

Yes, this is the work. https://becca.ooo/blog/vertical-integration/

whoa this looks fascinating, i've never heard of it before! thank you for the link :)

this is really cool omg! i didn't know that, i'll do some research.

one of the strange things to me about the terminal landscape is how little knowledge sharing there is compared to other domains i'm familiar with. iTerm has a bunch of things no one else has; kitty influenced wezterm but otherwise no one else seems to have valued reflection; there's a whole bunch of extensions to ANSI escapes but most of them are non-standard and mutually incompatible. it's weird. if i compare to something like build systems, there's a lot more cross-pollination of ideas there.

i would describe the main idea of the post as opening up the data model of the terminal. the list of wishes are an example of things you can build once you've done that, not the primary reason that opening the data model is useful.

yeah! so i somehow forgot to include this in the post, but one of the thing i would want as part of this is tab complete that integrates with the shell, essentially it would make an RPC call (in the step 3 sense). there’s things that work like this already today, they’re just extremely cursed ^^ but that’s never stopped me before. https://github.com/Aloxaf/fzf-tab?tab=readme-ov-file#differe...

I think so, yes. If you remove any of the things in the “core” I mention in the post, the language hangs together much worse even though it’s smaller; enums without pattern matching is a simple example.

I’m not just saying that I want to go back to the “good old days”, I really do think that those parts of Rust were designed as a coherent whole, in the same way that Uiua is designed as a coherent whole.

I think we are using different meanings of the term "cohere" and I am not sure how to reconcile them. I agree that Rust with async is a more useful language. I don't think being useful implies anything about how coherent a language is (I would point to bash and perl as examples of useful languages with very little coherence). "Coherence" to me means that all the features fit together tightly and are designed with each other in mind, and I don't think that's the case for async and const in Rust—simply because they aren't finished being designed.

note that RAII in Rust is not as simple as calling drop() at the end of each lexical scope, because of drop flags.

you were reading very closely, well done. yes, that is my claim, Rust was smaller and cleaner before async and const. I was so indirect about it because many of my best friends work on those features and I wasn’t sure how to word it. fortunately Matklad has worded it very well on the other site: 2015 rust was a more complete language that cohered better, but the vision of Rust is not to cohere perfectly, it’s to be an industrial language that is useful even if it’s not beautiful.

https://lobste.rs/c/b8kevh

I understand the point they’re trying to make, that being that rust forces you to explicitly deal with the complexity of the problem rather than implicitly

This is not the point I am trying to make.

I think I disagree that you can have a Rust program that doesn't use all these concepts, at least outside of very basic tutorial material. You will very very quickly run into compiler errors that mention them the second you write your own program.

The author conveniently left out all of the things needed to understand that JavaScript version, including async/await, promises, modules, string interpolation, [...] not to mention the runtime that is running this, etc.

These are also left out of the Rust version.

no. the JS program has obvious syntax bugs that TS wouldn't compile. commentors above are right that I was just lazy (ty for the callout, I have since fixed the JS program).

tech salaries in the US are high enough that this is approximately 1-3 years of income as a lump sum. more than that, if you got this amount as a bonus you already have stupid money.

of course $140k would be life changing for most people. but OP, and i suspect most of the other commenters, are not in that situation.

I think this is the natural end state of code bases over time and it’s very hard to fix without dedicating lots of time (and getting buying from management to dedicate that time) https://jyn.dev/technical-debt-is-different-from-technical-r...

oh hey Will! long time no see lol, it's been ages. small world.

i think this is on a good track! i like that it's designed to be extensible while still keeping some amount of structure, and that the DSL makes things very compact. how are those filters implemented? are you spawning a shell to run jq or are you interpreting in-process or something like that?

in general i'd love to see a bunch more DSLs, i think using general-purpose languages for everything is most of the time not actually helpful (cc https://jyn.dev/constrained-languages-are-easier-to-optimize...). i have some vague thoughts about how to make interop between DSLs and the host language easier but i need to think about them some more.

thanks :) i prefer to have the pipes on the new line so it’s more clear how the data flow works, but that’s a cute trick.

good catch. fixed the code block.