Programming

cross-posted from: https://jlai.lu/post/28733131

While looking around for datepicker libraries, I came across this helpful guide on how you can use native datepickers for most, if not all, required datepicker functionality. Sure, it may not be as flashy as the JS enhanced or framework alternatives, but still worth considering IMO.

The description listed a mirror of this video on Vimeo, but I'm not sure if it's still accessible as I have no access to Vimeo here: https://vimeo.com/649009599

Recently I discovered something called data-oriented design and I thought it was such a brilliant concept. Here are other references I recommend:

• A book available online freely https://www.dataorienteddesign.com/dodbook/
• I think this is the first blog post about the concept https://gamesfromwithin.com/data-oriented-design
• Data-Oriented Design and C++ - A talk by Mike Acton https://www.youtube.com/watch?v=rX0ItVEVjHc

What's new in .NET 10

.NET 10 is a LTS (long term support) release.

With C# 14, F# 10, .NET Libraries, ASP.NET Core, Blazor, .NET MAUI, Entity Framework Core 10, Visual Studio 2026, SDK releases.

This post is part of my series comparing C++ to Rust, which I introduced with a discussion of C++ and Rust syntax. In this post, I discuss move semantics. This post is framed around the way moves are implemented in C++, and the fundamental problem with that implementation, With that context, I shall then explain how Rust implements the same feature. I know that move semantics in Rust are often confusing to new Rustaceans – though not as confusing as move semantics in C++ – and I think an exploration of how move semantics work in C++ can be helpful in understanding why Rust is designed the way it is, and why Rust is a better alternative to C++.

When publishing a package for use by programmers, automated changelog generation is very beneficial. In this blog post, I explore how to do it in a simple way that works everywhere.

Obs.: I'm using "[REDACTED]" to not look like I'm doing some advertising.

Sorry to bring AI subject here, but I'm terrified by how efficient AI generation code became in the past few years.

Last year I was seeing a designer community with desperate people because of AI generative images, many people hopeless because how more convenient it is, way more than paying for a freelance to do something reasonable.

Now I'm with the same feeling as a programmer. I just decided to take a look into AI a little deeper, as I don't use it very often. So I tried the recent [REDACTED] editor, which is just [REDACTED] with AI agent features (an AI that does more than just generate text, it create files, make decisions etc...). And I must say, programming jobs will be reduced a lot.

The app was able to do a entire module of a side project, integrating with another API and following the same conventions I did. It worked in the first try. It created all the files and everything.

Many people bring this argument: AI won't replace devs, we'll always need devs to check code etc. Ok, I agree with that, but if before we needed 5 devs to do a job, now we just need 1 to revise all the job an AI did alone equivalent to 5 devs programming.

So, there's no way it won't impact the devs market. I'm being optimistic here, because the future is still unclear, but if it keeps the same rate we can reduce the dev jobs to near zero.

This is what every executive always wanted, get rid of devs, and now they can. Devs were always an inconvenience to executives, but they couldn't get the job done without devs.

Now they can focus all money on AI research until it gets nearly perfect, reduce the skill needed to deal with code and build projects without too much knowledge, and get rid of many devs too.

It's undeniable that AI jobs WILL be affected in a negative way. I'm seriously considering leaving this area and use programming just as a hobby, nothing more.

JPlus is fully compatible with Java, offering modern language features like null safety, boilerplate code generation and other modern language features to reduce developer burden and maximize productivity.

Notably, there is currently no ‘superset’ language that keeps Java syntax almost intact while extending the language with features like null checks at the language level. JPlus aims to fill this gap, providing a language that existing Java developers can naturally learn and adopt.

JPlus is fully compatible with Java, offering modern language features like null safety, boilerplate code generation and other modern language features to reduce developer burden and maximize productivity.

Notably, there is currently no ‘superset’ language that keeps Java syntax almost intact while extending the language with features like null checks at the language level. JPlus aims to fill this gap, providing a language that existing Java developers can naturally learn and adopt.

I’ve tried vim on and off during college but never really had the time to fully get working with it. As it turns out the stress of two degrees is not conducive to “fun activities”. Now that I have a real job ™️, I’ve decided to finally try and use it this week full stop and I genuinely feel like a programming chad. There’s still a lot I’ll need to learn and probably overtime I’ll discover some inefficiency in how I’m using it now but it really does just feel good. I understand the hype now.

A very small thing just happened to me that I don't think I would have noticed if I hadn't been specifically trying not to use an LLM coding assistant.

I am trying to teach myself Godot and GDScript. I have some ideas for video games that I've had scribbled down for a while now but I'd never built enough of them to get a satisfactory prototype. I am comfortable enough in JS that I've now cobbled together some Phaser code into a working game, but I used an LLM to write most of it, I tweaked it just enough to get it running because I wanted a working prototype more than I wanted something polished. I was able to do this pretty quickly, but I (quickly) ran into the problem a lot of vibe coders run into, which is that I didn't understand how the code actually worked. Debugging began to slow me down because I had to try to learn the code as I was debugging it. It was the difference between the relatively minor hassle of debugging my own code and the usually onerous, occasionally nightmarishly unpleasant chore of trying to debug someone else's code, where you keep having to context switch from "how could this code be producing that behavior" mode to "what is this code even supposed to do" mode. I didn't want to work on the project after a certain complexity boundary because making changes became exactly like one of the least enjoyable parts of my job, having to sift through huge amounts of unfamiliar code trying to cobble together enough context to enable the one minor change I want (then rinse, repeat).

So, I decided to start over in Godot, write in GDScript, use only the Godot editor, and use no LLMs while I figure out how to tell Godot what I want. Just me, the docs, and stack overflow, just like old days. Progress has been predictably slow, but I like it. Something about transitioning from generating huge blocks of code at a time and ripping through a generate -> edit -> test -> repeat cycle to writing everything by hand puts the slowness of it in a new light. This feel presumptuous to say because I know almost nothing about carpentry but it's what I imagine it might feel like going from a day job where you have to crank out furniture pieces as fast as possible, then going home to your woodshop and spending a few hours with the hand tools, getting one piece just so. Something about having a comparison to the new way makes the old way feel more noticeably nicer.

While I am doing this old-fashioned coding, I am reading a lot more than I'm writing as usual for starting out in a new language. I'm also less familiar with resources that are available for Godot, so I spend more time scanning the internet trying to find the bit that answers the question I have. Just now I was looking up whether there's a Tuple type in GDScript and I saw an example that, while it used an Array instead of a Tuple, also used the built-in Vector type. It wasn't what I was looking for, and it didn't solve the immediate problem at hand, but for the game I'm imagining I will almost certainly make use of Vector, so I made a note of it. And it occurred to me that this is a thing that happens a lot. I think that slow, semi-random accumulation of trivia and knowledge that happens over the years while you're poring over old forum threads or rambling tutorials or ancient StackOverflow arguments is really useful for developing a deeper understanding of the tools you're using, and I don't think I ever appreciated it or even noticed it happening until now.

At some point I plan to implement (yearly) subscriptions in my app and I'd like to use an European alternative to Stripe.

Having an Elixir SDK would be nice, though it's fine if there isn't one.

The two key points:

• Meetings, interruptions, review delays, and slow CI pipelines cost more than AI saves. Individual productivity tools can’t fix organisational dysfunction.
• AI amplifies existing engineering culture. Strong quality practices get faster. Weak practices accumulate debt faster.

Does anyone have a favorite diff tool for reviewing lots of code? I'm thinking something along the lines like meld or vimdiff. I don't really need a git client. I'm comfortable with the git CLI. I'm mainly interested in making code reviews a little easier to manage.

I'm reviewing a large code change right now and the web interface sucks. It's slow. It doesn't load all the files at once. Cross referencing files sucks.

I know, I know. "Code changes should be small." I've already voiced that to my team, yet here we are. I'm trying to figure out a way to make this a little less miserable.