[5stospace]

I still don't understand why they would choose Swift over C#?

They complain about C#/Java having "highly dynamic constructs" but correct me if I'm wrong but isn't swift also a GC/OOP like Java and C#?

I don't think Swift has any inherent objective advantages over c#.

I think it would have been a better decision to go with C# over Swift as Microsoft has a clear roadmap with the language and it is already supported on linux/mac/windows.

[FridgeSeal]

I would rather claw my eyes out than write any ML stuff in C#.

It's a fine enterprise language, but good lord writing data science and machine learning stuff in it would be an right pain. It's also not super high performance, and when you're doing a lot of maths heavy operations, high performance is absolutely crucial. I had great difficulty establishing whether SIMD/vectorisation was even supported, and then even more difficulty getting it to work.

Julia would have been a far, far superior choice than Swift.

[bonesss]

For data science and anything with a demanding domain model I find F# streets ahead of C#.

For a project like this, though, the type F# providers are a bit of a game changer that opens a lot of roads to create a 'best of both worlds' experience. For example, offloading heavy maths to other runtimes while providing a mature stack for everything outside of ML. The F# Type Provider for R (http://bluemountaincapital.github.io/FSharpRProvider/), is an example of this hybrid approach.

I believe Julia looks to be the better choice over Swift, tho.

[pjmlp]

SIMD is supported already for quite some time on RyuJIT. Quite easy to find out when searching the MSDN .NET Blog.

Its performance is good enough for doing medical digital imagining as presented by Siemens at FOSDEM 2019.

It is a matter to properly use the features that the language gives us.

[FridgeSeal]

Yeah I found the blog posts, but then had the problem of “what compiler am I using now?” Was it the Roslyn one or RyuJIT? Does RyuJIT support .NetCore or is it in Standard or Framework or one of other seemingly limitless versions of .Net that exists for some reason.

Apparently I could use a library called Vectors, buried deep inside some numerical library, but then the runtime wouldn’t recognise the libraries existence despite being a dependency and installed (and linked and every other thing you have to do to get .Net to do anything). After I fixed that issue it wouldn’t let me construct any arrays or anything.

Suffice to say, on top of C#/F# being painful to deal with at the best of times, attempting to do anything numerical was an absolute shit fight. I’m sure if you’ve got a whole team, you can make anything work, but for me it was not at all worth the effort.

When you consider I can get fully guaranteed (not just hoping the compiler chooses to optimise it right) in Julia practically for free along with nicer syntax, 100% less namespacing hell, equal or greater performance, and far more data science and numerical packages and it’s hard to see what the draws of C# would be.

[pjmlp]

It appears to me that the issue was not being confortable with the .NET eco-system.

Roslyn and RyuJIT aren't the same thing. Roslyn is the new compiler infrastructure for MSIL generation, where the original C++ compiler got replaced by bootstraped VB.NET and C# compilers.

RyuJIT is the new JIT compiler introduced in .NET 4.6, replacing the former JIT64.

I don't disagree that Julia is better suited for data science given the eco-system, as proven by my other posts in this thread, just that the performace is also there when one wants it.

[barbecue_sauce]

While I do think the choice of Swift is kind of weird, you are wrong about Swift being garbage collected (it uses Automatic Reference Counting). It also compiles to actual machine code (rather than an intermediate representation for use in a VM).

[pjmlp]

Reference counting is a garbage collection algorithm as per CS literature, you are mixing it up with tracing garbage collection algorithms.

Swift makes use of SIL and LLVM bitcode before the final binary is produced.

Likewise C# can be AOT compiled to actual machine code via NGEN, .NET Native, CoreRT and Mono/Xamarin.