Hacker News Reader

Comment by jeswin | Hacker News Reader

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so easy. If you're writing a Web App/Service, the Framework APIs and most popular libraries will nudge you strongly to use Dependency Injection throughout the app and implement everything as a class and to extract interfaces out of it.

My wishlist for C# is short:

- Allow functions outside of classes

- Structural typing

- Files and directories already provide excellent namespacing. Adopt it instead of forcing namespace declarations

Btw, Linux as a deployment platform works quite well.

View on HN

> Allow functions outside of classes

Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class.

But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design.

> Adopt (files and dirs) instead of forcing namespace declarations

Likewise.

> Structural typing

Like "dynamic" in C# 4 ? Been there, done that and it didn't take off really. It's useful for some interop cases and that's about it. Strong types, with type inference is more suited to the language design.

https://stackoverflow.com/questions/2690623/what-is-the-dyna...

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Structural typing is different from dynamic typing. C# supports structural typing in the form of tuples and anonymous types. But you can't return an anonymous type from a method. This is a significant limitation.

As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".

You can't return an anonymous type, but the syntactic difference between an anon type and a tuple is two characters: parens instead of curly braces.

And the little "new" in front of it. I actually preferred the curly braces version and would have loved for them improve it instead of creating a replacement.

And well, I'd expect them to get it right eventually. It is at least their third evolution of that feature... there was a System.Tuple as well. Wonder if they ever come out and officially deprecate their earlier attempts.

> Wonder if they ever come out and officially deprecate their earlier attempts.

That (mostly) doesn't happen.

I would say that .NET Core was the sole attempt to deprecate a lot of the framework. And most of it came back anyway; see the title of the parent article.

I don't think C# have ever deprecated language features. You can still use the old "delegate{}" syntax even though we have the more concise arrow syntax.

Why are "free" functions useful? What actual real difference does it make compared to putting an extra word in front to call the method?

You don't need to put the extra word in front since "using static" was introduced. But you still need to define a useless static class.

> But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design.

Fairly complex programs can be written with just plain functions, all of them elegantly starting off column 0 instead of being tabbed for namespaces and classes. It works especially well with directory structure based namespaces. eg: Microsoft's own TypeScript.

> Like "dynamic" in C# 4 ?

No not dynamic, I wouldn't use that very much either. https://en.wikipedia.org/wiki/Structural_type_system

It sounds like you are using the wrong language. F# is what you want to be using.

> No not dynamic

Ok, I see that structural typing is a third type system option.

But honestly, I don't want C# and .NET to contain every feature and paradigm ever created. It would be bloated and hard to use. Already there is significant legacy and different ways of doing the same thing, and it's likely to get even worse.

If the language that you ideally want is built around structurally typed free-floating functions, then it probably isn't C#. It probably exists, it's likely possible on the .NET platform, but it doesn't work and think like C#.

> But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design.

That's what the Powershell integration is for.

> That's what the Powershell integration is for.

And projects such as scriptcs and cake

http://scriptcs.net/

https://cakebuild.net/

If you'd like to develop on Linux, I suggest trying Jetbrains Rider. It's as good as VS in most cases, and better in several. I've used it as my primary IDE for most of this year.

+1 for Rider. It's basically ReSharper.

Including resource usage! As anything on top of InteliJ.

JetBrains stuff does feel sluggish and occasionally hangs on my 2016 XPS-13 with 8G of ram. It gets the job done, but it's not pleasant.

On my new Ryzen 3600 with 32G of ram it runs smooth. So if you go for JetBrains, I definitely advise not to cheap out on the hardware.

Rider on Linux was very good for me, working on C# azure functions.

32G?!? Where does one find such employers???

Not to mention how crazy it sounds having 32GB for an IDE.

Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.

I had a 32GB dev machine in my last job at a bank. 8GB is barely enough to run a full-on IDE, but if you also need to run wireshark, Geneos, outlook, big-ass excell sheets, several browsers with over a dozen tabs each, a bunch of communications tools, other office apps etc, etc, I'd regularly go above 20GB memory usage.

I was working app support really, with a fair bit of dev work as well, so needed to run a ton of different tools.

I'm not even at a tech company and requested 32GBs, as I sometimes have VS and Android Studio open, running mobile emulators and checking what is going on the API end. You add VMs to the mix and one really needs 32GBs. My company had no issues providing the ram. Plus, it is insanely cheap right now.

I am self employed, and invested the lump sum of 800€ (+ screen that I already head) for a reasonably beefy desktop machine. I'm not saying that 32G is the minimum required to run JetBrains IDEs well; I'm saying 8G is not enough and 32G is definitely enough to run it alongside a bunch of containers and other stuff.

I agree that JetBrains stuff is resource hungry (maybe excessively so); to me it is still worth using it for Java, C#, Python, iOS and Android. For C++ I prefer Qt Creator (though I must say that the idea of switching to CLion and having a consistent IDE experience across all platforms that I work on is tempting).

In my current role, I was given a laptop with 8GB. An additional 24GB mysteriously found it's way in there after a couple of days...

It depends on your use-case.

Add Docker, VM, development database server etc. to the bill, and a 32 GB machine is pretty reasonable for a dev.

All the Dev machines where I work have been 16GB for years, I wouldn't be surprised if we jumped to 32GB in the next hardware refresh.

These days 32G is starting to become more of a necessity as apps take more and more RAM. And if you're a gaming, 8G doesn't cut it anymore for some games;

On a brand new machine (just verified), Visual Studio cannot keep up with my typing - a problem that has existed since the VS .NET days. IntelliJ may take a little extra time to start (though, not a huge amount more), but it has never suffered from that problem, even on much lower end boxes.

One of the nice things about Rider, though, as opposed to ReSharper, is that it can be run as 64-bit, and you can control the size of the Java memory heap, rather than being jailed inside the 32-bit devenv.exe process.

Visual Studio with Resharper chokes and dies pretty badly when you get into large solutions with 100k+ LOC and many projects. For years I've been seeing problems when memory usage gets close to 2GB, and the editor and intellisense starts getting laggy and unresponsive. For whatever reason, it is really bad if you have web applications with JS in the mix, to the point where I have resorted to just running WebStorm in parallel to do any front-end work.

something I have noticed with vs 2019 is that it creates lots of processed, presumably to try and give itself more than a single 32-bit address space

Seconded. As another commenter on this thread said, make sure you have a powerful enough machine. I work with Angular a lot. For me, Rider's killer feature is Angular integration [1]. It is far more powerful than Visual Studio's.

[1] Other paid-for Jetbrains products such as IntelliJ Ultimate have the same integration

The closest you'll get to free floating functions are methods in a static class. The static classes essentially become namespaces.

Then with static using directives, you don't need to spell out the namespaces.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

You can even put every global function into a single class but still organize your code across multiple files by making them all part of the same partial class.

I personally wouldn't organize my code this way, but it seems like you can achieve what you want today with minimal effort.

> Then with static using directives, you don't need to spell out the namespaces.

Static using directives! Certainly a useful tool, thank you. I had been away from the .Net universe for a while and I think I have some more catching up to do. Some of the newer changes in C# help a lot with reducing code heft, even though it makes the language more complex.

However, the Framework seems to be headed in the opposite direction when it comes to simplicity. Here's for example the IOptions pattern: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...

I really wish the documentation for things like DI, IOptions and ILogger were moved out of the ASP.NET documentation. Trying to decipher from the documentation how to use these in a non-ASP.NET project is needlessly complicated.

It's getting pushed out of ASP.NET with the "Generic Host" efforts. It's still for the time being in ASP.NET documentation, but you see it's moving in that direction.

https://laurentkempe.com/2019/09/03/WPF-and-dotnet-Generic-H...

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...

The asp configuration thing is complicated but powerful. If you don't want that, you can just use ``Environment.GetEnvironmentVariable`` and be done with it.

Plus it’s barely any extra work to load settings from environment variables. And it lets you write code agnostic to where the settings are coming from, and then choose to load them from environment variables, a file, hard coded values, etc.

Makes testing easier too because you don’t have to write a fixture around your settings. Just build the class with known setting values without writing code purely for testing.

I have found that large partial classes declared across many physical source files creates lots of issues with intellisense throughput. At 50+ partials, you are looking at solid 10+ second delays in the IDE between when you typed something naughty and when you are informed of it. This behavior has been replicated across many different computers and versions of visual studio, so I think it's just a fundamental limitation.

We have some solid use cases for free floating functions (e.g. business rules that need to be able to arbitrarily invoke each other) which we ultimately decided to scope to one public function per class. This allowed for some other interesting advantages in terms of consolidating tightly-coupled business logic that was formerly spread across the codebase (e.g. items used only by the one function - mappers, request/response models, private utility methods, etc). We even explicitly duplicated out some logic in order to enable completely isolated verticals of BL.

Don't get why people want floating functions. It makes easier to do bad coding and architecture imo. At least you must namespace them;

Consider something like the Math class. In practice it just works like a namespace for math-related functions. The only reason to have a class is because the language requires it.

It would certainly be cleaner without having to define a useless class.

Well, a static Math class always did make perfect sense to me. Never bothered me. Even after I discovered languages that allow you to define functions everywhere, I still prefer static classes; As long as there's no performance penalties, I'm good. In fact, static classes method calls are really fast;

Yeah, except I like that Log() isn't already a reserved function name.

I don't think anyone is suggesting the function names should be reserved names. They would still exist in a namespace.

I don't really understand how this is significantly different than having a static class with the function

> My wishlist for C# is short: [...]

F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.

It doesn't give you structural typing, it's still normative:

https://stackoverflow.com/a/3137561/57094

Nominative, not normative. Nominative means "by name", i.e. you reference types by names. A structural type (aka anonymous type) does not have a name, so cannot be referenced.

Yes, I meant nominative.

It also has syntax for structural typing where needed.

https://www.infoq.com/news/2019/01/fsharp-4.6-preview/

Works for personal projects and is certainly a joyful experience. But recruiting developers is near impossible - which is key for the kind of projects/companies I work with.

I've heard this before, and frankly, it is not something I recognise.

A few years back, I was the VP of Engineering at a (now well-known) startup that had chosen to use .NET (on Azure, which is a whole other story). Everything was written in F# by default, _occasionally_ branching out to C# or C++ if it was proven that F# was unsuitable for the job.

We managed to hire a very large team in comparatively little time - and because people who apply for F# jobs either know it (indicating someone interested in looking forwards in the industry), or were interested in learning it (we provided training), quality was better and waste was substantially less overall than I have seen elsewhere in a rapidly scaling team.

Despite what Microsoft may think, F# is the crown jewel of the .NET world, and it is a mistake to sideline it over fears such as this.

What's the problem asking experienced developer to learn F#? That is course assuming they do not refuse the work?

Team dynamics in large companies can be quite challenging. In addition, whoever made that decision might become responsible for project delays, inability to hire, people writing bad code, destroying work-life balance etc. And not just you, everyone up the chain will get blamed for choosing a programming language with a near-zero market share.

Generally large companies and enterprises are resistant to change, and my advice will be to just ask for enough room to get the project executed somewhat within budget and schedule.

At Olo, which is primarily a C# shop, people have been excited to learn F#, and able to pick it up on an as needed basis. We are pretty large and it has been fine. It helps quite a bit that it is a different language but part of the same ecosystem. It is quite a bit easier to manage than it would be adding say, Go, or Rust or something into the company, with entirely new tooling and libraries. for instance a visual studio solution can contain C# and F# projects, and they can refer to each other.

Your original point was about inability to recruit developers. That is why I asked. From my experience it was never a problem for seasoned developer to get a grip on new language barring few very exotic cases. I completely understand other factors in enterprise.

F# is a nightmare you want to use asp.net core.

In a previous role some time back used F# on top of ASP.NET Core. It isn't that bad and people thought the code was quite clean in the end; we had dev's thinking going back to C# even with F# using vanilla ASP.NET would be a downgrade. There's ways to mitigate the pain of the C# specific API. We went the vanilla ASP.NET Core route (for Swashbuckle) and found only the Startup class (which could be replaced by functions in hindsight) and the Controllers (which were still clean code wise) needed to be classes. The rest (majority) of the program was typical F# code with an interfaced object usually created via an F# object expression put into ASP.NET's dependency injection. Helped to separate the web controllers from the logic layer anyway and keep the ASP.NET code to a minimal. Most of the program was written in F# style with ASP.NET used just as a web server for functions basically.

There's just few public examples on how to do this cleanly so people kinda have to work it out themselves which I think could be improved.

What do you base that on? I have had no problem with F# and asp.net core. Just look at safe stack, it uses saturn or giraffe which in turn runs on asp.net. https://safe-stack.github.io/

That this abstractions exists on top asp.net core to make things more ergonomic proves my point.

No, it only proves that C# and F# are two different languages.

If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically.

https://code.visualstudio.com/docs/languages/csharp

Oh no, don’t do that.

The vscode integration is barely beyond autocomplete, and it uses more memory than rider does.

The c# story for vscode still has a long way to go before it’s even close to feature parity.

(...and yes, if you scrabble enough plugins you can get more features, but you get more crashes and even more memory slurping. :/)

What do you mean? The official C# support is from the Omnisharp plugin [1].

Omnisharp is the official .NET cross-platform development support system and is used across many different interfaces (VSCode, Atom, Sublime, etc). It's powered by Roslyn [2], the C# compiler platform, and can use the same packages for analyzers and autofixes that VS uses. It also has official debugging support. This is way beyond autocomplete.

1. https://github.com/OmniSharp/omnisharp-vscode

2. https://github.com/OmniSharp/omnisharp-roslyn

I don’t know what to say; except, yes, and the experience on atom, sublime and the other tools that use omnisharp is terrible.

It’s not unusable, but for example, I can’t refactor my code base without it crashing, and forget any advanced features like jump to symbol or extract class. The only feature that works reliably for me is autocomplete.

I can only speak for personal experience; omnisharp on Windows and Mac, on .net core (or heaven forbid you use something non standard like unity3d) ...

It’s just terrible.

Perhaps your combination of platform / project is a different story, but I try it again every few months, and bluntly, rider is just better at everything.

Visual studio on windows is also excellent, and the tooling is usually tighter (rider usually lags when new stuff like .net core 3 comes out, and the azure function integration is a bit spotty because it uses the core tools).

/shrug

Tldr; my experience, on multiple platforms on multiple projects has been simply negative every time I’ve used it.

Ymmv.

I can second that. Worked better on Xubuntu/VSCode than on Windows/VSCode even. Really smooth in fact, with intellisense/autocompletion and more just working. Then, I used it only on small CLI apps so far.

It's still nowhere near the same level of experience that Rider or VS offer.

Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time.

I can have VSCode installed and running with my personal settings on any OS within 2 minutes flat. I don't have to find a secret license key, login with any account, or pick through a list of 100 features in the installer. Then, once it's installed, well VSCode is just a better experience for the basic act of editing source code. Multiple cursors, quickly opening files by typing the name (without having to type a greater than sign followed by a space first every time like you do in VS), sane default keyboard shortcuts for managing/splitting documents and so on... Plus, it's got way better facilities for working with front-end web code than VS ever had and some other major features such as remote editing oh and one other little thing: it's fully cross-platform.

And that's the reason for VSCodes wild success. Let's hope Microsoft never fucks it up by trying to glom the rest of their Azure/Microsoft Account crap onto it too much.

Luckily, I don't have to work on anything that needs a designer anymore, like WinForms, but if I did I would certainly install VS. Even then - I think I'd only use VS for the designer and go back to VSCode for everything else. (And I love Windows and I used to love VS, having used both of them for 30 years and 15 years respectively.)

But the VSCode team also covered a lot of ground faster than VS ever did, adding feature after feature. So, what do you want for C#? I'm certain that we'll be getting it soon.

> Luckily, I don't have to work on anything that needs a designer anymore, like WinForms, but if I did I would certainly install VS. Even then - I think I'd only use VS for the designer and go back to VSCode for everything else. (And I love Windows and I used to love VS, having used both of them for 30 years and 15 years respectively.)

The WinForms designer is wonderful. I can throw up an ugly CRUD app that works so insanely fast with it. The web-equivalents are horrible. Everyone is trying to make a rich web app to write rich web apps and IMHO they are all targeting way too low on the "technical ability" scale for their users.

Though web is harder, since apps need to be responsive, and cross plat, and automating code gen of CSS that does that cannot be easy, and having a form designer UI expose settings for how a UI resizes itself doesn't sound like a UX challenge I'd want to tackle.

>Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time

I find it's the opposite. VSCode is just a very barebones editor with an ecosystem of plugins that may or may not be maintained. I always need to search through a list of hundreds of plugins to figure out which ones I need for this particular techstack.

I started using Rider this year and it's been much, much better than VS and VSCode for me. I can use it in both Windows and Linux. Search experience in Rider is my favorite part of the UX. I find VSCode clunky in comparison.

I use VSCode when doing Vue stuff. I like it for that. But I still miss the nice search UX of Rider. Maybe I need to dive deeper to see if there is a setting or another plugin that can get me that same feeling.

I've been using VSCode for C# daily for a year or two. I'm considering switching to a non-electron editor because of how slow and sluggish it is, including IntelliSense, refactoring, syntax highlighting and the latency and frame rate of actual rendering (huge drain on the battery if you have one). The editor doesn't (seem to) support language-integrated syntax highlighting, so no ambiguous language features get recognized and there's plenty of bugs (such as with around the C#7 ValueTuple syntax feature). The C# extension tends to freeze a couple of times a day. One feature that excels out of nowhere is the search functionality which greps entire folders almost instantly, probably because the functionality is delegated to a separate (native, I presume) process. JSON-with-schema-based configuration is something more software should have. The editor also starts pretty fast but most features are delegated to extensions which load (ultra)lazily and aren't usable for a few (5-30) seconds.

Just curious: are you on a Mac or Windows? I never experienced any freezing at all on Linux.

Windows, although my experience with VSCode on Ubuntu wasn't very smooth or stable either (worked with TypeScript for a few months a while ago).

I use VSCode with C# extension. THe only thing I missed was the additional analysis and quick fixes that full VS provides. However, that got sorted out by installing Roslynator in VS Code (works on linux too) and I couldn't be happier.

I keep coming back for a look every time there is a major release but it always seems quite cumbersome to me despite the fact I work in C# everyday. I ran through the Razor pages tutorial yesterday and I was surprised how heavy it all felt, I was expecting something like Flask or Sinatra.

I'm a big fan of IDEs, I couldn't imagine using C# without one.

I've been quite happy using Nancy for the past several years. At the time we made the switch, it wasn't possible to use WebApi or MVC in a self-hosted OWIN web server, and our application had lifecycle constraints that made trying to run it out of IIS impractical.

But I've come to really like the way Nancy has explicit API routes, compared to the implicit conventional style, or slapping attributes all over everything. You can avoid a lot of the magical action-at-a-distance middleware behavior that seems to be increasingly common as well.

> and adopting a functional style

Although this won't solve all of your problems, if you can't use F# and want to use a more functional style, then this will help [1].

disclaimer: I'm the author

https://github.com/louthy/language-ext

>Btw, Linux as a deployment platform works quite well.

What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?

We run Kestrel directly facing the internet serving http2 traffic across billions of requests per day with no issue. No need for Nginx.

Which Linux distro are you going with? Any recommendations for/against distributions.

We deploy our apps as containers on top of the standard dotnet images: https://hub.docker.com/_/microsoft-dotnet-core-aspnet/

The default uses debian but they have ubuntu and alpine variants too. We stick with the defaults and don't have any preference for distro.

I am using nginx as a reverse proxy to kestrel in production on one of my projects and it seems to be working great so far

Yeah I do the same, lets me do seamless deploys. I spin up the new version, change the nginx config, then tear down the old one.

This setup is also what Google Cloud is using for their App Engine.

Yes, this is what we use. So far it seems alright, and we did some load testing last week.

You can get most of the way to functions outside of a class with "using static". I often do "using static System.Math;" to have bare may functions. Also often do the same with System.Console.

I'm not sure what your thoughts are on Structural Typing, but I've found liberal use of extension methods on interfaces to be a really useful way to get lots of functionality on a wide variety of types.

As for your comment on namespaces, I cannot agree. Again extension methods would not be anywhere near as useful if one can't arbitrarily add code to any namespace, without needing to adhere to a file system structure.

Are you making interfaces for everything? Just register and use the class with constructor injection. All those layers of indirection just waste time.

What would change with functions outside of classes? You already have anonymous functions/lambdas, static classes and extension methods if it's about instantiation overhead, and local (nested) functions. Can you explain a scenario where this doesn't work for you?

For namespace declarations, you can just use the same namespace on all classes if you want to keep it simple, and that kind of flexibility isn't available if you use file structure.

It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.

Well do you really need to mock everything? And if so, how is that different than any other stack?

Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.

I once "inherited" a project where I counted more than thirty levels between the web pages and the send/receive on a queue to the system that actually did the work.

Funnily enough they had a huge team (and over 30 thousand classes) and a lot of time (over two years) but they couldn't finish it.

Edit: Should have said it was J2EE rather than .Net

I agree. I've spent the past 6-9 months cleaning up a .NET MVC project and one of the first things I did was to rip out all interfaces that weren't being used the way I expect interfaces to be used.

We have the base MVC project that references services for DI. We load in another DLL via Ninject to add customization on top of those services (custom parsing of some magnetic card swipes for different institutions we deploy to and such). I discovered that while all of our services (~20) had an interface, only one of them was being customized/overridden. This mean that in order to do something as simple as a parameter change, it had to be changed in way too many places: the definition, the implementation, and the usages.

Why have that extra layer? If we need to override in the future, we can add more interfaces. For now, I just want to maintain my sanity.

I am seeing it all the time when consulting for companies. Their developers just love taking relatively small things and turning it into multilayered monster with insane amount of dependencies for code, development building pipelines and deployment.

I see that too - but I also see plenty of completely un-testable code, because the controller constantly reads from AppSettings, or creates a new database connection directly, or similar issues.

For small applications, instead of going full on DI, I sometimes just make a few simple public static properties, that I initialize on program startup. Then you can initialize them differently in your test harness. This is a lot easier to understand if you're not an expert in the chosen DI framework or app framework.

I am designing financial software for the crypto industry and I definitely prefer the ability to 1) have a high test coverage, and 2) quickly be able to write regression tests. Without dependency injection with mockable objects, that would not be possible.

Probably not but it is in my opinion very nice to have the ability to mock evertyhing if and when you need it.

You always have the ability. It's just writing code. But you should only do it when you need to.

You can mock classes with virtual methods/properties.

I prefer making interfaces instead, though. I find it useful to make the boundaries between components explicit.

I'm pretty sure you could do this via reflection and virtual public methods. The same way entity framework creates its proxy classes.

Which strategy? If your dependencies are all interfaces, then they're all mockable.

I find the verbosity complain rather strange.

Then again, I rather use maintainable programming languages, instead of writing hieroglyphs.

I find structural typing is mostly necessary when someone messed up and used a class where an interface should have been used.

I'm now currently in the position of having to decide whether it's better to accept defeat or use T4 or similar to write the 1000+ line wrapper class to undo the mistake... You'd think Microsoft would at least remember to do dependency inversion through interfaces in their own C# code.

I wrote a tool, NimbleText which is free and good and lightweight for these one off 1000-line code generation scenarios. See https://nimbletext.com/live or email me for help (support at nimbletext)

> Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio.

I have had and continue to have the opposite experience of you. I use Ubuntu with VS Code and a few C# plugins that have greatly allowed me to navigate the .NET Core framework and write code with minimal references.

Even, with Visual Studio (unless you use R#), you will always run into issues where you aren't sure where the function or class lives. That's why you go read the documentation or ask SO.

The more you write webapi's the easier it is.

> Structural Typing

Dynamic was the closest to it, but it has significant performance issues. Tuples and structs do exist also.

> Allow functions outside of classes

No.

> Verbosity in C#

????

> most popular libraries will nudge you strongly to use Dependency Injection throughout the app and implement everything as a class and to extract interfaces out of it.

You do realize C# is mostly a strong Object Oriented language hence why they (the libraries) urge you to do that.

If you want functional so much use F#.

I don't believe you will ever get functions outside of classes in C#. It is antithetical to the entire ethos of the environment.

Thank god we won't. Functions outside classes never did make sense to me. People love to hate classes sometimes. For me, everything starts at classes and structs;

in C# you can make a static class, and then put functions in it. When you do this, the class is nothing more than a namespace. But the class is already in a namespace. So you now have a redundant namespace. It isn't a big deal but its a bit silly to have to do that, when writing static functions.

Yeah I agree. I really like static classes, but I've seen them being overused; As long as it doesn't causes performance problems I'm good with it. In fact calling static methods is faster;

you can just make a public static class FUNCTIONS and then use a static use at the top of each file, then pretend.

> Allow functions outside of classes

Mads Torgersen did a proposal related to this, it's in the C# Version Planing as version X.X, so maybe in the future we're going to have those capabilities.

https://github.com/dotnet/csharplang/issues/2765

> - Allow functions outside of classes

use a delegate for this:)

Btw, for dev on Mac I use Jetbrains Rider, its like VS with Resharper or even better. Its also available on Linux. Otherwise, for smaller (micro)services, VS Code works fine. As soon as you start fighting with Code, maybe your solution is too big?

can't you just put static functions inside of a static class and use them with "using static StaticClassName"?

- Allow functions outside of classes

What do you mean? Isn't that just anonymous functions?

He wants top level functions. He wants to not have to write classes if he thinks the domain doesn't need modelling as objects.

You can have static classes that can contain nothing but static members - so effectively a namespace with no instantiation of that class allowed so no objects.

I know, but many people dislike boilerplate code.

You can use a static class though. It's 1 class that then just behaves like a namespace and doesn't need any object modeling.

You could create an F# class library, put your functions in there, and then call them from C#?

They probably wants to not have to write classes if he thinks the domain doesn't need modelling as classes.

Objects are just initialized memory with a vtable, or actors that sends and receives messages...

Reply on news.ycombinator.com