Which keywords would you get rid of and why? You don't have to use all of them!

I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers).

I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.

I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.

I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.

I would probably remove async/await as well, but this is a broader debate beyond Swift.

And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.

I agree with you about result builders, silly feature that only exists for SwiftUI.

But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.

I'm not a Swift user, but I can tell you from C++ experience that this logic doesn't mitigate a complex programming language.

* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.

* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.

* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.

But you have to know all of them to read other people's code.

To answer your question: I would immediately get rid of guard.

Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.

I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming.

internal should definitely go though.

The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.

I think the ?: operator ends up being a decent alternative, e.g.

  // Swift
  guard let foo = maybeFoo else {
    print("missing foo")
    return false
  }

  // Kotlin
  val foo = maybeFoo ?: run {
    print("missing foo")
    return false
  }

Unless there's a use case for guard I'm not thinking of

It’s a decent alternative, but to someone not familiar with the language what’s going on isn’t as clear.

1. You don't have to use it all, but someone will. And there are over 200 keywords in the language: https://x.com/jacobtechtavern/status/1841251621004538183

2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006

That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).

are there actually 217 keywords? Just wondering what the difference between that file and https://docs.swift.org/swift-book/documentation/the-swift-pr... (a mere 102 keywords)

That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/...

I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle

Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes...

> You don't have to use all of them!

You sure pay for the language complexity in high compile times though. Swift is slow, like really slow. I’ve been with it since like v1.2, and its been getting progressively worse for a while IMO. Complex language features (Lets do a borrow checker! Lets do embedded!) and half of the shit isn’t being used internally as far as I can tell

i would get rid of associatedtype, borrowing, consuming, deinit, extension, fileprivate, init, inout, internal, nonisolated, open, operator, precedencegroup, protocol, rethrows, subscript, typealias, #available, #colorLiteral, #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation, #unavailable, associativity, convenience, didSet, dynamic, indirect, infix, lazy, left, mutating, nonmutating, postfix, precedence, prefix, right, unowned, weak, and willSet

It's true that internal is pointless.

Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.

this is gonna sound ranty, but it's straight from the heart:

i think most of them are pointless. not every feature needs to be a new keyword. stuff could be expressed within the language. if the language is so inflexible in that regard that it's impossible to express stuff without a keyword, use macros for gods sake.

why is there a need to have a "convenience func" declaration?

why is "didSet" a keyword?

what about "actor"? most other languages don't have nearly as many keywords and manage to express the idea of actors just fine!

You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.

There are still challenges with basics like compression, which tends to involve trawling Github for the least dubious toy project. Even Apple's Compression framework is missing important algorithms like ZSTD.

Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.

There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.

> There are still challenges with basics like compression

FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/8541...

That’s really useful information, thanks.

I wonder if the same people using "agentic AI" are the same that spend days setting up the "perfect" work environment with four screens.

I find LLMs are great for building ideas, improving understanding and basic prototyping. This is more useful at the start of the project lifecycle, however when getting toward release it's much more about refactoring and dealing with large numbers of files and resources, making very specific changes e.g. from user feedback.

For those of us with decades of muscle memory who can fix a bug in 30 seconds with a few Vim commands, LLMs are very likely to be slower in most coding tasks, excepting prototyping and obscure bug spotting.

Maybe if you've spent decades on the same codebase. Now try doing that in a recent codebase thats been agnatically engineered by five people spiffing into the same repository. Good luck with your VIM muscle memory where the entire code base changes every five seconds around you so that no human can actually track wtf is happening week on week.

Because it's the new Macbook.

So in a couple of years we will have de MacBook Neo Neo?

I think they got just cheaper marketing since jobs died. No focus or brand protection.

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?

Thanks! See https://news.ycombinator.com/item?id=47206861 for some general comments on performance. I haven't measured bit unpacking specifically yet.

> recently implemented a Parquet reader in Swift using parquet-java as a reference

Is this open / interested in users / PRs?

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.

Might be time to run my own models.

I dont like the Gemini's personality. It acts like it know it all.

Don't all LLMS act like it know it all?

Gemini, doubles down when a mistake is pointed out.

Other usually find the mistake or check new sources to fix the mistake.

Feather (Arrow IPC) is zero copy and an order of magnitude simpler. Parquet has a lot of compatibility issues between readers and writers.

Arrow is also directly usable as the application memory model. It’s pretty common to read Parquet into Arrow for transport.

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

Recently we have started documenting this to better inform choices: https://parquet.apache.org/docs/file-format/implementationst...

It's interesting to look at the relationship between this and Apache Arrow.

"The data types generally have a 1-1 correspondence with the Apache Arrow data types." [1]

So it would probably be relatively simple to set up an Arrow Flight endpoint working with LanceDB.

[1] https://lance.org/format/table/#manifest

Thank you I’ve been looking for this. His method of delivery is so clear I find it immensely relaxing.

Do people really still program in vi when most IDEs have excellent Vim support?

Yes, I only open an IDE to run a debugger when needed. The vim support isn't exhaustive and it's jarring whenever a command doesn't work.

This is about Vi though and that's certainly more rare. For me that's only used over a rare ssh with vim not available but vi present

Well it depends, on still using.

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.

IDEs do not have "excellent Vim support".

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 would be very interested in seeing a single IDE with "excellent Vim support".