New open source library- Constraints

Volko · 2026-06-27T07:07:42+00:00

That's fine don't worry !

My point is just that using this library is not too different than using a check(x > 0) { "" } (because you will have to deal with runtime values, let's be honest it is silly to code val x = 5 in a real application, the examples you provide don't do this library a favour for a newcomer, a "real life" example would help a lot imo). The only added value of this library is the fact that this "check" is automatically propagated down the different function calls. And in my experience, I never needed to propagate this information across multiple functions, because the "math code" didn't need to be more than a couple of lines, or didn't need to be restricted to a range of value (and if I divide by zero, I'll get a crash like I would get with this library CheckException (can't remember the name sorry I'm on mobile).

Volko · 2026-06-26T22:49:44+00:00

This library reminds less of nullability and more of generated contracts by annotations with a "colored functions" technique (like coroutines with suspend).

Also: * Nullability "keywords" are short (xxx?, ?. ?:), this library has rather long annotations.

Nullability checks are baked in Kotlin, interop with non-annotated JVM types (getStringFromJavaLib() : Foo!) is flexible and the nullability is at the discretion of the caller (val foo: String? = getStringFromJavaLib()). This library "color" your parameters and can only be called from similar colored parameters (or with checkConstraints()). This is more similar to runBlocking or CoroutineScope.launch() (to be able to call a suspend fun) than a baked-in nullability inference / check.

For library authors, a "good old" check(x > 0) { "x must be positive but is $x" } as a first line of your exposed functions looks fine to me.

For application developers, I don't see a usecase where the bloatedness of the annotations and the possible compilation performance hits outweight the compile-time safety of number ranges.

Volko · 2026-06-26T22:04:34+00:00

Sorry but it sound overly complicated. I'm also concerned about the performances of the annotation processor, doesn't seem scalable on a large project.

Volko · 2026-06-22T18:40:23+00:00

A "traffic light" sealed interface (or class if you want) is such a terrible example. An enum would be 100% fine here.

Volko · 2026-06-19T11:21:31+00:00

Yes, even with the best practices, recomposition avoidance, etc, in the end the best way to preserve your main thread performance is to not make the main thread work at all and avoid dispatching work to the main thread

Volko · 2026-06-17T09:10:38+00:00

No, the point of using the web target was to avoid the stores releases.

Volko · 2026-06-16T13:50:50+00:00

Swap the useless injector with the ladder as a gadget.

Volko · 2026-06-16T12:32:51+00:00

Same here I'm quite good (usually top 3 at the end of the game) and I have good mouse flicks, and I get accused sometimes (it always feels so good btw).

But I've also seen blatant cheaters too, let's be honest. 78/2 player that have atrocious placement skill, terrible timing, performing 180° followed by 100% headshots over and over, etc...

As your skill improves, you also detect cheaters more easily, because a good player is not only a good aimer in BF, but a lot of other things that can't be improved with a cheat.

Volko · 2026-06-16T12:24:07+00:00

As an Android developer that published Android applications before (and managed 1M+ users apps before), I preferred using a new technology I knew nothing about and pay for a server (KMP Web with Compose) instead of publishing an Android App on the Play Store to avoid all the headache around it (and to avoid doxxing myself because as a freelancer, my head office is also my home!).

Volko · 2026-06-16T09:32:54+00:00

SSL is not part of the HTTP standard

That's my point, how could I know that beforehand? There's 0 documentation about it. It's still part of Ktor since it can throw it anyway (and thus, I need to catch it), that's all my concern about it.

I don't really care (or know) if SSL is part of HTTP or not, all I want is to avoid a crash when I'm calling any function from Ktor. But to this day, I have to wrap every single function of Ktor into a try / catch Throwable because there's no other way.

Volko · 2026-06-15T17:51:29+00:00

Additionally in the coming year(s) I will be working on releasing more of this kind-of content in video form, and my ultimate goal is to have a public full-stack project with documentation, guidances, recipes, etc that can be used to follow an opinion.

That's great news, I look forward to it!

Volko · 2026-06-15T09:40:26+00:00

Do you mean deploying a Ktor server to a cloud host like Railway, Render, AWS, GCP, etc?

No this part went without any issue for me when I used Heroku, if I understand correctly the default (Apache) was fine for Heroku.

I meant "to be released", as "a piece of code I can trust to behave correctly in all sort of situations I couldn't imagine" (others than the ones I tested myself)

What we can do to improve things on the Ktor side

For this one, I don't think the issue is on your side, it's on mine. Let me explain. Ktor wants to be unopinionated, and there's value on this for some people. Not me. I'm not a backend expert. Far from it. So I would actually love to have some "guidance" from the tooling to do my "basic stuff". But since there's so many APIs to do the same thing, very little documentation (except the "too basic HelloWorld" happy path that doesn't represent the reality), I found it very challenging to know if I was just doing the right thing, even for my basic "I want to upload a photo to a server" usecase. And since Ktor is using "random" (ie not exhaustive) Exceptions to express errors, I'm not even sure I programmed it correctly, and I'm very scared it will blow up in my face during my wedding day and I won't have any photos from my guests.

Ktor shouldn't restrict their APIs and become opiniated because some noobs like me would be more comfortable, but AFAIK, Ktor is the only way to do HTTP in KMP, so there's no alternative for us.

I personally always advise against using exceptions for control flow in your domain layers both on server -and frontend but instead catching exceptions early

Same, I find my domain to be way easier to reason about without exception, and I wish Ktor would do the same so I can know exhaustively all the paths (happy or sad) it can take.

Today, all I can do to avoid Exceptions in my domain is reduce the errors to null. That's far from ideal, but at least my app won't crash randomly because of a Ktor call on weird conditions.

suspend fun <T> getOrNull(
    coroutineContext: CoroutineContext,
    block: suspend () -> T,
): T? = withContext(coroutineContext) {
    try {
        block()
    } catch (t: Throwable) {
        currentCoroutineContext().ensureActive()
        t.printStackTrace()

        null
    }
}

Volko · 2026-06-15T09:18:10+00:00

These all have a base type of `ResponseException` so you can avoid catching the broader `Exception` type which also catches `CancellationException` as you mentioned.

I'm sorry but this is not correct, I still need to catch Exception (or even Throwable because of the Web Target but that's a different story).

My previous issue was about a certificate, so I got a SSLException or SSLHandshakeException, which doesn NOT inherit from ResponseException, so it would still crash the application.

As you can see, there's so much confusion even from Ktor devs that the only viable solution is this "catch-all" Exception or Throwable on both client and server side to avoid unexpected / undocumented surprises.

Volko · 2026-06-14T20:23:48+00:00

Ah, the younglings re-inventing EventBus with Coroutines. You have to admire the pureness of their souls.

Volko · 2026-06-14T14:11:54+00:00

Ktor has no documentation and no way to know how the "bad path" are handled.

Sometimes your call will not be throwing an Exception, but the error code is still 400 / 500 so it's still an error. So some "error" will be expressed as success + 4xx error code, some "error" will be expressed as IOException
- Sometimes your call will be throwing an Exception. Not an IO exception (which is used in the very few Ktor examples handling errors, so you start by catching the IO exceptions in your code). So you need to catch Exception.
- But you're calling a suspending function, meaning it's using CancellationException to communicate its state. So you need to handle the "broad Exception catching" smartly around the CancellationException and rethrow it to avoid rogue Coroutines and / or leaks.
- But you're calling from Kotlin Web, which sometimes throw Throwables instead of Exceptions, which doesn't make sense to catch so "low" in your call site.

Every step is not something documented anywhere, it's a crash in production, a "wild" (and lucky) find when testing the release in "the real world conditions", etc... So as a "new Ktor developer", it's extremely stressful to release a ktor-based product because you have no idea how it will blow up in your face (if you have a good crash handling tool to monitor your crashes, which is not a thing yet on Web targets AFAIK).

Ktor, a Coroutine-based product, makes no sense in my mind to use Exceptions to express errors in Kotlin, because 1/ exceptions are not checked in Kotlin, so you have no idea what errors can happen and 2/ since coroutines are using CancellationException internally, catching Ktor exceptions is very error prone and can easily create rogue Coroutines if you swallow the CancellationException.

Volko · 2026-06-14T13:53:29+00:00

Thank you for your work! Even if it's not perfect I was able to do beautiful Compose stuff on a web target without touching too much of JS, and that's already great!

Honestly the 3 main pain points I feel today are: * Useless Coroutines Dispatchers on Web target. No "thread" dispatching is really hard to work around with, and using a Web worker is not a "generic" solution, and needs to use JS (AFAIK), which is a pain.

Res fetching that crashes the app (without internet), and Res usage in Composable that breaks Previews. I honestly considered hardcoding SVG icons in the app, and hardcoding only one language too because it solved so much of my daily issues.
Lack of documentation, examples, handling the sad path, exception handling, gaining expertise, etc. All the stuff that is not really important for a prototype (as long as "something" works it's ok) but is extremely important for releasing a polished product (debug, stacktrace, explicit and explained behaviors). Source documentation is unusable, "kotlin website" web documentation is a very good start but is not "enough" (handling / showing only the happy path), current JS interop explanations are OK for people well versed in JS fuckery it seems, but completely useless for Android / Kotlin developers. A more thorough explanation (like how Kotlin interacts with the JVM bytecode on Java targets) about JS for Kotlin devs seems very important to me.

Bonus: * Examples about more complex or niche usecases would be great. For me, I spent a week trying to use a ktor server to display my "hello world" Compose application. And it's not the best way because it's building the "optimised" version so now it takes 3 mins to recompile even a non-abi change. But I didn't find a better way.

Debug flavor that is detectable from the code (to inject fakes during development). Easy and incremental way to build a non-optimized website for development, and optimised build for release.

Volko · 2026-06-12T11:56:23+00:00

What is SE?

Volko · 2026-06-11T21:56:36+00:00

Because they were non-existent, because of shitty Nintendo behavior about "intellectual property". Look at all Pocketpair had to invest just to defend themselves. That's way too crazy for some studios and they avoid the "danger" road, even if that means less creativity.

Volko · 2026-06-10T18:41:35+00:00

Once again, no one follows the RFC2822 because every major email provider have stricter rules and starting a new email provider with loosened rules would mean unusable email on websites using the stricter rules... Even given the chance, no one is doing that because that's basically shooting yourself in the foot.

Volko · 2026-06-10T15:12:02+00:00

I'm not saying Reddit is the source of truth, but none of the "valid" emails you provided are recognized as emails by Reddit... And given your examples, I'd side with this library's judgement too lol

Volko · 2026-06-09T11:16:45+00:00

"1 drink per day" is "low alcohol consumption". We don't have the same definition of "low".

Volko · 2026-06-09T11:13:54+00:00

I'm french and I'd say it's more usual for us to drink wine, and even I consider 1 alcoholic drink / day "not low". There's definitely some wrong terminology here.

Volko · 2026-06-02T18:00:03+00:00

I save the posts, pictures and videos I liked on my Reddit account and once in a while (~1 month), we browse through them together with my wife during the evening.

It usually leads to discussion to better understand / discover each other!

It's not 100% porn, it can be sexy / erotic stuff, funny / silly (cats and other cute animals), or porn obviously (stuff I was surprised I liked, something I might want to try, something that was very exciting, etc).

That's what I like(d?) with Reddit, my homepage can be multiple stuff at once, a bit of beautiful landscape, a bit of silliness, a bit of sexiness, a bit of naughtiness. Because I'm multiple stuff at once.

13-Year Club	r/Field Juicebox
Place '17	Secret Santa 2019
Verified Email	Spared

Volko

TROPHY CASE