flossly

You can have naked (top-level) functions in Python right? Are they also in instances of classes?

Kotlin has optional OOP on the JVM. I still use it, but sparingly. Barely ever classes inherit from other classes in my code; I use interfaces, mostly to be able to fake services for testing.

Most of what I write are functions and data objects (records, basically).

One pattern I use is classes with one function, where the constructor takes the functions dependencies, and the function only takes non-dependency parameters.

Not sure what you mean by modern C++ code.

But Rust's type system an borrow checker are not something you want to go without in Rust, while in C++ many codebases prevent the use of some features to reduce compile time right?

Predominantly trained on atheist text maybe?

Also, would you want to know an LLM's religious/spiritual orientation? I rather have it help me code.

No, "CloudFlare going all in on Rust" means that the code they write and maintain is rewritten.

> P.S. I've tried Zig [...]

Why not Zig then, and C instead?

As a C/Zig outsider, I'd much rather read Zig.

Yes, at least Rust and Zig have answers for the remaining niches.

Rust's type system is making it's compile times bigger than C, C++ and Zig. This does keep it away from some code that's currently C or C++.

Cannot really compare C# to Rust.

C# to me compares to Java and Kotlin (they have a large runtime or VM and implement GC).

Rust compares to C, C++, Zig or Odin (compile to native, memory is more self-managed).

Best part of Golang ihmo; first time I saw a language mandate it's formatting. Fast compiles are also nice, but not exclusive to Go (C, C++, OCaml, also compile fast).

I find it interesting that Google uses Rust. I know they work on Rust-based kernel code for Android. I'm curious to know if they also use it for networked application code, and why they picked it over Go.

Personally I prefer Rust over Go for it's types, and I never use it in big projects, so compile time does not bother me. But Google basically created Go for it's networked application code.

...and a community the size of Elm.

> I want regular OOP

Why would you want that? Just to continue the habit? I'd say regular OOP is, after implicit `null`, the biggest mistake in software.

Crystal is nice, but for network programming, Go simply cannot be beaten by a language that has a equally limited type system.

just bolt your SSG onto the many CMS backends that are available. like Ghost, WriteFreely, Strapi or Payload.

We can do better than PHP, EAV-style db schemas, year 2000ish CMSes and, thus, Drupal.

It' reputation is earned.

A fresh web stack with a traditional (non-EAV) db schema and proper programming layers is a much better DX, I'd say. All very doable with LLM-assisted coding.

I'm more insterested in the new CSS scoping feature that still not supported. HAving CSS only work on a scope of the DOM would make dealing with CSS a lot easier.

While waiting for that I decided to use Tailwind so I can basically "not do CSS", but have it locally defined in my HTML. It buys me a similar freedom to the CSS scoping feature, as the cost of having to run a bunch of tools to get my final CSS asset file for deployment.

> bad taste

They are only as good as their training data.

I expect them to have badder taste for PHP or JS, than, say, Kotlin or Ruby.

That's be because I prefer the code the latter communities have produced over the former.

Ruby is token efficient because it is terse, and has little special-characters. That why it sometimes "reads like english".

But also it has a bolted on type system.

I dont mind burning tokens on code that is well typed.

Just like I dont mind burning tokens on TDD.

I think maintainers here listened to their gut feeling and trusted their experience.

On top of that I think this is actually great FLOSS news, knowing how many commercial products have sacrificed proper professional programming on the altar of shareholder expectations.

> We might need different kind of rules/constraints because at the end we rely on LLMs to respect or use those rules

I want everyone to respect those rules. LLM and human alike.

Hence, I like architecture tests. Most of my arch-tests double as a point in a CLAUDE.md (or sub) file.

Architecture tests are understood both by LLM and human, and test everyone's code. How's this not what you need?

Saying we need a different language, to me, is saying you do not understand LLMs well: those algorithms basically can do what they do due to prior art. A completely new language is not what I'd expect an LLM to be great at.

Look into architecture tests. By leveraging those you can get any project to have those benefits.

Is it?

When you have to understand something yourself, do you rather read C, JS or C#?

In the end of the day I have to be able to read it, in anger, when things go south...

Some libs have amazing APIs (many in C# and Kotlin are well done); some libs have horrible APIs (many libs in PHP and JS look horrible to me).

In the end of the day I have to be able to read it, in anger, when things go south...

I found that what me/ my project/ my LLM needed to arrange this was very elaborate architecture tests: tests that check if some architecture rules are still upheld on the main (and test!) codebases.

If I find a violation of a arch rule (e.g.: a db query defined in HTTP-handler code), I codify that arch rule in the architecture tests.

Libraries exist to help writing arch tests, but you can also let your LLM come up with something custom.

Also for CSS? I really like how Tailwind puts the CSS in the same place as my HTML, and also I like how well LLMs write it.

Also my JS is very "contained" as I write SSR web applications. I also really like how Alpine.js makes my use of JS very "close to the HTML". I'd say using Alpine helps my LLM to deliver more maintainable JS code (in case of SSR web apps).

Just a few years ago, before the LLM-assisted-coding-era, I already did not like frameworks as much as I used to.

I liked Rails. But that was more because through Rails I learned the MVC pattern, learned the layer-middelware pattern from Rack (and the ActiveRecord ORM -- but I now no longer like ORMs but that's a different story). Those 2 pattern I still use today in some way or form, and I find them in many modern (Rust) web development frameworks/libs.

So I now no longer use Rails for new projects. These projects were all SSR web apps (traditional server-side rendered web apps that use JavaScript sparingly), built with Kotlin+http4k. Http4k is a web library, so no framework there and it feels very good.

The article is very frontend/JS-focussed. I prefer to keep things simpler and just use SSR for the UI. This is because above all (1) I dont like JavaScript (not even when my LLM writes it for me) and (2) for the type of application it is not needed to do state management again in the browser (IMHO it's just more code for the same features).

Sure, a little JS is needed in my apps too. But I (assisted by LLM) use it sparingly and when I use it it's with Alpine.js.

CSS with Tailwind and JS with Alpine makes for pages that are mostly "self contained" (the CSS and JS defined in the same place as the HTML that relates to it), which makes reasoning about them so much easier. For HTML building i use kotlinx.html (an HTML eDSL in Kotlin; HTML as Kotlin code).

I'd say http4k, Tailwind and Alpine are not frameworks. Maybe Alpine is most framework-like of all of these. At least they are not frameworks in the sense that they do not dictate my project folder structure and "how everything ties together".

With http4k the "how everything ties together" answer is in your own project's code, NOT in "the framework" or in 3rd party library code.

In my latest projects (all LLM assisted) I make heavy use of architecture tests: tests on the shape (e.g.: folder structure) of my codebase. These tests check that my architecture rules are adhered to. Think of enforcing the MVC pattern; only the pattern that I use is way more split out (instead of M-V-C, it more like: boot - contract - db - domain - filter - handler - job - lib - path - presentation - routing - workflow).

I'd say framework matter more when:

1. you are learning something, or

2. when the team needs to have shared code hygiene values, or

3. when you do not use architecture tests yet!

Kotlin is, according to surveys, getting very big as a back-end language.

This is (after Android apps) something that Java has historically been very dominant in.

I read the comment you reply on as a reason not to use C.

I kinda like kotlinx.html in Kotlin; it's an eDSL for writing HTML in actual Kotlin. So I can put break points in my template code. It's a tiny bit slower than string-with-some-interpolation type of template libraries; but it's so little that it's a price I'm willing to pay. Also there's more impact on compile times than with string-with-some-interpolation type of template libraries.

The typesafety you get is what you already have in Kotlin, and there a little extra in that you cannot nest certain HTML-elements in certain other elements (adhering to the HTML spec). You can come up with your own elements and attributes, but the ones that are in the HMTL-spec are usually available in kotlinx.html as well (and thus can be auto-completed).

A large part of this library is generated from the actual HTML spec.

Claude Code seems to have not problem writing it (I barely write templates myself these days).

https://github.com/kotlin/kotlinx.html

https://dzone.com/articles/modern-type-safe-template-engines...

If ETH-68 support Milan-AVB that would indeed be cool (especially for users on other platfroms).

Seem like a link to a Pipewire repo. Instead it is a Pipewire implementation of Milan-AVB.

Milan-AVB is a deterministic, standards-based media networking protocol built on top of Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) IEEE standards. Maintained by the Avnu Alliance, it is designed for the professional audio, video, and live event industries to guarantee plug-and-play interoperability across devices from different manufacturers

Quake is to some extend a reference implementation of a modern FPS-type game. Because it is open source and because it is well written.

Now I'm no hero in C (doing slightly better in C++). But I have quite some experience with Rust. I rather read Quake in Rust than in C. So I'm happy with the port.

Also, you talk down on the effort but porting over a codebase this size is no small feat even with the help of LLMs. I think the "author" (human creator) learned a thing or two along the way.

> provided by OpenAI for evaluation

Well that backfired. Now all geeks reading this know that Opus beats Astra's ass hands down.