romshark

Having rules is good, but having rules that you can statically enforce is better (partly why Rust is so popular, right?). Think of golangci-lint. Datapages can prevent drifting agents (and humans) from making mistakes using static code analysis.

A very simple example is a stale link to a page that no longer exists. Datapages will not allow `<a href="/account">Account</a>` in your Templ templates, `datapages gen` or `datapages lint` will error. It will give you a hint, that you should be using a URL builder from the generated package instead: `<a href={ href.PageAccount() }>Account</a>`. And if that page is ever changed/removed - that will produce an actual compiler error.

But this is obviously just one of the smallest of mistakes.

A production ready application requires a lot of moving parts: - SSE stream subscription, teardown, per-tab state, panic recovery, and graceful shutdown. - Auth, sessions, CSRF, input validation, cross-origin, CSP, etc. - AI skills (I created and tested them for you so you don't have to). - Logging, metrics. - All the NATS boilerplate for doing proper CQRS. - Service workers, browser-local caches, static assets. - Live reload in dev mode (https://github.com/romshark/templier is built in) - etc.

Basically, I'm trying to move a lot of the "plumbing/infrastructure" code out of your and/or your agents ownership into the ownership of a well tested code generator to make it super cheap and easy to ship production grade Datastar apps in Go. You can literally wipe 2/3 of the code base and recreate it idempotently and deterministically, so you really only own and maintain 1/3 of the code (fewer bugs, fewer AI tokens).

The core feature is the toolchain :) the linter & code generator.

TL;DR: Datastar is awesome, but in each Go code base with Datastar I just kept repeating the same code patterns over and over again, and coding agents kept messing up too. Hence, I thought that this code should not be owned and maintained by the author of the business logic, instead it should be owned by a code generator that calls into your business logic.

It keeps the code base more maintainable, especially with agentic coding and should also reduce your token usage (you give the agents less freedom of choice to maneuver within which makes them more efficient).

Read the full motivation here: https://github.com/romshark/datapages#motivation

> Also Go is not very framework oriented...

True. But Datastar is a framework :) it does define how your Go code is going to look and function; and I believe to have found the best approach to Datastar in Go, which doesn't compromise on performance and DX and remains flexible enough to cover practically any sort of use case, except SSG (static site generation).

After 7 long months of lots of work and rumination, it finally happened!

Datapages, the Datastar-powered Go frontend meta-framework and toolchain has reached beta

This is the first release of Datapages I consider production ready.

P.S. Please read the release notes, I've carefully hand-written them for you Otherwise - happy to answer any question!

A Datastar metaframework for Go: https://github.com/romshark/datapages

it's a CLI toolchain with a code generator and linter.

I invested time into this because:

1. Go is a much less wasteful SSR solution than JavaScript.

2. Datastar + Templ + Go is a highly effective combination.

3. I wanted a set of tools that not only helps getting started with a project fast, but also allows me to make it easier to maintain, especially with coding agents.

v0.10.0 should soon move it out of alpha into the beta stage.

GitHub is slowly turning into the Deutsche Bahn of git providers.

> Is there something I'm missing? Why does this workstation need a ~$1000 motherboard and a ~$1000 Xeon CPU? Those two components alone cost more than either of my computers and seem like severe overkill.

Yes, as stated in the article, it probably could have been cheaper. But this setup is supposed to:

1. Run simulations and benchmarks of/on entire SCION topologies with multiple ASes.

2. Potentially grow beyond 25 Gbit/s into the 200 Gbit/s ranges (and more?).

3. Be available to me ASAP (can't wait months for it to arrive from China).

4. Potentially be used for CI/CD performance regression testing in the future.

The budget allowed a bit of headroom for the future.

First of all, at this point, SCION is not here to replace BGP, practically speaking. It's here to provide a more secure and more reliable way of interconnecting ASes for critical infrastructure applications (finance, defense, government, energy, etc.) and can, for example, be seen as a better (multi-provider, multi-path) and cheaper alternative to MPLS, etc.

SCION can help private and public organizations better protect themselves from network disruptions (immediate failover thanks to multi-path routing instead of BGP reconvergence) and reduce DoS attack surface (you can't be hit if you can't be seen).

> How do I peer with the big corps in a SCION world?

You do so by joining an ISD (Isolation Domain) and inheriting TRC (Trust Root Configuration).

> so SCION doesn't really enable a more secure internet, it enables more (largely corporate) control

SCION gives you path authenticity that BGP simply can't provide. It gives you as a packet sender control to define how your packet shall be (multi-)routed given the path options you get.

Think of the power grid for example. Putting power plants on the internet is probably a bad idea. A better idea is to interconnect power plants through multiple ISPs over a separate SCION ISD.

The developers of data-star.dev are working on something interesting they call "Rocket", but it's currently a WiP and hidden behind a paywall so I can't really compare it to Lit. Lit is great though, used it myself a few times (e.g. github.com/romshark/demo-islands). But I still think there's a learning curve to Lit. Better than raw vanilla JS custom elements API, but still not as simple as it could be.

Repos: https://github.com/romshark/tik https://github.com/romshark/toki

I'm trying to make i18n easier, integrate it better with CI/CD and automate it more with LLMs (for now in Go, second priority is TypeScript and other languages later).

For this I had to develop a completely new approach and subsequently a specification for the "textual internationalization key" (TIK) which are programmatically translatable to ICU MF.

Toki is the first TIK processor implementation for Go.

You might also want to check out this abomination of mine: https://github.com/graph-guard/gqlscan

I've held a talk about this, unfortunately wasn't recorded. I've tried to squeeze as much out of Go as I could and I've went crazy doing that :D

I've recently held a talk (https://youtu.be/a7VBbbcmxyQ?si=0fGVxfc4qmKMVCXk) about github.com/romshark/jscan that I've been working on. It's a performance-oriented JSON iterator / tokenizer you might want to take a look at if interested in high performance zero allocation JSON parsing in Go.

I tried to come up with the most efficient implementation of this rather simple function that I could think of with pure Go without going down to SIMD Assembly: https://go.dev/play/p/zHFxwvWOoeT

-32.31% geomean across the different tests looks rather great. Any ideas how to make it even faster?

A high performance GraphQL proxy that allows you to define a whitelist of queries that you explicitly allow to protect your GraphQL API from malicious queries with undefined complexity.

A simple HTTP file server written in Go that's watching the served file for updates and automatically reloads the page in any modern JavaScript-capable browser.

Shouldn't such old standards like SMS just die?

I didn't write or receive any SMS for like 5 years now (except some confirmation codes) since encrypted messengers became so common and accessible.

I think it's obvious that SMS is outdated either way and I too think that encryption should be P2P on the "application layer" for many reasons. Encrypting the actual physical transport would add extra cost in terms of latency and hardware and could become a maintenance disaster over time if I'm not mistaking.

It'd rather reduce complexity. It'll make Go code less ambiguous leading to fewer bugs that you'll have to spend your time debugging. When working in big teams on big projects you better describe your intentions clearly.

Yes, you can hide state behind interfaces and opaque types, but you don't take into account, that the implementations of those types and interfaces need to be reliable as well. An interface with read-only types, for example, can declare its methods immutable enforcing an immutable receiver type on the implementing functions which makes sure that it's always correctly implemented and doesn't mutate its object for sure! A field can be declared immutable to make sure it remains immutable after the object is initialized, and so on. Immutable types allow you to better express your intentions when implementing something because in a month from now you'll be a different person too and you won't remember certain implementation details like "why you shouldn't mutate this inner slice in this struct" etc.

The whole concept is actually composed of 5 fundamental rules that are relatively easy to pick up. It also shouldn't be compared to C++ or even C style const qualification, because it's easier and safer.

Quick reminder on the live conversation, feel free to join us and share your thoughts and experiences!

https://t.me/yc_summer_2017

Share your thoughs with us, even if you were rejected!

https://t.me/yc_summer_2017

live conversation: https://t.me/yc_summer_2017

for all those who click the button every single minute :D

Live conversation just started, everyone's invited!

https://t.me/yc_summer_2017

South Germany (9 hours ahead) - not yet so far... awaiting