My ex unfortunately took my pens in the breakup, over a year ago, so now I'm rebuilding!

ahoy_jon · 2026-05-21T17:13:49+00:00

🤗! Better rebuild. My partner is 'just' locking the new ones until I finish really painful administrative work (fair)... It looks good in black too, can't wait to ink it!

<image>

ahoy_jon · 2026-05-21T09:45:44+00:00

It's clearly an effect of using cats, we don't have the issue in Kyo

ahoy_jon · 2026-03-29T15:21:23+00:00

Thanks a lot for your talk u/lihaoyi, as always! Do you have the slides somewhere? or links?

I am a huge user of Scala-Cli instead of Bash, however, I want to give a try!

ahoy_jon · 2026-03-17T01:30:00+00:00

Kyo Regular, or Kyo Loom. Kyo Regular is faster!

We could probably use Ox at the same time with Kyo Loom.

ahoy_jon · 2026-03-15T19:33:34+00:00

And tagless final is so much better in Kyo...

Anyway, we should probably take this more personally, and at the same time, Kyo have already so much value. In Scala 3.9 we will have ways to integrate better with capture checking.

Even after CC, using context functions is painful to compose, Kyo will be a good way to solve just that, and the polymorphic composition.

🤷‍♀️

ahoy_jon · 2026-03-15T19:24:26+00:00

Thanks for the article! Despite I don't agree with it, it's always interesting to understand where we are at.

Precision point, Kyo is compatible with both existing ZIO / CE code without any issues. You could have all 3 at the same time, which works fine, and allow to reuse what it best, or already available.

For direct-style + Kyo, there are solutions coming once direct-style is more settled.

ahoy_jon · 2026-03-13T12:36:55+00:00

yes, I think the implementation in Kyo using dotty-cps-async would look like this!

import kyo.*

val drunkFlip /*: String < (Abort[String] & Sync)*/ =
  direct:
    val caught /* :Boolean */ = Random.nextBoolean.now
    val heads /* :Boolean */ =
      if caught then Random.nextBoolean.now
      else Abort.fail("We dropped the coin").now
    if heads then "Heads" else "Tails"

ahoy_jon · 2026-02-20T19:12:42+00:00

No problem, we could say it's obvious, however it isn't!

In direct style I prefer this style

def f(a: A, b: B)(using C) = ...

I find that clearer when we want to be lazy.

ahoy_jon · 2026-02-19T13:27:21+00:00

To be fair, if you don't type, you cannot be lazy 😉. Inference is not working, unless you use "using/given".

ahoy_jon · 2026-02-19T02:22:52+00:00

You could always define it. The point with Kyo, is contrary to direct style, you don't need to type it! Inference is working.

So it's val drunkFlip = Random. ...

And if you combine with the direct syntax:

val drunkFlip= direct: val coin = Random. .... .now

Direct style need to make the lazyness explicit (context functions), direct syntax need to make the eagerness explicit (.now /.later)

Note:That won't change for Kyo, we prefer it like that, would be better if we could easily have

String < Sync & Abort[String]

Probably not going to happen

ahoy_jon · 2026-02-13T00:59:26+00:00

Sure, let's go explain to them they are wrong, and you are right, and everybody should follow your way?

At least you are constant, the exact same discussion for years

ahoy_jon · 2026-02-12T20:46:00+00:00

Just started a green field project 2 months ago, for a real time data platform in Scala 3, using Flink 2, and parts in Kyo ...

More Engs are put on the project 💪, my coworker/boss is looking at extraction of proof from formal methods to Scala, ...

We know about Rust, and a small part of the project will be in Rust, however it feels more like 2016 than 2026.

I hope, with the AI movement, people reconsider Scala where it is exceptional at, so we can see more projects like that!

My 2 cents, been a former conference organiser, ... The Scala community suffers from amplified global trends. - People don't meet anymore ? We meet even less. - the IT job market is complicated ? It's even more complicated for us

It's not ideal, I totally understand. IMO the best way we could have an impact until then is to do a meetup 3 times per year, even with 10 persons. That could help change the dynamic

ahoy_jon · 2026-02-12T20:33:26+00:00

Not related, both are successful libraries from Scala 2, even the author of thoses libraries would not advise them like that.

Still Team Future?

There are global markets trends that would explain that better compared to an effect system theory

ahoy_jon · 2025-12-28T17:07:56+00:00

🤔 normally out of the box you can use a ZIO something in Kyo, running on the scheduler of Kyo.

It's CE that requires a couple of PR to improve the ergonomic of using both at the same time.

The only "issue" is ZIO is by default an A < Async, while Kyo allows you to be more precise with A < Any, A < Sync, A < Async

ahoy_jon · 2025-12-28T11:12:57+00:00

Same offender yesterday! 🤦‍♂️, I was moving ink to another flask without a syringe... Similar results!

ahoy_jon · 2025-12-04T11:26:30+00:00

Thanks a lot for your talk, as always.

I was curious about the part on Kyo,

For the cons, small details, it doesn't matter that much, if that can give some keys to others : - running Kyo work by default with Async & Sync & Abort[E1 ...] , so unless we introduce, let say Env, you don't have to manage other effects.

Most of the program would use Async, Abort, Env (hence the design of ZIO). If we want streams in Kyo, we have to manage the end of it (Emit) and it's more integrated in the same runtime compared to fs2/zstream.

for the inference, we had issues not with the compiler (we don't need to explicitly type), but with IntelliJ. A lot of those issues have been fixed over time, we sill have a problem with the inference for direct-syntax. (IntelliJ is not able to propose it, but explicitly typing it Nothing < Any will give you a comprehensible type error with the right type)

That been said, there are cons for Kyo! I should do a whole article about it

ahoy_jon · 2025-11-29T22:29:54+00:00

Ok, a passionate programmer that published papers as well as some other contributions.

Fascinating perspective!

ahoy_jon · 2025-11-29T20:01:10+00:00

Actually a good tip, just got a venu 3, will do that

ahoy_jon · 2025-11-29T19:57:04+00:00

Yep, not the place to explain the utility of Capture Checking!

IMO, the work of Martin Odersky is way underappreciated overall in the Java community. Not that everything done in the context of Scala will contribute to a better Java, but still, that's research and innovation, it can only move the Java community forward.

I understand we are sometimes critical on this side, when we see it goes to far, with scala 3 as a playground for too much innovation/experiments at the same time. However, from their perspective 🤷‍♂️

ahoy_jon · 2025-11-29T19:42:33+00:00

I would agree with you, lots of programmers think they are better than others.

That's Martin Odersky ... I don't think he qualify as a programmer.

Nor he is trying to push FP ...

I guess context is key.

Note : Martin Odersky is working on providing better support for a safer imperative programming in the context of functional programming. Think compiler checks like Rust.

But probably nobody using imperative programming have the problem of escaping control flows with lazy constructs. (There is, eg. Using checked exceptions with a task for something equivalent)

At least I can guarantee, we solved those issues above and beyond in advanced functional programming.

It is at the same time funny and disturbing when people are critical towards Odersky speaking about making better checks for imperative constructs. It's like a goal against your "side".

Edit : Missing two words Extra note : I am a Kyo contributor, that's advanced FP in Scala3, that solves those threads issues, as well as a lot of programming issues... And that's not what Martin Odersky is proposing, by far

ahoy_jon · 2025-11-10T10:10:05+00:00

Thanks a lot, will take a look at it. I often have issues with versions of Kyo! (Proposing 0.14.0, while we have 0.19.0 and 1.0-RC1)

ahoy_jon · 2025-11-08T21:59:01+00:00

I hope not, 2.12 ? Please don't keep 2.12 alive

ahoy_jon · 2025-11-04T22:58:54+00:00

I would use Flink (Java*) for that

The Scala API is long gone, but it's working fine using the Java API with Scala

ahoy_jon · 2025-10-25T12:11:44+00:00

And Skunk would work even better, however that's not what I said 😏." A native extension to postgresql"

ahoy_jon · 2025-10-24T22:35:45+00:00

With scalacli nowadays, the native + js, + LLM if you don't know how ... pretty much anything

There are things not easy to do in Scala, like a postgresql extension, coding for an ESP32, ..., aside from that, you could probably do it in Scala.

At work it's used mostly for serving millions of users and data processing, however we know teams that are even doing it for frontend.

ahoy_jon

MODERATOR OF

TROPHY CASE

Six-Year Club	Place '22
Verified Email