cirwin

We'd love to (and, tbh, likely will).

Search had been a blocker, but that's coming soon; beyond that not sure that there's any reason other than inertia. Alacritty is totally fine, but excited for the Ghostty focus on performance (obviously), and the font rendering stuff looks excellent (though TBD how much of that we can "just use" vs needing to copy-pasta)

You can configure an arbitrary command to connect to ACP in your settings, maybe something like:

{"agent_servers": { "Container Gemini": { "command": "ssh", "arguments": ["hostname", "gemini", "--experimental-acp"] } }

could work?

Author here. Seemed like the least bad of the options.

Being able to comment out sections of a config file easily is a prime use-case; and that really implies using newlines as delimiters, and well, you fall into this trap..

We currently download node if the system version isn't recent enough (we used to always download it, but I fixed that...).

Zed maintainer here.

We use node.js to run a number of language servers and formatters (which are often written in node due to the VSCode ancestry...).

There've been a lot of requests to disable language servers by default; but I think that's not the right default for most users – things should work out of the box.

That said, better control over this is definitely something we will add.

I’ve been working on https://conl.dev, which fixes/removes YAMLs problematic features.

Trying to find a tag-line for it I like, maybe “markdown for config”?

This inspired me to write https://conl.dev

I agree with his premise that TOML is not user friendly, but INI is not useful enough. CONL attempts to land in the gap

`go tool` doesn't require a rebuild, but it does checking that the tool is up-to-date (which requires doing at least a bit of work).

This is one of the main advantages of using `go tool` over the "hope that contributors to have the right version installed" approach. As the version of the tool required by the project evolves, it continues to work.

Interestingly, when I was first working on the proposal, `go run` deliberately did not cache the built binary. That meant that `go tool` was much faster because it only had to do the check instead of re-running the `link` step. In Go 1.24 that was changed (both to support `go tool`, but also for some other work they are planning) so this advantage of `go tool` is not needed anymore.

Primary contributor to the feature here.

We went back on forth on this a lot, but it boiled down to wanting only one dependency graph per module instead of two. This simplifies things like security scanners, and other workflows that analyze your dependencies.

A `// tool` comment would be a nice addition, it's probably not impossible to add, but the code is quite fiddly.

Luckily for library authors, although it does impact version selection for projects who use your module; those projects do not get `// indirect` lines in their go.mod because those packages are not required when building their module.

For me (maintainer of Zed's vim mode) it comes down to a few things:

1. LSPs differ per-language, and so I'm never sure whether I'll get lucky today or not. It's more reliable for small changes to talk about them in terms of the text.

2. LSPs are also quite slow. For example in Zed I can do a quick local rename with `ga` to multi-cursor onto matching words and then `s new_name` to change it. (For larger or cross-file renames I still use the LSP).

3. I err as a human continually, for example in Rust a string is `"a"` and a char is `'a'`. It's easy for my javascript addled brain to use the wrong quotes. I don't know of any LSP operation that does "convert string literal into char literal" (or vice versa), but in vim, it's easy.

We are slowly pulling in support for various vim plugins; but the tail is long and I am not likely to build a vim-compatible Lua (or VimScript :D) API any time soon.

For example, most of vim-surround already works so you could get the most used parts of mini.surround to work with just a few keybindings `"s a":["vim::PushOperator", { "AddSurrounds": {} }]`, but rebuilding every plugin is a labor of love :D.

I’ve been working on a configuration format [1] that looks surprisingly similar to this!

That said, the expectation in CONL is that the entire structure is one document. A separate syntax for multiline comments also enables nice things like syntax highlighting the nested portions.

I do like the purity of just a = b, but it seems harder to provide good error messages with so much flexibility

1: https://github.com/ConradIrwin/conl

Nice – I like your verbatim syntax for multiline strings!

I went with indentation because a very common use-case in a configuration file is commenting out lines. Even with CSON-like comma rules, you still need to balance your {} and []s. Indentation balances itself most* of the time.

Funnily enough, I've been working on solving the same problem concurrently. Though in my _very_ biased opinion; I think CONL is easier to read and write:

https://github.com/ConradIrwin/conl

  value = example

  map
    a = b

  list
    = 1
    = 2

  multiline_value = """bash
    #!/usr/bin/bash
    echo "hello world"

I wrote something like this for contact auto completion - running in the browser we had to ensure that both tree construction was fast, and also that completion was instantaneous. So the next level of optimization is to amortize tree construction over searches (using the observation that most of the tree is never accessed)

https://github.com/superhuman/trie-ing

A failure rate of ~once every two years is so tiny compared to the rate of failure introduced by other things (from human error, on up); and for many time-related things being off by a second is irrelevant (or again tiny compared to all the other sources of noise in measuring time). So it seems reasonable to me to ignore leap seconds in the vast majority of projects.

That said, modern cloud environments do hide this problem for you with leap smearing [1], which seems like the ideal fix. It'd be nice to see the world move to smeared time by default so that one-day = 86400 seconds stays consistent (as does 1 second = 10e9 nano-seconds); but the length of the smallest subdivisions of time perceived by your computer varies intentionally as well as randomly.

[1] https://developers.google.com/time/smear

This is great!

A few more exciting things are happening with file-systems in Chrome that will make this a lot better soon.

Firstly OPFS gives you a private sandboxed filesystem you can access with `await navigator.storage.getDirectory()` to avoid the permission prompt.

Secondly "Augmented OPFS" is coming to web workers, which will give you the ability to read/write partial files with `file.createSyncAccessHandle()`.

There's a demo of this working from the Chrome team here: https://github.com/rstz/emscripten-pthreadfs/tree/main/pthre...

And a more thorough write-up here: https://docs.google.com/document/d/1SmfDdmLRDo6_FoJMl5w1DVum...

Shameless plug, but I built https://github.com/superhuman/lrt as simply as possible, explicitly to avoid this kind of issue (which seem to plague tools in this space).

To do this well (for servers, which is the most common case) you need to keep the port open (and delay requests while recompilation is in progress) or clients can see transient errors. So it's probably not a language level concern, but a protocol level one (it's very solvable for HTTP for example).

I built https://github.com/superhuman/lrt which tries to solve this problem in a go-like way (no configuration required, minimal log noise, and reliability/simplicity as the primary design goals) for Superhuman.

We went through the same problem at Superhuman (and as I write our latest extension update has been pending review for 2 weeks, so maybe we're about to hit it again).

Simeon on the mailing list was quite re-assuring, and I would recommend reaching out to him, though there are limits to what he can help with.

That said we found that the review process is quite arbitrary, resubmitting may work simply because you get a different reviewer. (We've seen identical copies of the extension with different version numbers where one was approved and one rejected).

We've also observed that they use some kind of automated code-analysis to tell whether or not you're making use of the permission; so you may want to check that it's obvious from the code included in the extension bundle that you need the permissions you're asking for.

We've also hypothesized that they apply different standards to extensions depending on the number of users – our staging extension (~50 users) usually gets approved quickly, but our production extension usually takes a while and is less likely to be approved. (This may just be luck of the draw coupled with arbitrariness though)

Superhuman | Fullstack Engineer | San Francisco & Vancouver | Full-time |

At Superhuman, we're rebuilding the inbox from the ground up to make it extremely fast, delightful, and intelligent — you'll feel like you have superpowers.

We're looking for Fullstack Engineers who are deeply invested in building quality software to focus on building out our flagship desktop product. You'll be working heavily on everything that makes an email client tick: Storing and searching gigabytes of data in the browser; building blazingly fast, visually gorgeous user experiences; and jumping in wherever you can make the biggest impact.

• Stack: React, Golang, Postgres, Electron, Google Cloud

• Core values: Create Delight, Be Intentional, Remarkable Quality

• Growth: 20% MoM Growth, 250k+ users on wait list

• Funding: $51M+ from Andreessen Horowitz, First Round Capital, and the founders of Gmail, GitHub, Stripe, Reddit, Intercom, and AngelList

• Interview process: - Phone call with one of our founding Engineers to learn more - about team and tech challenges plus technical discussion - Onsite with Emuye Reynolds, Head of Mobile, and me (CTO)

You can apply here https://superhuman.com/roles?gh_jid=260350 or shoot me questions at [email protected]

– Conrad

PS: Check out our blog https://blog.superhuman.com/

I like the idea of logging both for a bit! We’ve definitely seen CSS regressions too.

It’s pure CSS columns, and not updated since 2012 or so.. yay for the web.

I’m surprised they’ve not caught on more, but it is quite hard to control where column breaks end up in a way that lends itself nicely to evenly lengthed columns and to keeping headings near the paragraphs they’re describing.

Thanks jwilk!

Indeed a lot of this information is now quite outdated - thankfully people (e.g. vim) are beginning to implement it natively, and so I have basically deleted all of my own code and can use existing plugins.

I’d be open to talking through a backend-focused role, though because we run a search engine and sql database in the browser realistically we end up doing most of the traditionally ‘backend’ work (like search and storage) in the clients.

That said we do have a go backend that doesn’t have a full time owner just now.

Superhuman | Fullstack Engineer & Lead Designer | Early-Stage | Full-time | San Francisco | Onsite | $125-160k + equity

• Product: The fastest email experience in the world for web & mobile. Beautiful, powerful, and programmable.

• Why: 1 billion people spend 3hrs+ per day on email. They deserve superpowers that augments their productivity and capabilities.

• Traction: Most wanted product on Product Hunt. 85k+ on our waitlist. Beloved by users (https://twitter.com/SuperhumanCo/timelines/91127886321634099...)

• $15M+ Funding: First Round Capital, Sam Altman @ YC, and the CEO/Founders of Stripe, GitHub, Reddit, Gmail, Intercom, AngelList, Ripple, and Dribbble

• Web Stack: Javascript, React.js, Go

• Values: Create Delight + Be Brilliant + Be Swift

==20 Person Team==

Founders of Rapportive (YC'10, acq by LinkedIn) and LiveRamp (acq for $310M), and previously built products at Apple, Facebook, Flipboard, Google, LinkedIn, Meraki, Zynga.

==Interview==

Phone call / coffee [1 hr] >> In-person [3 hrs] >> Onsite w/team [half-to-full day]

==Contact==

[email protected] | More info: https://superhuman.com/jobs

– Conrad Irwin, Co-Founder & CTO