[ifthenelseend]

Now you can easily write the following state machine in C#:

    static State ChangeState(State current, Transition transition, bool hasKey) =>

    (current, transition) switch

    {

        (Opened, Close)              => Closed,

        (Closed, Open)               => Opened,

        (Closed, Lock)   when hasKey => Locked,

        (Locked, Unlock) when hasKey => Closed,

        _ => throw new InvalidOperationException($"Invalid transition")

    };

[ComputerGuru]

To be clear, this has nothing to do with .NET Core 3.0 but rather is a feature of C# 8.0, which depends on compiler support that can be targeted to any previous version of .NET Core or Framework, all the way back to Framework 2.0 (tested myself, although MS says not to target 2.0 or 3.5).

[legulere]

C# 8 needs .net core 3.0 for some features to work at all like default interface method implementations, and for some to work meaningfully like nullable reference types.

[platz]

Still no exhaustiveness checking like a true match expression unfortunately, which is what would give it parity against the traditional subclass/polymorphic approach.

[alkonaut]

Heard it’s being championed for C# 9.

[smush]

It's so amazing to me how many features from F# or other functional programming languages make their way to C#, and the devs who were otherwise never gonna try those features use them because they are 'normalized'.

I do wish people would give the language that has (relative to this ^ trend) 'already arrived' a chance.

[FlorianRappl]

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 years). A mixed model would also open other scenarios.

The mixed compilation is something that current web tech (using bundlers) has in advance. I can do crazy things and end up with the best (optimized) output using a common denominator.

On the F# track I fully agree - its a wonderful language that more people should try out.

[ygra]

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.

[FlorianRappl]

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.

[jen20]

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

This is actually untrue - though the tooling does not make it easy.

If the output type of a 'project' is set to `module` instead of `assembly`, it can be added as a module reference to another project which builds an assembly.

The downside used to be that completion in the IDE didn't work, but as far as I'm aware there's no real reason why multi-module assemblies couldn't easily be exposed by tooling if it was considered important enough.

[platz]

well there is some mixing at the solution level. You could have an F# project containing your domain model, and a C# project in the same solution just fine - but it would be nice to mix in the same project.

[james_s_tayler]

I thought you could actually do that already?

I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...

[jen20]

The 'normal' approach to this is two different assemblies. There is, however, support in the CLR (I assume it still exists) for assemblies built from different languages - it's just not well exposed by tools.

[platz]

As explained in today's https://news.ycombinator.com/item?id=21049374

> While early adopters may accept some problems on the way (like immature tooling), the majority expects a definite productivity improvement without disrupting the way they work (evolution instead of revolution).

Tooling in F# was/is bad for ages, and also lags in other areas. You have to put up with some disruption to your normal workflow to really embrace it.

[nikofeyn]

i actually just did this in f# using the MailboxProcessor. it's beautiful. although, f# has had this since the beginning and is much cleaner being able to define the states and transitions using discriminated unions and having exhaustive pattern matching.