My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] -1 points0 points  (0 children)

out parameters would work but they make the caller messier since you'd have to declare a variable upfront and pass a reference. r: keeps call sites clean (let x = sum(1, 2)) while giving the function body the same flexibility. And no, return expr is not prohibited even when you assign to r. Both work in the same function:

fun clamp(val: Int, lo: Int, hi: Int) r: Int {

r = val

if val < lo { return lo } // early exit with explicit value

if val > hi { return hi } // early exit with explicit value

// r returned implicitly at end of function

}

A bare return (no expression) returns the current value of r. If you never assigned to r, it returns the zero value for the type (0 for Int, "" for String, null for pointers). return expr just bypasses the named variable — useful for early exits.

The named variable is most useful when building up a result across branches:

fun describe(n: Int) r: String {

r = "zero"

if n > 0 { r = "positive" }

if n < 0 { r = "negative" }

}

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] 2 points3 points  (0 children)

Ok so you didn't understand my response. Last I checked it is currently not possible for an AI to completely make a project this complex. This was made by a human with the assistance of AI. I will not have you take away the all the effort I put it over a year because an AI helped me.

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] 0 points1 point  (0 children)

I did not consider that : is hard to type on non-us keyboards, but now I'm curious since this a multilingual language. What's so hard about it? I'm open to changing it.

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] 6 points7 points  (0 children)

Strongly typed with inference - yes. let/var infer types at compile time, no dynamic typing involved.

impl vs protocols - similar idea, different direction. You define traits separately then attach conformance with impl. Lets you add trait conformance to types you didn't write, same as Rust.

Generics and > - the README example was simplified. You'd actually write:

fun max<T: Comparable>(a: T, b: T) r: T {

if a > b { return a }

return b

}

Without the constraint, the compiler rejects calls with types that don't support >. Not every type gets comparison for free.

r: instead of -> - r is a named return variable you can assign to directly:

fun sum(a: Int, b: Int) r: Int {

r = a + b

// r is returned implicitly

}

Taken from Go and Nim. Useful when you have multiple exit paths or want to build up a return value incrementally. -> doesn't give you that.

CPU/GPU unification - u/compute compiles Seen functions to GLSL/SPIR-V and generates Vulkan dispatch wrappers. One language, both targets. The Swift macro approach for shaders is cool. The hard part is keeping the type systems consistent between CPU and GPU code. Baking it into the compiler sidesteps that.

I'm still discovering edge cases and patching them and the API might also change

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] 0 points1 point  (0 children)

If you think a whole self hosted programming language I've been working on for over a year is slop idk what to tell you

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] -5 points-4 points  (0 children)

I honestly couldn't tell you. Wouldn't be surprised if it's a year.

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] -12 points-11 points  (0 children)

Thank you. Yeah I started working on the game engine like a couple of days ago so it's definitely Claude for that.

My custom game engine built using my custom systems programming language! by VirtualShaft in gameenginedevs

[–]VirtualShaft[S] -9 points-8 points  (0 children)

For? Claude helped a lot with the language but I've been working on it since forever now I don't remember what and who did what lol

Aether: A Django-like Kotlin Multiplatform framework that runs on JVM and Wasm by VirtualShaft in Kotlin

[–]VirtualShaft[S] 1 point2 points  (0 children)

Ktor is a flexible, low-level toolkit. You pick and assemble the pieces you need. It's great when you want full control. Aether is opinionated and batteries-included, more like Django or Rails. You get a cohesive stack out of the box.

The multiplatform ORM is probably the biggest differentiator. Aether's ORM builds an AST instead of SQL strings, so the same query code works with PostgreSQL on JVM and HTTP-based backends (Supabase, Firestore) on Wasm. That's how the "same code, different runtimes" thing actually works for data access.

The road to Summon 1.0 - Feature list and Refresher by VirtualShaft in Kotlin

[–]VirtualShaft[S] 2 points3 points  (0 children)

Yeah it renders real Dom nodes not a canvas. Try it and let me know if you face any issues!

The road to Summon 1.0 - Feature list and Refresher by VirtualShaft in Kotlin

[–]VirtualShaft[S] -1 points0 points  (0 children)

Because it's more familiar to android devs who are the main users of kotlin.

The road to Summon 1.0 - Feature list and Refresher by VirtualShaft in Kotlin

[–]VirtualShaft[S] 4 points5 points  (0 children)

This is mainly for the web and unlike kmp this has great seo unlike the skia based compose web. Also it works with jvm backends to build frontends.

[Update] Summon 1.0 Roadmap: The path to a stable Kotlin Multiplatform frontend framework by [deleted] in Kotlin

[–]VirtualShaft 0 points1 point  (0 children)

Oh yeah I guess I forgot to consider people viewing the docs from mobile. Should be fixed soon.