Hacker News Reader

Comment by GordonS | Hacker News Reader

I don't really feel like there is that much more boilerplate with C# than there is with TypeScript (although I do like TypeScripts's ctor shorthand that creates members for you from ctor params).

C# 9 also brings top-level programs, which essentially eliminate all ceremony for the entrypoint[0] - an app can now be as simple as:

  using System;
  Console.WriteLine("Hello World!");

[0] https://dotnetcoretutorials.com/2020/08/30/top-level-program...

View on HN

It depends how you write TypeScript. It's explicitly designed so that you can write it like C# if you want to (classes, interfaces, enums, dependency injection), but you can just as easily compose plain data types and write plain first-class functions and never touch classes.

Aren't top level programs basically "baby mode" for relatively simple programs or web webassembly based examples that target beginners?

As far as I've heard it does not exist e.g when it comes for ASP and I believe that what "OP" meant.

I may be very wrong here

I haven't used C# 9 yet, but I write a lot of console apps and services/daemons using .NET Core (the world is bigger than web apps :), but I don't see why you can't use top-level programs for ASP.NET Core apps, as they have an entrypoint too.

You would of course still have all the usual ASP.NET configuration and DI setup to do though, so the impact would be rather limited.

>as they have an entrypoint too.

I meant that (as I've heard) you cannot write big app using "top level style" only/mostly

It probably isnt going to reduce "the boiler plate" that people complain about

It will reduce some boilerplate but only for the entry point method

My understanding of this feature is that it's to encourage beginners to write code that does something without first having to learn about namespaces and the entry point concept. I expect most commercial apps and open-source projects will continue to use namespaces and an entry point method in their code.

Exactly! And on top of that I've mentioned in many conversations how teaching Java and C# as a first language often confuses people into believing that programming is about syntax rather than logic, because they spend so much time searching for syntax errors in their first hello world application.

For hello world with 29 tokens if i count correctly for C# vs 4 tokens for a Python program, guess where beginners have an easier time to fail?

It’s also great for testing concepts or libraries, “what happens if I call this object like this or like that?”

I used to use LINQPad for that, now I don’t need to, VS Code and this new feature is enough!

Don't you guys think that entrypoint is only 0.0000...1% of your development time? Not having to write Namespace, class, main method (which comes in template anyway), is not something I would use to compare languages.

Its nice for beginners, not having to explain every weird word they see, but not much for professional development.

However managing complexity with various language features all over the project makes impact.

If you're working on the same code-base for years, then yes.

If you write a few programs per day for throw-away data manipulation or system maintenance or something, then no.

Maybe they were thinking about REPL, scripting and Jupyter style notebooks.

Having this feature aligns nicely with those use cases.

.net core web is pretty much a mess. The very sight of dependency injection configuration is cringe. Even having to make the decision to go tables first or code first is a burden. I'm surprised at myself for saying this but given the chance I'd much prefer spring boot.

>Even having to make the decision to go tables first or code first is a burden

>he very sight of dependency injection configuration is cringe.

I'm curious - why?

Coming from a different perspective: Once you've been using Entity Framework for a while (I assume the OP is referring to EF, since there tends to be a 'Use what microsoft ships' culture in the .NET community), is that the APIs available to a "Code First" approach vs. a "Model First" approach are different. If you use Code First and Code Migrations, you don't have access (without getting out of Code First entirely!) to creating Views; and in EF 6 at least, creating indexes was a chore as well. I believe this has been fixed in EF Core; but regardless the mainpoint still stands: The APIs are different and what is natively available is different. At some point doing "Code First", you'll still need to write raw SQL, and that's unexpected if you are planning on doing your work in C# only.

Regarding Dependency Injection: It's very much suited towards enterprise web applications; and its failure mode is trying to get DI to work seamlessly in a non-web application sense (C# is a general language; and .NET supports console, GUI, and web applications) and once you get out of the we application thread-per-request pipeline, you find yourself hitting rough patches.

Op HSCK 12

I believe the smart advice says don’t go code first if you already know what you’re doing with SQL but it’s definitely sad that there’s such a huge barrier between these modes.

As for DI it can definitely be used fruitfully outside of a web application, I suggest the book Dependency Injection: Principles, Practices, and Patterns if you’re curious. It covers examples from ASP.NET Core MVC to console apps to GUI.

I've iterated on the style of my own development over time, and I hadn't really stepped back to look at where I was now for a while. Interestingly enough, I find that I've "worked around" both of the things you mentioned in one way or another.

I use EF, but generally only for migrations, and use Dapper for all the actual access. This avoids a lot of the headache I've had in the past with EF tracking, lazy loading, and foreign keys. I also avoid using views for anything, even at work where I can guarantee with many 9's worth of certainty that I will always be using MSSQL. Part of this is because EF doesn't support it for Code-First, but part of it is also generally trying to be proactive rather than reactive and pre-generate anything I'd be using a view for. Being able to more easily switch providers and move to a different RDBMS is just a "perk" that I'll likely never take advantage of.

I despise the Microsoft DI system. I won't bother going into details, it just doesn't seem to work "right" (that is, the way I want or expect it to). On the other hand, I've used Autofac for years and just seem to "get" it, so I sometimes go to relatively great lengths to use it, even when the Microsoft version would have been a lot easier to get up and running.

EF alone is a great reason to avoid the .NET ecosystem in my experience.

You aren't forced to use it. It's strange that a single library would make you avoid the entire ecosystem, even though it's one of the most advanced ORMs available.

It permeates everything .NET; try finding documentation that doesn’t assume you’re an EF adherent.

Any documentation that doesn't have to do with EF has nothing about EF. You can use whatever data access code you want. There are thousands of examples of Dapper, for example.

"Dependency injection" frameworks look to me like a hack. In a more expressive language, such as F#, one could probably describe what needs to be done symbolically, and then write interpreters that implement the different behaviours required.

The entire web platform is a mess because of an unclear complain about configuration? You could at least try being specific if you’re going to make such stark claims.

Reply on news.ycombinator.com