Superb, I installed and will use it.

Currently almost all of my side projects, LLM assisted or not, are coded in Go + HTMX.

Opus and GPT are very good at it, it's fast to build and start, convenient to deploy and host, one binary. I like it very much.

Very good stack to iterate fast.

Good article.

Maybe you could look up the Try monad API (Scala or Vavr works in Java + Kotlin), by using some extra helper methods you can have something probably a little bit lighter to use.

I believe your example would look like the following with the Try monad (in Java):

  public UserDTO register(UserRegistrationRequest registrationRequest) {
    return Try.of(() -> authService.userExists(registrationRequest.email))
      .filter(Objects::isNull, () -> badRequest("user already exists"))
      .map(userId -> authService.register(registrationRequest.email, registrationRequest.password))
      .get();
  }

The login() function would be using the same pattern to call authService.verify() then filtering nonNull and signing the JWT, so it would be the same pattern for both.

This is what I thought about OCaml when I first tried in 2001. I still do.

It's no accident that Rust's bootstrap compiler was written in OCaml. Rust borrows a lot of ideas from it. Arguably, OCaml and ML are closer ancestors of the language than C.

I like Rust, I use it as much as I can. But, it actually doesn't bring many new features to the table. What it's done is successfully learn from the past, scooping up the good ideas and ditching the bad ones. Its real selling point is how it wraps all of those old ideas up into a modern, well-maintained, stable package that's ready for use in the real world.

> What it's done is successfully learn from the past, scooping up the good ideas and ditching the bad ones. Its real selling point is how it wraps all of those old ideas up into a modern, well-maintained, stable package that's ready for use in the real world.

Which is no small feat. I wish OCaml cleaned house and settled on just one stdlib and removed a lot of legacy baggage, and oh yeah, add built-in Unicode support, and 5-6 other things I am forgetting now.

Sure you can muscle through all that but having Rust around really makes you wonder if it's worth it and in my case I ultimately arrived at "nope, it is not" so I just use Elixir, Golang and Rust.

To be fair, many languages have their bootstrapper written in OCaml or another similar ML. When I took my programming language interpreters and compilers classes, that's what they mentioned to us, because they are uniquely good at writing recursive descent parsers.

Looks nice, I didn't knew about this tool. Sad to see 217 open PR, and nothing gets merged.

Yeah, this is a bit weird. Although someone seems to be committing lately, but there hasn't been a release yet.

Exactly this, bookmarked.

This was a very good read, and I did learn some nice tricks, thank you very much.

Thank you for sharing this was really nice and interesting.

I have been solving these since years, I find it a nice way of assessing a language and deep dive since it will cover lot of parts of what makes a language.

I have been porting my old solutions in other languages into Kotlin over the time, and will be again doing them in Kotlin. I find it a nice language for AOC since custom extensions and DSL possibilities, it has a good builtin libraries and you can always fallback on Java, even if it has some shortcomings.

Regarding the AOC per se, I take it as a fun daily challenge, I know I won't be able to be part of the top 100, at least I would with some luck during the first 3 days, and then.. nope, that's life, try not to be too competitive. Last year it took me 8 hours to solve day 20, but it's a game, you should have fun doing it (I had), if not people should stop.

However, I strive in trying to write pretty, compact, idiomatic and as functional as possible code, which means that sometimes I will write an ugly solution in 5 minutes, and will take an hour to make it beautiful.

Besides I like to read the story, I know plenty of friends who don't even read the adventures of Santa, they just solve the puzzle and that's it, they don't even know they saved Christmas :-D !

> which means that sometimes I will write an ugly solution in 5 minutes, and will take an hour to make it beautiful.

I think I spent 2 hours last night just playing around with different methods of solving it after my initial version. Other libraries, slightly altered algorithms. I think that's one of the parts I enjoy the most, solving the puzzles is fun. Trying a dozen different variations is, for me, more fun (and more edifying).

Yeah, kotlins stdlib for collections is great. Has all kinds of variants of reducing, grouping, filtering, mapping, taking, dropping etc one can think of. Today's solution was to just call the window function.

Spoilers dude! I haven't started yet.

Haha, your last line really made me smile.

2020's day 20 was really tricky - that, and day 23 were the only two days I didn't manage to solve two parts on. I managed to get part one for day 20, but neither parts for day 23. It was good fun trying both, though!

I can vouch for wasting hours of coding due to not reading the problem thoroughly.

Or not trimming your input. I worked and reworked and reworked a problem once, the answer was some number in the billions. Eventually I gave up because I just couldn't work out where I went wrong. I then took someone's working solution and plugged my input in, and I was out by one, because it counted chars and I had a stray newline.

I'd like to say it only happened once, but, it happened again later that year... And then never again (because I pulled out code to always strip newlines after reading it in ;)

This led me one year to registering adventofrealizingicantread.com

It just redirects to the advent site but I've grown to love it :)