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...
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".
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.
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.
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
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#.
That's what the Powershell integration is for.
And projects such as scriptcs and cake
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.
Not to mention how crazy it sounds having 32GB for an IDE.
Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.
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 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).
Add Docker, VM, development database server etc. to the bill, and a 32 GB machine is pretty reasonable for a dev.
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.
[1] Other paid-for Jetbrains products such as IntelliJ Ultimate have the same integration
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.
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...
https://laurentkempe.com/2019/09/03/WPF-and-dotnet-Generic-H...
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...
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.
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.
It would certainly be cleaner without having to define a useless class.
F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.
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.
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.
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.
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. :/)
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.
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 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.
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.
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'm a big fan of IDEs, I couldn't imagine using C# without one.
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.
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
What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?
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'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.
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.
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.
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
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.
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 prefer making interfaces instead, though. I find it useful to make the boundaries between components explicit.
Then again, I rather use maintainable programming languages, instead of writing hieroglyphs.
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 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#.
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.
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?
What do you mean? Isn't that just anonymous functions?
Objects are just initialized memory with a vtable, or actors that sends and receives messages...
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.