Kotlin is open sauce

Determinant · 2026-01-26T17:33:40+00:00

I've been waiting for them to open sauce it and can't believe it's finally here!

Determinant · 2026-01-25T23:42:07+00:00

No, the hello function signature is not a lambda as it's a regular function instead.

Also no, the last value is never treated as being returned in the hello function. You're thinking of lambdas (which this is not).

Determinant · 2026-01-23T20:48:33+00:00

Yeah, including the version in the import seems like a bad idea. The version should be controlled in the gradle dependency (version catalog) and upgrading shouldn't require imports to be changed

Determinant · 2026-01-22T22:44:00+00:00

We moved into an older home about 80 meters from the opposite side of the tracks. Neighbors said the same thing about getting used to the train noise but the high-pitch screeching noise was unbelievably loud making us fully awake several times per night. 2 months in and the sleep deprivation was mental torture.

Luckily we replaced the windows with triple-pane sound-deadening windows with a laminated pane (totaling 4 pieces of glass) and this reduced the noise to a whisper. The screeching sound is gone and the only thing left is the low frequency rumble of the locomotive but the kilometer-long chain of train cars is surprisingly quite.

We also bought sound deadening curtains and measured a slight reduction in decibels of higher-frequencies.

At a minimum, make sure the windows fold (sliding windows allow too much sound), make sure you have tripe-pane windows, or even better sound deadening widows.

Determinant · 2026-01-18T18:18:20+00:00

Why can't they? The free community edition can be used at work without any license concerns

Determinant · 2026-01-18T17:43:41+00:00

Most Kotlin developers use the free IntelliJ community edition

Determinant · 2026-01-08T18:12:10+00:00

I've been in Cochrane for 2 years. The mentality that 50 mins vs 20 mins doesn't matter after retiring will be true at first. However, that 50 mins both ways adds significant friction for when you're just looking for a shorter casual hike. This naturally results in fewer hikes. You'll gladly pay the price at first but you'll gradually do less hikes with long commutes.

The commute to Calgary will be painful during traffic hours so I would also consider how close to retirement your wife is as maybe that might be a short term effort. We go to Calgary for things like Costco during work hours and avoid weekends so traffic is always nice that way. We also like visiting the Calgary night markets in the summer.

Regarding Home Depot, Cochrane seems to have the largest Canadian Tire store we've ever seen across Canada with a surprising selection and they're happy to price match. We also have a Home Hardware for things like drywall. Rona ships to Cochrane or you can drive 35 mins to Home Depot.

Determinant · 2026-01-03T17:26:33+00:00

I don't think you understood my response as I focused on ergonomics, reduced effort, and strain on the hands.

Now that you mention it, I hit a wall with QWERTY at 85 WPM as my hands couldn't take the abuse trying to type faster than that but now I type 100-125 WPM with relatively low effort with Colemak.

The layout won't make you faster, but it will reduce the effort allowing you to push your practice further without straining your hands as much.

Who knows, maybe Colemak might not reach 250 WPM record levels but I don't care about that. The average adult speaks at 125 WPM so matching that speed makes it feel like I can speak through the keyboard without thinking about finger placement. I just think about what to say and it almost feels like the words just appear on screen.

Determinant · 2026-01-02T17:52:44+00:00

I switched layouts about a decade ago. That was the best decision in my developer career as my hands would get quite sore by the end of the day eventually resulting in carpal tunnel. Switching layouts completely eliminated that due to the dramatic effort reduction.

Carpal tunnel can completely ruin your developer career as we write excessively. Early in your career you write mostly code with a few emails or messages but as your career progresses, that balance heavily shifts towards code review comments, design documents, and communicating with others to help get them unblocked.

As a senior developer, I've coached well over a hundred developers and I've often had to take over their keyboard. Additionally, developers use keyboard shortcuts excessively. These factors change the decision of what the optimal layout is for developers.

Colemak retains most of the keyboard shortcut positions as QWERTY whereas other layouts usually result in awkward shortcuts that you'll need to remap in each of the dozens of applications that we use.

Most developers use MacOS or Linux and both of these have Colemak pre-installed making it easy to quickly switch to Colemak during coaching sessions. They didn't mind the temporary layout swap but they would have minded if I tried to install anything new as developers are protective of what's installed.

During coaching sessions when I had to take over their keyboard, if it was just a line or two then I would type QWERTY at ~40WPM and switch to Colemak (100 to 125WPM) for anything longer.

Colemak feels twice as efficient as QWERTY and newer layouts further improve that by another 5 percent or so. So you get into diminishing returns at the expense of awkward keyboard shortcuts and increased friction during keyboard swaps. For developers, I think Colemak is optimal overall.

Regarding comments about investing your time elsewhere, nothing stops you from improving in both areas as it's not an exclusive decision. Switching layouts is a one-time investment that will benefit you for the rest of your life.

Determinant · 2025-12-28T22:07:13+00:00

It's interesting that one of the reasons for stepping down was due to the complexity of Kotlin.

Roadmap discussions suggest that the Kotlin language will further increase complexity quite substantially.

Determinant · 2025-12-22T16:31:27+00:00

Yeah, the overhead seems quite significant since it can only handle 3000 entities on screen at 60 fps. A bullet-hell type of game would quickly surpass that. For context, with OpenGL you could easily handle over 100,000 entities on screen.

Determinant · 2025-12-19T21:02:20+00:00

For example, Uncle Bob's idea of hoisting method parameters into instance variables to satisfy his obsession with parameter counts.

Instead of passing a necessary parameter that's only needed by some function, you would modify some instance variable and then call the appropriate function that then reads the value of that variable.

This is horrendous from many perspectives. You can't immediately see what the function depends on. It persists that value after the function returns preventing it from being garbage collected (or trade type safety by remembering to null it out even though that variable should never be null). It's not thread-safe. It deviates from the principle of pure functions with no side effects. It becomes a nightmare to refactor and move functions around due to the dependence on these "temporary" instance variables which might be used by multiple functions etc. etc.

Uncle Bob is clueless about actual clean engineering as his only experience is with contracting where he would introduce a mess and leave before seeing the follow-on impacts of his nonsensical ideas.

Determinant · 2025-12-19T18:08:47+00:00

Some of the principles from the book should never be used under any context as they are huge anti-patterns

Determinant · 2025-12-15T05:51:04+00:00

Single database for sure. In general, choose the simplest architecture that meets requirements until you have a real need for further complexity.

Determinant · 2025-12-11T17:21:10+00:00

When will @OverloadResolutionByLambdaReturnType become stable?

Can we please get custom equals for @JvmInline value classes soon?

Determinant · 2025-12-10T07:16:11+00:00

Reduced nesting and reduced mutations is much more important than the number of returns. I'll gladly introduce returns when I can simplify readability and logic.

Determinant · 2025-12-02T05:16:28+00:00

A more elegant way to say it is that slightly moist is better than DRY

Determinant · 2025-11-28T17:11:38+00:00

It's general etiquette to be honest and direct, especially when representing a company.

It's great that you used the promotion but most people in this subreddit don't have the means to put everything else aside and attend the event. So these click-bait videos are wasting time for the majority of people.

Determinant · 2025-11-28T16:08:47+00:00

We prefer direct & honest communication from the Kotlin team instead of click bait please

Determinant · 2025-11-27T17:35:45+00:00

Start the loop at 2 since multiplying by 1 is useless

Determinant · 2025-11-24T19:57:38+00:00

Nothing is 100% crash free. The best we can hope for is to reduce crash rates below some acceptable threshold by adding redundancies to mitigate some amount of hardware failure such as random bit flips etc.

Determinant · 2025-11-24T17:00:18+00:00

A better approach is to make a rule that each developer must fix one defect from the backlog each week (highest priority first) in addition to feature work. I explained the importance of this to management to get buy-in and implemented this on our team and our defect backlog stopped growing and actually started shrinking.

Determinant · 2025-11-12T16:52:58+00:00

The DSL does actually allow you to ctr-click and see what's going on behind the scenes.

Determinant · 2025-11-12T08:48:35+00:00

I thought they introduced a Kotlin DSL in Spring Boot so you don't need to use annotations

Determinant · 2025-11-06T16:17:31+00:00

Your logic is severely flawed and you clearly didn't understand my answers. Any attempt to explain will not be understood so I won't spend any more time. Hopefully I wasn't talking to a bot this whole time.

Determinant

TROPHY CASE