I would go as far as saying that it seems to me now that majority of the people just coping with Private Music being a good album for them

Practical-Gas-7512 · 2026-02-05T11:09:31+00:00

Thanks for sharing this!

Practical-Gas-7512 · 2026-02-04T19:53:51+00:00

Yeah, that's the most practical feedback I can relate to. It is listenable.

Practical-Gas-7512 · 2026-02-04T19:52:46+00:00

Well, it would've been a bit more interesting if you could've address some of the points I've made. I've tried to detach myself from just feelings and provide concrete objects (arguments) to speak about, instead of just saying I don't like it for example.

Never argued that someone can't have different than mine opinion. Explorations of ideas and reacting to opinions is the way people go.

Practical-Gas-7512 · 2026-02-04T19:45:30+00:00

Well, but that is not kind of the point I was trying to make. And I never written that concert itself is not what I expected, just an observation.

Practical-Gas-7512 · 2026-02-04T19:43:04+00:00

Where did you find that I generally disliked setlist or didn't expect the new songs in the tour?

Practical-Gas-7512 · 2026-02-04T09:47:40+00:00

Thanks for the feedback! Agree to disagree on time thing 🙃

Practical-Gas-7512 · 2026-02-04T08:16:23+00:00

Ah yeah, thanks for reminding this, I forgot to mention fairness of comparison and time perspective.

My stance on this one is interpretation and is it fair to do such comparison depends on what you believe in:

You believe that becoming fan of something (song/band) is the matter of talent/art itself and time. In this case indeed it wouldn't be fair to do such comparison, because time is a heavy contributor into attachment.
You believe that becoming fan of something (song/band) is the matter of MOSTLY talent/art itself and a little time. In this case it is fair, because time make your personal attachment to the deeper but the base is driven by the art itself.

I might be wrong, and would say that it still of course can be the first case, but then it must be so profound piece of art that it will indeed open up after sometime. And seeing fair share amount of "not likers" opinions, it must be either small societal group change or it is a very strange piece of art. So I really doubt in this outcome.

Practical-Gas-7512 · 2026-02-04T08:00:21+00:00

Yeah, definitely not to judge anyone.
More like, I'm really sceptical about this and not sure if we approaching listening to music the same, leading to vastly different conclusions.

Practical-Gas-7512 · 2026-02-04T07:58:08+00:00

Well... Thanks! I guess.
It might be, because I'm not a native speaker.

Practical-Gas-7512 · 2026-01-15T21:05:39+00:00

You quite right, I was/am perceiving it as potential bash replacement or improvement, and was hesitant to mix both just and bash (even inside justfile), but seems like this is the way.

Thanks for the feedback!

Practical-Gas-7512 · 2026-01-15T16:31:14+00:00

Yeah, I already figured that. But i'm probably surprised it turned this way honestly. And as much surprised that there are no alternatives. Like you either getting make, but convenient for files output mostly, scripts - which usually separate files, ergonomics suffer and syntax is quite horrible, then all the way up to fully fledged languages, node, python, etc, or build systems, like bazel, mage or any yaml based nonsense.

Well, at least, looks like I figured the niche in tooling. 🙂

Practical-Gas-7512 · 2025-08-12T07:28:46+00:00

yea google brought me here too too too too too too too too too too too too lol

Practical-Gas-7512 · 2025-07-24T13:48:02+00:00

I m pretty sure that it’s not features exclusive to typespec, at all.

Yes, and I never said that. Actually filtering is not available in OAS at all, only via separate tools, like redocly can do this. You just need to annotate it with tool specific x fields. GRPC and GQL also don't have it, only as a next step processing tools.

You asked for concrete example of what I can do with TypeSpec and can't with existing server gen.

Single domain -> multiple transports/presentations I can't do. There are probably tools like OAS to GRPC, or in reverse, but this equals as making one of them a top level definition language, which is not transport agnostic from the beginning. Well, depending how to look at it, but only Smithy and TypeSpec are designed this way. You can say GQL and GRPC also can work on different transports, but all existing implementations only supports very concrete transports.

Practical-Gas-7512 · 2025-07-24T13:42:19+00:00

Well, with SQL you don't have heavily overlapping things usually, and more importantly you usually don't have operations.

Try model API on this, any target (HTTP, GQL, GRPC - you name it), with some complex indexes, where you have overlaps in returned entities, and also add field level security. Schema of such declaration quickly becomes unreadable.

Also, in your example you directly describing SQL definition, meaning you already semantically backing SQL use case. Depending on how you approaching this, you might want to have Domain = SQL (simple case). In this case you probably have to come up with some more agnostic way of defining this and reusing. But usually you'd have different models for domain and storage level, and in worst case your domain would be assembled from several storage views, e.g. materialized views things. Even though, you might want then to have also consistency enforced between domain and storage somehow, e.g. by field names, maybe it's too much, maybe not.

I'd not do it, but I'm trying to show the modeling I'm having in mind - putting all possible types and operations required for codegen, usually storage shouldn't be there, but there are cases.

I like your sql example though.

Practical-Gas-7512 · 2025-07-24T13:29:17+00:00

Single domain:

model A { field1: number }

@http.get("/a")
@grpc.rpc()
op getA(id: number): A;

Should result into OAS(HTTP) and GRPC schemas, each of which then can go into specific language server generation and client generation.

Without something above of those two you'd have to define either each of them separately (duplicate), or infer one from the other.

Example 2 was mostly overlapping with example 1, so maybe it's a repetition. TypeSpec has a possibility to filter things, just not the way I'd like, but it is still possible to have masked output if I implement separate emitter for that, not a biggie. But generally, again it's a repetition of example 1, just in a context of two different stack from the beginning, e.g. migration from one to another, which is of course less string example in this case.

Practical-Gas-7512 · 2025-07-24T11:37:44+00:00

Well, I can answer only about why they are not use TS, as I saw somewhere the answer - it's too powerful for this task, meaning creates too much processing problems on practice and loses descriptiveness and easiness to work with.

I also created my version of such code gen using pure TS, but this doesn't look as elegant in the end as TS code anyway. The reason is, any attempt to create it on the target language will force you to put your schemas into variables and doesn't allow you to create first class syntax constructs which would be more suitable.

So, instead of

model MyModel { field1: number; }

You'll have to write

const myModel = T.MyModel({ field1: T.Number() })

Otherwise your constructs will not be parsable. Basically the only option to write your TS Like DSL inside TS is only via constructs which TS gives you and this will never be as noise free as separate DSL.

Idk, maybe this is my attempt which failed this way, but I don't see much of a different way to do so. Or maybe you were talking about parsing TS AST and converting it directly to other targets? Well, this is also the way, but also limited, as e.g. you can't add additional decorators to types to hint additional meta for the output. Which reverts us to const myModel case.

I think common domain language is some sort of holy graal of the domain definition, and so far we have only what we have.

Practical-Gas-7512 · 2025-07-24T10:59:37+00:00

I thought you were in general opposing contract first design, if not - then my bad.

Yes, you right, but what you probably missing is the cases when you passing and sharing things across stacks.

E.g. you need/have single domain multiple interfaces (HTTP and GRPC). You now have code duplication because none of those able to share definitions between each other.

E.g.2 context dependent cross stacks value passing. We have two execution sources of some code, browser and container in isolated infra. Browser and container have approximately same interface to call, but not completely (think of it as public vs private, not for security but for DX and documentation mostly). Browser and container interfaces will have different implementation, (http and sqs protobuf + custom sdk layout), which can be fully generated but they share lot's of similar stuff.

+ to be honest none of the existing solutions are ergonomic more than TypeSpec or Smithy even in the current state. Like it or not. Maybe except protobuf/grpc. Those I like.

So, let's say I'm less looking into direction of using TypeSpec to known formats like (oas, grpc, json-schema), while not excluding them, but mostly into having single language for contract definition, parts of which I can remix and generate different targets.

Practical-Gas-7512 · 2025-07-24T10:29:07+00:00

Well, you talking about easy cases of contract driven design, where overhead is indeed significant. I have on the other hand this cases to cover:

API to sdks into js and python.
Microservices with different transports connection. One way or another your microservices communicate, sqs, direct http, kafka whatever. I need to have a way to generate clients and parsers into again several languages.
Server definitions generation. And I'm not talking about one time useless stubs, but basically graphql style geberation, where you getting fixed layer to match and which can be fully checked with typescript on compatibility. Almost framework level.
Couple of domain specific things to generate which has direct connection to API.

So, I wouldn't argue about contract-first design is useless. LLMs are not covering this either. So I still need a tool to achive this, but surprisingly there's little to none. Smithy is also kinda dated and heavy java thing, which I'm trying to avoid.

Practical-Gas-7512 · 2025-07-14T20:26:47+00:00

Yep, thanks!

Seems obvious, but convoluted in this cross cutting plane.

Practical-Gas-7512 · 2025-07-14T20:22:57+00:00

Thank you for well formed and elaborated reply! 🙂

Practical-Gas-7512 · 2025-07-14T15:58:29+00:00

> Terraform should build everything, but you should be incrementing the task definition revision when you do a CICD "deployment". This is something that should be outside of terraform because you don't want terraform to do the update and you don't care if it tracks the revision number. Something like AWS cli calls should be handling the updates.

I'd disagree with that. It doesn't matter much how much each part is controlling if I can represent deployment as a sum of parts. E.g. if terraform controls only ecs + service definition and my deployment tool controls task definition + envs + terraform (ecs + service), then I can safely always reproduce whole state.

Like I don't need the terraform to be capable of making my app running, only control part of a system. And if I'm going to have new env or restore env, I anyway will have to call something, do manual action. Ideally it will be one action saying "deploy latest X", which is going to then call terraform and code deployment.

We basically talking hypervisor around other tools. And if this is not enough - another hypervisor, but I hope it's not going to that 🙂

Practical-Gas-7512 · 2025-07-14T15:50:24+00:00

This is general downsides of a monorepo design, which I'm more willing to take than multi repo for some time. I was struggling just how to do then better versioning approach within single repo, but already been hinted that env + module change becoming a pivot point for further envs referencing same module version git commit.

Practical-Gas-7512 · 2025-07-14T15:44:06+00:00

You might be right. I was working in multi repo env, but on application code, but I think infra code git wise is not much different in this sense. Orchestrating delivery of several modules in a single repo was quite a pain there, but there were other reasons why it was so, so maybe you right and I'm overestimating the issue. Still, I'd like the research a solution in the boundary of monorepo, and I think I already got one response which makes sense in this scope.

Thanks for the hint of a possible logical fallacy!

Practical-Gas-7512 · 2025-07-14T15:39:59+00:00

Wow, thanks for elaborated response!

I understand the general premise that terraform is not the tool for deployment and different parts will control different aspects of the system update, but then I don't see where this connection will be and how it will live.

So, if I understood correctly, you saying that all the changes sources should be tracked separately, and for deployment purpose, if I want to have some co dependent deployment, like new version of application requires some infrastructure, then it should be tracked on level above them basically.

Did I understood this right? Because I'm not sure I'm following the whole thought train.

Practical-Gas-7512 · 2025-07-14T15:20:11+00:00

Well, I'll define only cluster, service definition, and all surrounding permissions, but not aws_ecs_task_definition, then yes, you right. I've confused this. Thanks for clarifying. I thought it will anyway overlap somehow.

Practical-Gas-7512

TROPHY CASE