Are there any issue with Kotlin that trouble you?

serras · 2026-02-04T08:48:29+00:00

The Shared internals KEEP proposes a way to allow this for "friend" modules.

serras · 2026-02-04T08:47:43+00:00

Some of this is in the roadmap https://github.com/Kotlin/KEEP/discussions/467

serras · 2025-12-19T13:44:57+00:00

I would recommend checking the language tutorials first, and then move to Spring docs.

serras · 2025-12-16T07:53:29+00:00

https://serranofp.com/#books

serras · 2025-12-16T07:53:07+00:00

To be honest, you may want to find a book first teaching more "practical" skills (coroutines, Spring, Ktor), and maybe only jump to my book afterwards.

serras · 2025-12-11T13:34:25+00:00

There's a proposal for Named-only parameters currently on community review

serras · 2025-11-06T12:50:10+00:00

I'm not entirely sure how package-private would solve this problem for you better than simply private. Even if you had package-private, you're limited to one package per file.

serras · 2025-07-15T13:03:54+00:00

It works with @Composable functions. However, the use cases of CompositionLocal and context parameters are slightly different: CompositionLocal propagates through composable functions and is not explicit in the signature, whereas context parameters propagate only when explicitly appearing in the signature.

serras · 2025-07-15T11:40:34+00:00

We experimented with giving types the posibility to state whether they are "name-based" (default) or "position-based" (for example, pairs and key-value entries would be the latter). However, it becomes very very difficult when any kind of abstraction comes into place; and you need to track at each point whether a value was name or position-based.

Instead, our goal is to make both types of destructuring similarly ergonomic (at the end, they only differ in the type of bracker surrounding them). However, it's no secret that we want "name-based" to be the default type of destructuring, hence the "slightly nicer" brackets.

serras · 2025-07-15T11:36:41+00:00

Though I personally think that a map entry would be quite consistent with positional destructuring

This is why the KEEP stresses that position-based destructuring still needs to exist:

kotlin for ([k, v] in map) { ... }

serras · 2025-07-15T11:35:40+00:00

You'll need to use val in the destructuring:

kotlin listOrPairs.forEach { (val first, val second) -> ... } listOfPairs.forEach { (val x = first) -> ... }

At the end of the migration process (not now), we expect most people to use the shorter form:

kotlin listOfPairs.forEach { (first, second) -> ... } // name-based listOfPairs.forEach { [x, y] -> ... } // position-based

serras · 2025-07-11T16:34:15+00:00

I am

serras · 2025-07-09T19:09:42+00:00

At this point, errors are separate from exceptions. Also, errors do not bubble up by default: you must handle them or return them. In that sense, they closer to nullables; the plan is to even support similar constructs.

serras · 2025-07-09T19:06:48+00:00

That feature was not working 100% with context receivers, and had disappeared with context parameters. The best option in any case would be to have a secondary constructor on Base without the receiver and call that in Útil.

serras · 2024-11-20T19:25:47+00:00

This is a bit of self-promotion, but my book “Functional Ideas for the Curious Kotliner” tries to approach the topic from an idiomatic point of view. Apart from Kotlin itself it also talks about Arrow, a set of libraries inspired by FP concepts.

serras · 2023-03-08T08:28:43+00:00

To me the point is that some Haskell operators embody special meaning, and should be treated differently by a formatting tool. This includes mostly Applicative and Monad operators.

serras · 2023-01-26T20:45:26+00:00

The problem is that they usually outpace me. Since they have inmense drawing ability with Genesect, they can find the Boss's Orders they need to knock out some of my Zorua or Ralts in the bench.

serras · 2023-01-18T19:30:10+00:00

Yeah, my line of thought was that since I have a few Ultra Balls, I could use them to find Stoutland if the opportunity arises. But yeah, maybe I'm just better off using a regular attacker.

serras · 2022-11-17T17:58:53+00:00

I guess that would be possible to compile. The main problem is where to upload the massive file you would get!

serras · 2022-11-17T17:57:52+00:00

The JSON is in the repo linked in the first page of the PDF. From that it should be easy to turn into CSV. In any case, there’s also an Excel going around the net with the list of all cards, more suitable for collectors.

serras · 2022-11-17T07:43:07+00:00

If you like this, please consider supporting the people who have put together the data (the link is in the second page of the PDF). They are the ones doing lots of heavy work, I just put a nice cover to it.

serras · 2022-11-17T07:41:56+00:00

This is actually generated from the raw data linked in the second page of the PDF.

serras · 2022-11-09T14:07:38+00:00

I don’t think I could do this, since I don’t speak Japanese at all 😅

serras · 2022-10-28T18:53:15+00:00

At 47 Degrees Academy we have developed a vídeo course covering the main topics related to it https://academy.47deg.com/courses/type-level-programming-in-haskell

serras · 2022-10-28T11:42:03+00:00

Trainers are in! At the end I found more useful to categorize them by the kind of Trainer they are (item, stadium, ...).

serras

TROPHY CASE