As a small note, Swift is a compiled language. It uses LLVM as a backend, same as Rust and Clang (C/C++/ObjC). It's currently listed under "Web & typed scripting".
It's definitely a blurry line, this `run` tool invokes your Swift file with `swift file.swift` which runs it in immediate mode. Technically it is compiling your code to memory and and immediately executing it, but is it that different from JIT in Python or Node scripting?
I wonder if the mistake might stem from Go using a subcommand (i.e. `go run`, which might appear resemble `cargo run` or `dotnet run` at a glance) compared to providing the ability to run a "script" as a top-level command, which tends to be more common with interpreted languages (`node`, `python`, `irb`, `bash`, `lua`, etc.)
"compiled" isn't a property of a language. I think the distinction that both you and the author of the tool are making is always going to be messy. It seems to me that you're talking about the language itself via an imprecise description of a particular implementation.
You're right—Kotlin can be used as Kotlin/JS for web development, and as a compiled language when we're talking about Android development.
Context matters
You're right—and the same applies to Kotlin. Swift is more like Rust, C, and C++ in that it compiles directly to machine code. So yes, Swift is currently listed under the wrong category.
As for Kotlin, it could reasonably be placed under either "Web & scripting" or "Compiled," depending on how it's used. Since Kotlin can also compile to JavaScript, its classification depends on the context. If we're talking about Android development, then Kotlin is clearly a compiled systems language.
To clarify: Swift is a compiled, statically typed systems language, much like Rust, C++, or Go. Its core toolchain (swiftc) compiles code into native binaries.
This is a quirky response. Kotlin might be able to compile to JS the same way C++ can compile to WASM but I don't think that's it's primary purpose. Either put them in their idiomatic category or don't bother categorizing at all.
Claims of being "10x faster performance than existing solutions" using a HNSW written entirely in Python is enough to raise alarm bells, vibecoded or not.
That's neither random nor O(1). I think everybody reading the link immediately understands what you mean, but I whished this community would use its technical terminology more carefully.
I use "random" in quotation marks because it communicates the topic effectively and is very straight to the point. Colloquially, when people say "random" in the context of algorithms, it's generally understood to mean "pseudorandom" or "quasirandom". The trick is essentially an LCG using coprime numbers.
The blog post uses "random" in quotations as well in its title.
I call it O(1) because the ordering is fully determined just by choosing an arbitrary prime number. It's constant time to "reorder" the elements and also constant time to get the i'th element in the permutation. This is in contrast to something like the the Fisher-Yates shuffle which permutes the elements in O(n) time.
And for times you need a fast heap-allocated type, Swift's Noncopyable types have been pretty great in my experience. Especially so for graph data structures, where previously retains/releases would be the biggest slowdown.
I've tried different L-Theanine supplements, and there's definitely a difference in quality across companies... which could help explain the variance in experiences.
Unfortunately, there isn't much regulation for supplements in general. Some companies do 3rd party purity testing, though it's not always the case.
Is it possible to finetune an LLM on the factual content without altering its linguistic characteristics?
With Stable Diffusion, you're able to use LoRAs to introduce specific characters, objects, concepts, etc. while maintaining the same visual qualities of the base model.
https://github.com/githubnext/monaspace/blob/main/docs/Textu...