simon_void

Joined 8 years ago

Karma

Submissions

Member since

Jul 19

Recent submissions

nope, StarCraft factions (most likely) come from Warhammer40k. - the Zerg (and its hivemind) are a version of the Tyranids [1] - the Protoss are adapted from the Aeldari [2] - the Humans are, well, Humans. with the ghost units being adapted from Psykers [3] and Marines being adapted from the 40k Space Marines [4]

The rumour is that Blizzard wanted to make a Warhammer game, but Games Workshop - the owner of the Warhammer IP - pulled out of the deal, so Blizzard modified their game's universe a a bit and called it WarCraft and later took a similar approach with StarCraft.

[1] https://warhammer40k.fandom.com/wiki/Tyranids

[2] https://warhammer40k.fandom.com/wiki/Aeldari

[3] https://warhammer40k.fandom.com/wiki/Psyker

[4] https://warhammer40k.fandom.com/wiki/Space_Marines

Comment · 15 days ago

I've read it again: Junie CLI has a Linux version, Junie Local doesn't.

Comment · 15 days ago

why is Junie local only available for Mac & Windows? Why not Linux?

Comment · 24 days ago

regarding naming the planet, I'd vote for "Adrian".

Comment · 2 months ago

> Bun's recent migration to Rust which could be misinterpreted as an example supporting migrating to rust, but under the hood it's far from a success story.

Since you don't mention that this migration is basically executed agenticly by Claude, it seems like you attribute this troubled migration to Rust not being that good of an improvement after all. For me it doesn't seem that surprising that Claude autonomously translating hacky Zig (according to Andrew Kelly #1) to unidiomatic (way more unsafe code that usual) Rust didn't solve the issues that the original code base already had.

#1 https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

Comment · 5 months ago

less is more, I just want the plain old search experience I've had for 25 years so I stated paying for Kagi around a year ago. (Before that I used DuckDuckGo which still seems fine. They seem to also offer AI now, but it's not obnoxious like on Google.)

Comment · 5 months ago

Is the inclusion of synchronous interfaces a new thing? When I learned actix_web 2-3 years ago for some webservices at work, the documentation surely (at least) started of with async functions everywhere. Did that change? Were synchronous interfaces introduced later in the actix_web documentation? Or did everybody switch over to axum in the meantime and axum has synchrounous interfaces!? (I just checked and according to crates.io axum seems to have 8x the recent downloads of actix_web.) background: actix_web is still the only Rust webframework I have experience with

Comment · 8 months ago

nobody trusts AI agents, that's why they are put in a harness. It's just that I additionally belong to the people who don't trust AI agents to always adhere to harnesses either.

Comment · 8 months ago

true, but you'd be wrong to assume that Germans only compound words if both parts are nouns, e.g. "Gehweg" (walk way) and "Springseil" (jump rope) use the base of a verb. We do actually have "Kochwasser" ("kochen" means "to cook", "kochend" means "boiling") but that's not boiling water ("kochendes Wasser") but for water used for cooking.

Comment · 8 months ago

not anything. As a German I see no way to compound "boiling water". It remains two words: "kochendes Wasser".

Comment · 9 months ago

thank you for the link to the talk! I actually witnessed the talk live, but must have completely missed this or simply forgot that this was answered :D

Comment · 9 months ago

Rich Errors look promising to me, but what about interop with Java? What will the return-type of a function be on the Java side be, if the return type on Kotlin side is: Int | ParseError | SomeOtherError?

Background: unions aren't restricted to one normal type and one error type, but to one normal type and any number of error types, so this can't be modelled as syntactic sugar on top of an implicit Either/Result type, can it??

Comment · 9 months ago

technically, Kotlin can use VirtualThreads like it can use any other Java Api (when being compiled to JVM bytecode).[1] If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads. So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines). What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions! My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)

[1] https://void2unit.onrender.com/post/virtualthreads-in-kotlin...

Comment · 10 months ago

I really like languages with non-/nullable types like Kotlin and Rust! I used to work with Java for over a decade and therefore used to code very defensively against NullPointerException and now (with Kotlin) I just don't have to do this anymore. That being said there are two possible sources of nullpointers: from inside your program or from outside (e.g. the json your server got send wasn't fully initialized). The majority of NullPointers come from outside in my experience. Nullpointers from within you have to fix mostly once. but there's no end to what data send to you from outside your control can be missing. Of course you still have to validate/parse outside data when using Kotlin but since the type system then carries on which data has been validated, you can drop the defensive mindset that was appropriate in Java.

So if you have a self-contained, non-safety critical project and want to use/try out an arena-allocated memory approach using Odin seems fine (e.g. looking at you: "raytracing in a weekend").

So yeah, I think there's a niche of projects where the possibility of null pointers isn't a huge deal.

None of my work-related projects fall in that category though :D

Comment · 10 months ago

I agree, i started with (scope) blocks in Rust, but keep the habit in Kotlin win the run - scope-function. Since run takes no arguments, it feels like the closest equivalent to Rust scopes (compared to other Korlin scope functions, which also keep their local variables from polluting the rest of the function body).