Respect for doing this. I recently implemented a Parquet reader in Swift using parquet-java as a reference and it was by a long way the hardest bit of coding I’ve done. Your bit unpacking is interesting, is it faster then the 74 KLOC parquet-java bit unpacker?
If Claude could stay available I might consider it. Unfortunately right now, out of the big three, only Gemini has reliable uptime. As much as I dislike Google it's the only reliable option.
Gemini’s web UI and mobile app are horrible. Gemini outputs malformed links that lead BACK to gemini.google.com. There are constant bugs with the side panel not showing your chats or the current chat timing out for no reason. Also, the mobile app has an issue if your text input is too long where the entire text entry box lags, even to the point of locking up the entire app. Openrouter’s web ui runs circles around all the frontier lab UIs. I even prefer their PWA to any of these mobile apps.
I just use the web interface. I don't use mobile apps for things that should be websites.
It's a shame because when Claude is working well it is the best for actual algorithmic coding. There's so much cruft around it now, memories being the most annoying part of that.
80% of the time I just use these things as a sounding board when exploring options and I need responsiveness for that.
I agree, it's definitely attempting to gaslight us all.
I find I need to explain I know what I'm talking about first before it gives me non-patronising answers.
It definitely advertises Google services and I would say I hate it. But it's just reliably available. Neither Claude nor ChatGPT are responding at all today.
When you say compatibility issues, you mean they are more problematic or less?
It’s pretty common to read Parquet into Arrow for transport.
I'm confused by this. Are you referring to Arrow Flight RPC? Or are you saying distributed analytic engine use arrow to transport parquet between queries?
Not the OP, but Parquet compatibility issues are usually due to the varying support of features across implementations. You have to take that into account when writing Parquet data (unless you go with the defaults which can be conservative and suboptimal).
I've been mostly using emacs past 30 years ie. about the time when system memory wasn't any more constraint which while single user was about 8MB at least. But I did earn my living before that about 7 years mostly using vi as most usable editor in the system and that 8MB was luxury most of that time.
But even emacs IMHO was and is vastly superior, vi still had it niche fast small edits and especially before log based transactional filesystems. After power outage or bad brownout event system crash there was great chance you got to fixing filesystem with fsck (which did often take lot of time) and worst cases finally debugfs trying to fiddle bits that you get fsck fixing rest.
Bringing system up with old system could be tedious. Before you get system enough up single user mode and just root fs mounted you had to resort you way forward using those modest tools you had there. It was really great if vi did work, but it too required sometimes more memory than you had before swap was active. If not, then ed was your friend, ex is just vi without visual mode.
For a long time vi was also able to edit very large files. It did not require reading whole file in memory before it allowed editing as for example emacs did (or mmap's it memory later).
These days I use vi for quick edits like someone above mentioned and like it more than any later replacement (nano etc) if emacs is not there, not worth installing it for just quick change or when can't install on (embedded) or someone else's system for any reason.
Vi is often available also *bsd based appliances which I've been using like Junos, Netscalers, etc.
IDE vim support suffers from three problems. First, performance. I have yet to try an IDE that can match the responsiveness of vim. You can obviously tank vim’s performance with plugins, but you don’t have to. Second: clutter. Modern displays are gigantic, and yet most IDE users don’t have more than 40 lines of code on the screen at a time. The rest is occupied by a file picker, command palette, integrated terminal, LLM chat interface, and so forth. You have to go to some effort to reclaim those pixels; big context is not yours by default. Third: uncanny valley effect. Vim implementation is usually incomplete, especially when it comes to ex-style colon-prefixed commands. It’s jarring to run into a spot where your muscle memory doesn’t work.
In short, IDE vim support does not measure up to the experience of using the real thing.
vi is not available on modern systems, people are using clones like (neo)vim or Emacs with evil-mode. And those clones also have modern features too, pushing them to IDE-level of tooling. Proper IDEs are often still a tad superior in being an IDE, but their vi(m)-modes are very lacking in comparison. So at the end it comes down to where you set your focus, and often the vim-side wins over the IDE-side.
They are not meant to be modal, they do not implement Vim meaningfully, they just map a few keybinds. Extremely few have ever tackled trying to implement Ex.
Trying to map vim onto an IDE misses the point, as you'd want to remove most of the IDE getting in the way of actually sitting down and programming and getting shit done.
I think there may be other factors killing SaaS, particularly data sovereignty.
"According to IDC’s Future Enterprise Resiliency and Spending Survey from June 2025, 45% of all organizations and 56% of “digital natives” cited data sovereignty and potential cloud changes as their greatest concern for 2026."
> you can't open a project and one of it's dependent swift packages for editing simultaneously
You can. Any local packages are automatically editable in Xcode. Opening two projects referencing the same local package dependency isn't possible however.
Editor features for editable local packages are limited, even the project inspector hides some actions and then there is the whole story of schemas, working directory (maybe you want to tweak a binary or another target in that package) etc. It’s broken and frustrating.
Is this the time for a random Xcode rant? The topic is agentic AI in Xcode.
I'd be a lot more interested in hearing what people think about this development, what it means for code privacy, how are the context windows handled, can it be enabled per-project, etc.
reply