I think more competition in the "AI Editor" space is good, but I have to ask – why not make it a VSCode extension? I feel it'd be much more accessible.
Are there limitations in the extension APIs that make it hard to implement?
Agreed, it’s not perfect but VS code is a pretty rich ecosystem. Dealing with the drift between a fork and the core product — and missing features/broken extensions that’ll inevitably come with that isn’t really something I want to deal with in my work flow.
Cursor has a pretty polished experience, but I keep coming back to VS Code and using continue.dev, which is a lot rougher around the edges, because the UI works well enough.
Hey, great question - you're right, extensions are more accessible - the thing is, there is no great way to build the native UI we'd want using them. For example, displaying the before-and-after is vital for us, and doesn't feel natural in an extension.
Extensions like Codeium do the most naive thing possible by writing something like <<<<<<< DIFF >>>>>>>> in your file, literally breaking syntax highlighting. Others like Copilot are super buggy.
Right now Void is built on top of an extension, but we're also modifying and hooking into parts of the IDE to make a more native UX.
A lot of folks prefer JetBrains over VSC. For example my top choice for an AI Editor today is Zed.dev which lets you trivially setup to use a variety of key maps including JetBrains.
I remember having to use BlueJ at University... I found that it makes programming so much harder. New window for every file, no ctrl+click following references, no auto-formatter, no easy sidebar tree of files...
I ended up using vscode and just copying the files into BlueJ before submitting my assignments.
> I remember having to use BlueJ at University... I found that it makes programming so much harder. New window for every file, no ctrl+click following references, no auto-formatter, no easy sidebar tree of files...
There's something to be said for a very minimal "just get shit done" code editor. I think Thonny[1] falls perfectly in this line though in terms of useful features vs IDE-completeness. It has most of the quality of life improvements you're talking about here but is otherwise an advanced text editor with code highlighting.
I used to nearly exclusively write my code that way actually, using EditPlus and then later Notepad++, both with plugins for syntax and formatting. I found it to be surprisingly productive. Then again, I suspect there's a large overlap between people who are like me and will find it productive and those who like all those distraction-free writing applications out there.
> I ended up using vscode and just copying the files into BlueJ before submitting my assignments.
This I'm curious about. Why would you need to do this? Does BlueJ do something specific with the application that VSCode can't?
NAT is not a security feature, nor is everything publicly exposed to the internet on IPv6. With most routers you would have to explicitly forward a port in the router to expose that to the client anyways.
This is something I've been wishing for for ages - I'm glad to find out it's a real thing now. It's a shame about the licensing, but it's a good start.
SVT-AV1 has massively improved encoding speed. I was getting ~4x encode speed with some heavy compression (barely any noticeable quality drop) on 1080p/24fps footage on my Ryzen 7 3700X just yesterday.
For cpu I don't know but h265 hardware acceleration ASICs are mainstream contrary to AV1. Also h265 can reach higher compression level than AV1 although the difference is relatively small apparently.
However technologically AV1 is largely obscolete since h266 stable has been released.
Every study I've seen shows AV1 beats H.265 on VMAF at all bitrates. H.265 never got significant browser support, and I don't expect H.266 to either. https://caniuse.com/hevc
I have seen a scientific paper a few weeks ago stating h265 was ~7% smaller than av1 on tested dataset. Although maybe it's dataset sensitive or differ because of the metric? (maybe it was PSNR or SSIM?)
Anyway any data on AV1 hardware decoding energy consumption vs h265? That is probably the main differentiating metric of interest here
Apple is a "Founding Member" of Alliance for Open Media (which doesn't really mean they are actually a founding member). I think Apple main issues with VP9 was that it was a Google codec by all means.
Apple already supports FLAC and Opus in macOS and iOS, and VP9 in Safari.
It could be that they are waiting to see if AV1 will actually get a marketshare outside Youtube or not.
...to bad that they (in the usual Apple fashion) don't support it in a standard container which everyone else supports and require you to package it in their special snowflake .caf container, so even though in theory everyone supports Opus you still need to use MP3 if you don't want to deal with having to support multiple formats/codecs at the same time.
VP9 is an open format but can still be encumbered by patents. $20 says Google gave Apple an indemnity agreement for VP9 support for YouTube only which is why VP9 is locked down so hard in iOS. So if Apple enables VP9 and gets sued for patent infringement for their VP9 implementation Google will have to pay for some or all of the legal costs and/or judgements resulting from them.
I'd say they are, but the real issue to Apple is how this or that format will affect their users and how it will portray their products. That is, whether or not they can decode the format without the device running hot, noisy and out of battery in 45 minutes. They like H.264/H.265 because users can decode them with high power-efficiency due to GPU- and dedicated hardware support. This is one of the greater benefits of formats that the whole world accepts and adopts.
Are there limitations in the extension APIs that make it hard to implement?