new | ask | show | jobs
CharlieDigital 2 days ago  [ - ]

I disagree on this.

I am at a (YC, series C) startup that just recently made the switch from TS backend on Nest.js to C# .NET Web API[0]. It's been a progression from Express -> Nest.js -> C#.

What we find is that having attributes in both Nest.js (decorators) and C# allows one part of the team to move faster and another smaller part of the team to isolate complexity.

The indirection and abstraction are explicit decisions to reduce verbosity for 90% of the team for 90% of the use cases because otherwise, there's a lot of repetitive boilerplate.

The use of attributes, reflection, and source generation make the code more "templatized" (true both in our Nest.js codebase as well as the new C# codebase) so that 90% of the devs simply need to "follow the pattern" and 10% of the devs can focus on more complex logic backing those attributes and decorators.

Having the option to dip into source generation, for example, is really powerful in allowing the team to reduce boilerplate.

[0] We are hiring, BTW! Seeking experienced C# engineers; very, very competitive comp and all greenfield work with modern C# in a mixed Linux and macOS environment.

com2kid 2 days ago  [ - ]

> so that 90% of the devs simply need to "follow the pattern" and 10% of the devs can focus on more complex logic backing those attributes and decorators.

Works well until the 10% that understand the behind the scenes leave and you are left with a bunch of developers copy and pasting magic patterns that they don't understand.

I love express because things are very explicit. This is the JSON schema being added to this route. This route is taking in JSON parameters. This is the function that handles this POST request endpoint.

I joined a team using Spring Boot and the staff engineer there couldn't tell me if each request was handled by its own thread or not, he couldn't tell me what variables were shared across requests vs what was uniquely instantiated per request. Absolute insanity, not understanding the very basics of one's own runtime.

Meanwhile in Express, the threading model is stupid simple (there isn't one) and what is shared between requests is obvious (everything declared in an outer scope).

badhombres 2 days ago  [ - ]

The trade offs are though that patterns and behind the scenes source code generation is another layer that the devs who have to follow need to deal with when debugging and understanding why something isn’t working. They either spend more time understanding the bespoke things or are bottle necked relying on a team or person to help them get through those moments. It’s a trade off and one that has bit me and others before

germandiago 2 days ago  [ - ]

I am not talking about C# specifically but also and I agree.

Implicit and magic looks nice at first but sometimes it can be annoying. I remember the first time I tried Ruby On Rails and I was looking for a piece of config.

Yes, "convention over configuration". Namely, ungreppsble and magic.

This kind of stuff must be used with a lot of care.

I usually favor explicit and, for config, plain data (usually toml).

This can be extended to hidden or non-obvious allocations and other stuff (when I work with C++).

It is better to know what is going on when you need to and burying it in a couole of layers can make things unnecessarily difficult.

CharlieDigital 2 days ago  [ - ]

Would you rather a team move faster and be more productive or be a purist and disallow abstractions to avoid some potential runtime tracing challenges which can be mitigated with good use of OTEL and logging? I don't know about you, but I'm going to bias towards productivity and use integration tests + observability to safeguard code.

badhombres 2 days ago  [ - ]

Disallow bespoke abstractions and use the industry standard ones instead. People who make abstractions inflate how productive they’re making everyone else. Your user base is much smaller than popular libs, so your docs and abstractions are not as battle tested and easy to use as much as you think.

CharlieDigital 2 days ago  [ - ]

This is raw OpenFGA code:

    await client.Write(
        new ClientWriteRequest(
            [
                // Alice is an admin of form 123
                new()
                {
                    Object = "form:124",
                    Relation = "editor",
                    User = "user:avery",
                },
            ]
        )
    );

    var checkResponse = await client.Check(
        new ClientCheckRequest
        {
            Object = "form:124",
            Relation = "editor",
            User = "user:avery",
        }
    );

    var checkResponse2 = await client.Check(
        new ClientCheckRequest
        {
            Object = "form:125",
            Relation = "editor",
            User = "user:avery",
        }
    );
This is an abstraction we wrote on top of it:

    await Permissions
        .WithClient(client)
        .ToMutate()
        .Add<User, Form>("alice", "editor", "226")
        .Add<User, Team>("alice", "member", "motion")
        .SaveChangesAsync();

    var allAllowed = await Permissions
        .WithClient(client)
        .ToValidate()
        .Can<User, Form>("alice", "edit", "226")
        .Has<User, Team>("alice", "member", "motion")
        .ValidateAllAsync();
You would make the case that the former is better than the latter?
badhombres 2 days ago  [ - ]

In the first example, I have to learn and understand OpenFGA, in the second example I have to learn and understand OpenFGA and your abstractions.

mrsmrtss 2 days ago  [ - ]

Well the point of using abstractions is that you don't need to know the things that it is abstracting. I think the abstraction here is self explaining what it does and you can certainly understand and use it without needing to understand all the specifics behind it.

CharlieDigital 2 days ago  [ - ]

More importantly: it prevents "usr:alice_123" instead of "user:alice_123" by using the type constraint to generate the prefix for the identifier.

hu3 2 days ago  [ - ]

How much faster are we talking? Because you'd have to account for the time lost debugging annotations.

CharlieDigital 2 days ago  [ - ]

What are you working on that you're debugging annotations everyday? I'd say you've made a big mistake if you're doing that/you didn't read the docs and don't understand how to use the attribute.

(Of course you are also free to write C# without any of the built in frameworks and write purely explicit handling and routing)

On the other hand, we write CRUD every day so anything that saves repetition with CRUD is a gain.

OtomotO 2 days ago  [ - ]

I don't debug them every day, but when I do, it takes days for a nasty bug to be worked out.

Yes, they make CRUD stuff very easy and convenient.

belmont_sup 2 days ago  [ - ]

It has been worth the abstraction in my organization with many teams. Thinking 1000+ engineers, at minimum. It helps to abstract as necessary for new teammates that want to simply add a new endpoint yet follow all the legal, security, and data enforcement rules.

Better than no magic abstractions imo. In our large monorepo, LSP feedback can often be so slow that I can’t even rely on it to be productive. I just intuit and pattern match, and these magical abstractions do help. If I get stuck, then I’ll wade into the docs and code myself, and then ask the owning team if I need more help.

speed_spread 2 days ago  [ - ]

That's the deal with all metaprogramming.

bcrosby95 2 days ago  [ - ]

People were so afraid of macros they ended up with something even worse.

At least with macros I don't need to consider the whole of the codebase and every library when determining what is happening. Instead I can just... Go to the macro.

CharlieDigital 2 days ago  [ - ]

C# source generators are...just macros?

skydhash 2 days ago  [ - ]

They are not. They are generators. Macros tends to be local and explicit as the other commenters have said. They are more like templates. Generators can be fairly involved and feels like a mini language, one that is not as observable as macros.

CharlieDigital 2 days ago  [ - ]

Isn't this just a string template? https://github.com/CharlieDigital/SKPromptGenerator/blob/mai...

Maybe you're confusing `System.Reflection.Emit` and source generators? Source generators are just a source tree walker + string templates to write source files.

mexicocitinluez a day ago  [ - ]

> Generators can be fairly involved and feels like a mini language, one that is not as observable as macros.

I agree the syntax is awkward, but all it boils down to is concatenating code in strings and adding it as a file to your codebase.

And the syntax will 100% get cleaner (it;s already happening with stuff like ForAttributeWithMetadataName