Hacker Newsnew | past | comments | ask | show | jobs | submit | ckolkey's commentslogin

I've always just used `:e <filename>` - never saw the appeal of oil.nvim for that use case. But for other kinds of modifications it's nifty.


I thank, therefore I am...


...seven months ago, no less


I used Yabai for years until I found aerospace, and switched over instantly. Would highly recommend anyone to try it :)


Huge fan of shelly. I wrote a little sinatra web-server that can just show the current state, and toggle the state, of a bunch of lights around my yard. I really appreciate that all you need is http, no cloud, no fuss to just put together a custom ui for them. Couldn't recommend them more highly


Missed it so much in vim I started maintaining the neovim clone.


Its just a Scheme dialect. A bit odd, but not crazy.


Not really. It uses S-expressions but Scheme pattern matching is totally different. The most common Scheme pattern matching syntax is basically the same as pattern matching in any other language: x means “bind the value at this position to x”, not “the child node of type”. See: https://www.gnu.org/software/guile/manual/html_node/Pattern-... or syntax-rules.

It’s as much a Scheme dialect as WASM’s S-expression form is a Scheme dialect.

Treesitter’s query syntax is slightly understandable in the sense that having x match a node among siblings of type x works well for extracting values out of sibling lists. Most conventional pattern syntaxes struggle with this, e.g. how do you match the string “foo” inside of a list of strings in OCaml or Rust without leaving the match expression and resorting to a loop?

But you could imagine a syntax-rules like use of ellipses …. There’s also a more powerful pattern syntax someone worked on for implementing Scheme-like macros in non-S-expression based languages whose name escapes me right now.


Oh, that meme is old, sorry to say. Here's a nice blog post about ruby outperforming C with the new JIT compiler. Fun times :)

https://railsatscale.com/2023-08-29-ruby-outperforms-c/


Ruby YJIT is slower by multiple orders of magnitude if we look at more than a single constructed example.

In addition, the blog post measures the cost of avoiding doing the interop, which allows wins as the compiler improves in the case of short-lived calls implemented in a native component.

This, however, is not exclusive to Ruby and statically typed JIT or AOT compiled languages benefit from this to a much higher extent.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


In very specific, very limited cases.

I remember when these claims were made for Java twenty years ago. It’s still slower than C, most of the time.

Some things don’t change.


I've been using flowX for many years, first on android and now on ios. I've found it to be incredibly customisable, and particularly good at visualising incoming weather. Gladly paid for it for years now

https://www.flowx.io/


Off the top of my head, in turkish, `i` doesn't become `I`, it becomes `İ`. And `ı` is the lower case version of `I`


You don't need to decide how to upper or lower case a character to be insensitive to case, though. Treating them all as matching isn't a terrible option.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: