roblaszczak

> The prototype is working software. And the improvement and testing of that prototype is further enabled by more improvement loops with the AI. It gets better with more testing and verification, not through human code review, but through usage and testing.

I would love it if it was that simple :-) Agents can one-shot this prototype and that feels like they are "almost done". The hard part starts when we try to make it production-grade.

I'm not saying that it's not possible, but it requires more effort than productionizing a PoC that we used to create "by hand". We start to discover shortcuts taken by the coding agent and we spend 80% of the time on getting the last 20% right (but to be clear, it's still less time than writing it by hand).

It looks like the author may not have hit this reality check yet:

> Of course, neither of these things is currently shipped, or supported and isn’t what I’d call production ready software. So you could say what many say about AI, which is that it helps you ship the prototype faster. But that isn’t really giving enough credit here.

For AI-generated code, finding "the last 20% rough edges" is much, much harder than creating PoC. Often the rough edges are buried in the code that we don't know. Fixing those problems requires big refactors that, for wrongly architected code, can break other things.

Tests help, but that's not enough for models to autonomously fix them. If they make one error, it compounds over multiple iterations.

It's especially true for problems where we don't have a clear oracle. It's impressive that models can brute-force problems with a clear oracle. But many problems where a clear oracle doesn't exist (a lot of business software that I know) will still require a lot of product engineering.

Maybe it will improve? I'm not sure if it can happen with hallucinations around (from what I see, they are still a big deal for domains that agents are not trained on).

Hey HN, Robert here, creator of Watermill.

Over the past few years, I've watched a sad trend: many companies are aggressively monetizing open-source. Thanks to being bootstrapped, we don't need to take that path with Watermill.

For 7 years, we've been building Watermill in the true open-source spirit—all components are open. We don't obscure documentation to push users toward our consulting services.

In that spirit, we've created a hands-on quickstart that teaches Watermill's core concepts through a real-world project. Since browser-based environments don't cut it for real-life projects, we built a custom platform that handles all the setup and verification directly in your IDE.

Rather than say more, I'd encourage you to try the quickstart yourself!

Hey, Robert here (author). We are the opposite of companies with big funding and quick success. I also know that software engineers education is not the most viral topic here. Nevertheless, seeing success stories not following beaten paths may be valuable and eye-opening. Long-term sustainable growth and learning by building are undervaluated.

If you have any questions or feedback, I'm more than happy to hear it!

Hey, Robert here (author).

We are the opposite of companies with big funding and quick success. I also know that software engineers education is not the most viral topic here. Nevertheless, seeing success stories not following beaten paths may be valuable and eye-opening. Long-term sustainable growth and learning by building are undervaluated.

If you have any questions or feedback, I'm more than happy to hear it!

Glad to hear that!

Hey, it's Robert here, author of the library.

A few years ago, I worked on a project where we wanted to use Event-Driven architecture. But most team members were unfamiliar with it and uncomfortable working with asynchronous architecture. I asked myself: "Is it possible to make building an Event-Driven application as simple as building an HTTP API?" — and that's how Watermill was born.

We currently support 12 Pub/Subs, including Kafka, Redis, AMQP, and NATS. We also support MySQL and PostgreSQL-based Pub/Subs, so you can use Watermill even if you don't want to add extra infrastructure to your tech stack.

It's handy for: 1. Building event-driven services 2. Implementing CQRS architecture 3. Creating complex message processing pipelines

We also support poison queues and the outbox pattern out of the box and provide middleware that supports logging, retries, and circuit breaking.

Watermill is an independent project under the MIT license. We don't plan to get VC funding, and nobody from outside can force us to change the license to monetize the project.

We released Watermill v1.0 more than five years ago, and since then, we have kept backward compatibility.

We plan to release v1.4 soon, including updated poison queue support and sending delayed messages.

I'd love to hear your thoughts and feedback. If you have any questions, I'm happy to answer!

Links: GitHub: https://github.com/ThreeDotsLabs/watermill Documentation: https://watermill.io/ Examples: https://github.com/ThreeDotsLabs/watermill/tree/master/_exam...

SlashID | Principal Backend Engineer | REMOTE (EU compatible time-zones) | Full Time

We’re an early stage startup building an identity platform. Our goal? Bring authentication for users, machines and APIs under the same (secure) umbrella (aka one identity platform to rule them all). We’re looking for people who can design, build, and maintain distributed systems at scale. You’re also driven, product-oriented and enjoy getting your hands dirty; extra points for experience in security. Stack: Go, GCP, Redis, PostgreSQL, Docker, Terraform. You don't need experience with all these but should be willing to learn).

Get in touch at careers@slashid.dev or apply on our website https://www.slashid.dev/careers/principal-backend-software-e...

Hey HN! I'm Robert, and I'm one of the authors.

With my friend Miłosz, we've been working on a way for experienced developers to grasp Go quickly. After long evenings and weekends, we're ready to share our idea that we think is unique.

Many Go courses cover lots of details irrelevant to most developers. The difficulty level is chosen for developers with all levels of experience. Often, they consist of videos, which makes them long. Or they make you write code in the browser. We believe that it’s not the most optimal way of learning. We decided to approach this topic differently.

While learning and teaching new technologies, we found that implementing real-life projects incrementally is the best way to learn. We decided to recreate this method of learning, but in a more structured and automated way. We created a Go training for experienced developers, containing the most relevant knowledge. It quickly makes you comfortable writing Go code.

The training is made of 80 exercises based on real-life projects and examples. You write all the code in your local editor or IDE. Our CLI provides the boilerplate code for the exercise and fast feedback about your solution.

The first four modules are free after registration. The entire training is free for students (please check the FAQ[1] for details). We are not aware of any similar training out there. It would be great to hear your feedback!

[1] https://threedots.tech/go-in-one-evening/#faq

Hey HN! I'm Robert, and I'm one of the authors.

With my friend Miłosz, we've been working on a way for experienced developers to grasp Go quickly. After long evenings and weekends, we're ready to share our idea that we think is unique.

Many Go courses cover lots of details irrelevant to most developers. The difficulty level is chosen for developers with all levels of experience. Often, they consist of videos, which makes them long. Or they make you write code in the browser. We believe that it’s not the most optimal way of learning. We decided to approach this topic differently.

While learning and teaching new technologies, we found that implementing real-life projects incrementally is the best way to learn. We decided to recreate this method of learning, but in a more structured and automated way.

We created a Go training for experienced developers, containing the most relevant knowledge. It quickly makes you comfortable writing Go code.

The training is made of 80 exercises based on real-life projects and examples. You write all the code in your local editor or IDE. Our CLI provides the boilerplate code for the exercise and fast feedback about your solution.

The first four modules are free after registration. The entire training is free for students (please check the FAQ[1] for details).

We are not aware of any similar training out there. It would be great to hear your feedback!

[1] https://threedots.tech/go-in-one-evening/#faq

If new hardware or technology is totally changing your solution - it's a bad sign.

It depends a lot on the domain on which you are working on. In places where I worked, such big changes could be encapsulated and separated from the domain logic (by using Clean Architecture, for example).

This is where modelling techniques are useful - with proper exploration you can create proper boundaries that will save you from such big changes. The only thing that is constant is change. It's all about being prepared for that.

You are right - I'm using it as as shorthand. It's referring to the "typical" monolith architecture perception.

I'm actually a big fan of modular, properly implemented monoliths. In the first blog article I was even showing that it can be actually an implementation detail if an application is monolith or microservice: https://threedots.tech/post/microservices-or-monolith-its-de...

Also as the context, most of these companies where PHP, Python, Ruby or NodeJS. In that case migration to Go had a lot of clearly visible benefits.

Pleasure is all mine!

> You're missing one key question in your list: "How much (time/money) will it cost and what will be the gain?"

I guess it depends on the situation of the company. But I guess that before doing such movement, company should do a pilot to verify if introducing Go can solve currently existing issues (with development velocity, bugs, performance etc.). After that answer should be simpler :)

> Two key aspects to that question: whether/when/how to re-write existing systems in Go and how re-written or new implementations integrate with the existing ones. It also really depends, but from my experience companies that were switching to Go were keeping legacy part and people who were able to maintain it. In the meantime they re-written what was worth to be re-written. Without touching old part too much.

In that case yo can stay with a situation where you have some developers of old technology and some of the new one. But AFAIK it was not a major issue.

The good news is that Go have very little entry point. Thanks to that you can hire people, who are working in other technologies and are interested in learning something new. From my experience they can be productive within a week. It's totally not possible with Java I guess ;-)

It's probably a bigger problem to justify it on the company level. It's always some risk to go with a language that doesn't have such good position on the market ("Who will maintain it?", "Where you will find people who will fix it?", "Wouldn't this language disappear in 2 years?").

Fortunately, a lot changed in recent years. Thanks to Kubernetes, Prometheus, Docker and all other infrastructure Go is already used in the most of the companies. That's giving people much more confidence about Go.

> While protocols in Go are great (one of the very many breaths of fresh air that Go provided), operations on data structures without generics does not seem like a good time. Does everyone get around the lack of generics by making most generic-looking operations slightly-specialized structs and some interface composition?

When it comes to domain code - probably when you are starting to think about generics that's a bad sign. Probably you are trying to make it overcomplicated. Domain code should stay simple and interfaces should be enough to handle it.

But when it comes to libraries the situation is totally different. One of the example is https://watermill.io library (that we are authors of BTW). Generics could give some nice simplifications.

It's also a case for event-sourcing library that we are using in the company where we are working on now. But You can still do a lot with interface{} and reflection. But it's not perfect and generate a lot of boilerplate.

The third example is a decorator pattern. You can't create generic decorator without code generation. It is of course some sort of the solution, but it's not trivial to implement.

Hey, unfortunately our e-mail automation is a bit slow. It should arrive to your mailbox within couple minutes :)

I'll add information to subscribe confirmation page about the delay.

> In my experience, it's easier to reason about and build systems when idempotency is an application level concern.

This is exactly what we are doing in my company :) But it’s always good to have an option and know that we can do it in specific cases without external calls. In this scenario it can be nice simplification.

Exactly-once delivery is covering processing in this scenario. Because of that it is not covered in tests and schemas. REST endpoint was just added to create entire use case. But you are right, if in this part of the system something will go wrong you will have duplicate message. But it’s rather at least once publish rather at least once delivery. Message will be delivered once, but published twice :)

This is also what Google suggests:

> Please associate your commit with your google.com email unless: - You have a history of contributing to the repo under a different email before your employment at Google Source: https://opensource.google/docs/patching/

> The release process applies to all types of projects: personal (at home), 20%, and new Google open source releases that aren’t part of and following the release process of an already-established Google open source project (like Chromium or Android). Source: https://opensource.google/docs/releasing/#patching

It’s a bit less strict, but signing work that I’m doing after job with my job e-mail doesn’t sound fair.

After a quick look, IMO Watermill is a bit more flexible, because of middlewares and decorators support ;)

And what is unique, Watermill provides some high-level concepts like messages Router or out-of-the-box CQRS support which is really helpful when you are building bigger application.

We are a team of three experienced software engineers, specialized mostly in advanced backend solutions. We can help you with building RPC/REST or Event-driven applications based on Kafka or any other Pub/Sub. We also have experience in introducing Continuous Delivery and DevOps culture in teams.

Location: Cracow, Poland, European Union

Remote: Yes

Technologies: Golang, Python, Kafka, MySQL, Elasticsearch, Kubernetes, Docker, CI/CD

Résumé/CV: https://threedotslabs.com/

GitHub: http://github.com/ThreeDotsLabs

Email: robert@threedotslabs.com

added ;)

for examples like this it is much better to explicit ignore error:

_ = index.Index(identifier, your_data)

it will also pass https://github.com/kisielk/errcheck check

eventually we can just panic error

if err := index.Index(identifier, your_data); err != nil { panic(err) }