Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Core 3.0

devblogs.microsoft.com

Post reply on HN
Print view View original

151–160 of 183 posts

Re: .NET Core 3.0

#151

Post by akra »

roebk wrote: post #54
Parazitull wrote: post #48

Earlier quoted context omitted.

If you're interested in .net and the clr, you could replace c# with f#. It's the most practical functional language that I've tried. Great for domain modeling and it can used in C# projects. I also think that c# is too verbose so what I normally do: asp.net core mvc for routing, templating, authentication / authorization, data access etc and then reference an f# project that contains the domain logic. The best of bot…

As a complete newbie to .net, I’ve tinkered around with f# for a web app and quickly got frustrated. I like the sound of your approach. Do you have any links / resources for the best way to get started with your approach?

If your writing a web app I've heard good things about Giraffe (https://github.com/giraffe-fsharp/Giraffe). It seems to even have a project template via the "dotnet" command to get a quick web app running. With F# I personally find Rider or VsCode better IDE's than VS as well. The workflow in F# is more like my experience with scripting languages than something heavy like Java/C#; you don't lose much by going to a more lightweight IDE and a lot can be done via CLI commands and text editing in .NET Core.

Re: .NET Core 3.0

#152

Post by ygra »

mrighele wrote: post #59
krat0sprakhar wrote: post #3

> Nullable enables you to directly target the flaws in code that lead to NullReferenceException. The lowest layer of the framework libraries has been annotated, so that you know when to expect null. I hope Java gets this one day.. would be a cool feature

You can try checkerframework [1], which uses annotations to perform extra typechecking at compile time, including nullable/not-nullable checks. Works properly altough it has a few issues: the biggest is that support is still stuck at java 8, and the framework is sometimes not smart enough to see that you already checked if a nullable field is null or not and you can safely use it. [1] https://checkerframework.org/

Annotations don't work for local variables, though. So you only get nullability checking around calling methods and accessing fields, right?

Re: .NET Core 3.0

#153

Post by keithnz »

jsingleton wrote: post #98
avgDev wrote: post #23

I have been developing in .Net MVC 5 and now the last 6 months in .Net Core 2.1. Core is pretty awesome, I would say the learning curve is pretty high, but I'm very satisfied. Previously, I used Java in school. The .Net stack offers a lot of jobs in enterprise companies, if you are someone that dislikes SV mindset. Also, Visual Studio is an insane IDE. Although, I recently did have some nasty bugs but updates are com…

It's usually a good idea to wait for the patch release before updating. This applies to most software, including VS, VSC and .NET Core. Being an early adopter sucks unless you're just testing it out. If it's your job then wait for it to stabilise and for the real-world bug fixes. The next Long Term Support version of .NET Core will be 3.1. It should be out in November.

Microsoft have been running things like Bing on it for a while

Re: .NET Core 3.0

#154

Post by keithnz »

mieseratte wrote: post #145
tabtab wrote: post #76

Earlier quoted context omitted.

Re: I would say the learning curve is pretty high If you had to rank and list the top rough spots in the transition, what would they be? Entity-Framework changes are often cited, but what else is different enough?

Having just come into a .NET shop in the last couple months, having spent much time with Spring / Java the documentation and clarity of what to use is troublesome. I really expected Microsoft to have great documentation, but sadly I’ve not found it great. So far I’ve done some WCF SOAP work, and an ASP.NET MVC 5 application. Figuring out what the latest frameworks and tools is a bit of legwork. Things aren’t always c…

its very simple to get .net core DI working, shouldn't be much code other than registering your types / service.

await new HostBuilder().ConfigureServices((context, services) => { // services.AddTransient.... }).UseConsoleLifetime().Build.RunAsync()

Re: .NET Core 3.0

#155

Post by keithnz »

gargarplex wrote: post #149
avgDev wrote: post #23

I have been developing in .Net MVC 5 and now the last 6 months in .Net Core 2.1. Core is pretty awesome, I would say the learning curve is pretty high, but I'm very satisfied. Previously, I used Java in school. The .Net stack offers a lot of jobs in enterprise companies, if you are someone that dislikes SV mindset. Also, Visual Studio is an insane IDE. Although, I recently did have some nasty bugs but updates are com…

As a recruiter, I have to say that .Net is still used by startups, especially in Europe and cities like Manhattan with a large European population. I am shamefully plugging the fact that I am recruiting for said roles :-)

Here in NZ its very popular as well.

Re: .NET Core 3.0

#156

Post by FlorianRappl »

ygra wrote: post #134
FlorianRappl wrote: post #108

Earlier quoted context omitted.

That's not the root of the problem. Personally, I wish MSBuild would be more powerful and would allow mixed compilation where some files are in C#, some in F# (or VB.NET or some other language targeting the CLR). Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent y…

This isn't really due to MSBuild, as the C# compiler has that limitation already. MSBuild just calls it. Basically a single assembly has to be written in the same language. You could probably get something similar with multiple assemblies and ILMerge.

I don't expect the C# compiler to understand F#, but in my opinion there should be language independent ways to create CLR assemblies. MSBuild (which calls the right compiler for each project) could also understand (and did iirc) compiler-independent project types that still produce assemblies, however, from mixed sources. Now the C# compiler would only be called for the C# sources.

> Basically a single assembly has to be written in the same language.

This is like saying a single js file has to come from only js files, still bundlers today merge all kinds of types in there - in a single sweep.

I am not writing this since I think mixing C#/F# is the future (well, it would be cool), but because it could allow the C# ecosystem to improve. Right now the best thing we have for metaprogramming in C# is Fody; and I personally think we could do better.

Hopefully this expressed my idea a little bit better.

Re: .NET Core 3.0

#157

Post by ygra »

FlorianRappl wrote: post #156
ygra wrote: post #134

Earlier quoted context omitted.

This isn't really due to MSBuild, as the C# compiler has that limitation already. MSBuild just calls it. Basically a single assembly has to be written in the same language. You could probably get something similar with multiple assemblies and ILMerge.

I don't expect the C# compiler to understand F#, but in my opinion there should be language independent ways to create CLR assemblies. MSBuild (which calls the right compiler for each project) could also understand (and did iirc) compiler-independent project types that still produce assemblies, however, from mixed sources. Now the C# compiler would only be called for the C# sources. > Basically a single assembly has…

The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit. You'd have to change that to some semblance of "object files" instead along with a "linker" step afterwards to allow for an assembly to be made up of different languages. Again, this is how the compilers work currently, so MSBuild (well, the default targets) just go along with this. This has nothing to do with MSBuild, which basically just tracks items, properties, targets, and tasks. It doesn't care about the semantics of all that.

Or, you know, use ILMerge, which is pretty much the equivalent of the JS bundlers you mention. With some custom MSBuild targets you should be able to create a project file that contains C# and F# files, both of them compile to intermediate assemblies (although you can't have circular dependencies between both), and a step afterwards merges the assemblies into the actual one.

Re: .NET Core 3.0

#158

Post by mrighele »

ygra wrote: post #152
mrighele wrote: post #59

Earlier quoted context omitted.

You can try checkerframework [1], which uses annotations to perform extra typechecking at compile time, including nullable/not-nullable checks. Works properly altough it has a few issues: the biggest is that support is still stuck at java 8, and the framework is sometimes not smart enough to see that you already checked if a nullable field is null or not and you can safely use it. [1] https://checkerframework.org/

Annotations don't work for local variables, though. So you only get nullability checking around calling methods and accessing fields, right?

Annotations in general do work for local variables, although this is specified on a per-annotation basis.

If I remember correctly, for example, the @NotNull annotation in javax.validation.constraints cannot be used for a local variable, but the one provided by the checkerframework can.

Re: .NET Core 3.0

#159

Post by EnderMB »

untog wrote: post #126
atonse wrote: post #5

Earlier quoted context omitted.

I’ve thought about this but I doubt it. The big change has been the perception shift. .NET was always really solid tech. Microsoft has always had stellar developer technology. But the love affair with open source and the super villain role that Microsoft played, is what kept people away, not the tech itself. I remember wanting to give a talk about how amazing C# was to a ruby group. I never did it, but it was definit…

The ecosystem is what drove me away from C# (as well as not wanting to do enterprise work). I started dabbling with Ruby and Node and the sheer number of free third party libraries blew my mind. C# simply didn't compare.

This is a very weird criticism. I'm a Ruby dev, but I spent eight years working with C#, and I can't remember any times where a Ruby gem was more readily available than a NuGet package.

If anything, I'd say there's less choice in the Ruby world, especially in the data science and ML fields.

Re: .NET Core 3.0

#160

Post by truth_seeker »

If you dont know already:

Azure has started investing heavily in offloading the task from CPU to GPU and FPGA. There are really good framework on .NET to achieve the same.

NVIDIA CUDA GPU - https://devblogs.nvidia.com/hybridizer-csharp/

GPU scripting and CUDA - http://www.aleagpu.com/release/3_0_4/doc/

FPGA - https://hastlayer.com/project, https://netfpga.org/site/#/

Post reply on HN