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)
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 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.
`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.
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
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:
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)
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.
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)
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)