Hacker News Reader

Comment by manojlds | Hacker News Reader

Interesting, in the context of Xamarin acquisition by Microsoft. Swift can very well spoil C#'s steam.

People focus far too much on different languages. The fact that Android and iOS have very different UI libraries is usually a much bigger problem.

Xamarin's big selling point is a cross platform ui library.

Lowest common denominator. Terrible for UX for everything but the most basic UI designs, sorry.

Each platform requires UI work to make it really fit the platform in question.

True, but Microsoft is such an enterprise company that it fits their customer base really well (e.g. "I don't care if it's pretty, I just need an inexpensive-to-build app for my 3,000 workers that runs on either platform").

I get that. But I also think that companies are slowly understanding that UI and UX matters. Even in the enterprise sector.

I think most people don't understand Xamarin. Up until pretty recently Xamarin had no cross platform UI components. That is although all logic was shared, views had to be written separately for the different platforms - just like React Native.

With Xamarin Forms this has changed - you can add a Xamarin Form component and this will work adapt itself across the different platforms. The key word there is adapt - it is not like an HTML page, a Xamarin form input will look different on Android and iOS by default.

So I think your point, while valid, does not apply in any way to Xamarin!

> So I think your point, while valid, does not apply in any way to Xamarin!

I'm afraid GPs point is still valid - UX (the experience) is more than just native/native-looking widgets, but how the app conforms to platform conventions. For example, iOS apps typically include(d?) a back button at the top left corner; even if the button is rendered faithfully as an Android widget - that app will feel alien on Android (it was also an easy way to spot lazy iOS 'ports'). I think edge-swipes are another iOS convention for navigating back/forward, which would be foreign on Android, so I fully agree with GPs statement: Each platform requires UI work to make it really fit the platform in question

That was his point though. You build the UI in Xamarin.Forms and on the iPhone there is a back button in the top left corner, on Android there isn't. Automatically rearranging and conforming to the platform guidelines.

Yes, the most noticeable differences are implemented. But this is very a superficial look. From the developer's page:

https://xamarin.com/forms

Xamarin.Forms is best for: • Apps that require little platform-specific functionality

Xamarin.iOS & Xamarin.Android are best for: • Apps with interactions that require native behavior

So I think your point, while valid, does not apply in any way to Xamarin!

I'll believe it when I see it. Cross-platform UI libraries like Qt, Gtk, SWT, etc, just never end up choosing quite the right widgets or having exactly the right look-and-feel as natively-designed apps.

If cross-platform is a bigger requirement than producing the best-possible UX, then perhaps Xamarin could deliver. I see this being a big deal with enterprise software. But that's almost never the case for most consumer-facing software; you're always much, much better off building your presentation code in a native UI toolkit.

but i would say for writing business apps, this isnt really an issue

most business users would accept that their apps, look slighly ... unlike common apps on the platform

Which users? Admins don't care about UX, they care about ticking checkboxes to appease management. End users are people like you and me, they want quality from their software. They may be forced to work with less then stellar software, but that does not mean they accept it.

I would say that React Native is the biggest threat there.

Doesn't perform well enough outside of high-end devices.

Do you have anything to back that up?

Run some lists with images on them on iPhone 5. Anecdotal, and I am sure you can dig into metal to improve performance, but out of the box, it's kinda poor. I still like React and I'm hopeful React-Native will improve.

Thanks. I wonder how much of that is due to the fact that JavaScriptCore can't use JIT compilation when running in an iOS application other than Safari.

As of iOS 8 that's no longer the case. JSC JIT compilation can be used in native apps. (It's also used by WKWebView.)

http://trac.webkit.org/wiki/JavaScriptCore

"JavaScriptCore is an optimizing virtual machine. JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter (LLInt), baseline JIT, a low-latency optimizing JIT (DFG), and a high-throughput optimizing JIT (FTL)."

Apps can use JavaScriptCore, and JavaScriptCore can use JIT, but these can't happen together, because third-party apps aren't permitted to execute writeable memory.

http://stackoverflow.com/questions/22281265/is-javascriptcor...

This is good to know. Looks like the only way to make use of JIT (by someone who isn't Apple) is to use a WKWebView to execute the JS.

This has been false for years.

I haven't used React Native, but I've done quite a bit with native bridging with JavaScriptCore and v8. If your performance bottlenecks are crossing the Javascript-to-native boundary, JIT can't help you. And crossing the bridge boundary isn't the cheapest operation.

That isn't an issue with React Native, which runs JS on its own thread and implements an asynchronous, batched bridge between JS and native.

As long as React Native requires the developer to use Javascript to write his code this is a no go for the sane of us.

Swift isn't a significant improvement over C#. Also, keep in mind that C# benefits from the whole Microsoft ecosystem, which includes Visual Studio.

Beyond the language, what's even more important is the application model. That's where frameworks like React Native have the edge. This might change if Microsoft upgrades Xamarin.Forms into full-blown Universal Windows App support (think WPF on iOS and Android).

You might just be looking at the language from a syntax perspective. However the two are very different in the way that you compile and run them. In C# the code is translated into a custom bytecode (IR) and then the CLR is used to execute that and manage the memory through GC.

In Swift's case it compiles down to native processor code instructions and can have optimisations applied ahead of time. This allows the app to run faster than a VM+JIT would do and therefore longer batter management. The overhead of the runtime is a lot lower since memory is ref counted and doesn't need to run GC periodically.

C# has always had support to AOT to native code since the early days via ngen. The only issue was that more effort was spent in the JIT compiler and ngen requires dynamic linking.

C# is compiled to native code on Windows Phone since version 8.

The C# extensions for Singularity (Sing#) and Midori (System C#) generate static binaries. Work which served as starting point to MDIL on WP 8.x and .NET Native.

The new .NET Native compiler even exposes SIMD.

Mono also supports AOT compilation since a long time.

As always language != implementation.

You are correct but part of the work being done to get .NET native working is the aot compilation. https://blog.rendle.io/what-ive-learned-about-dotnet-native/

.Net Core can compile AOT as well, and Xamarin already does that on iOS with its Mono runtime too.

ART also compiles down to native code. As for performance comparisons - last time I checked the benchmarks for Java were still faster than Swift.

> C# benefits from the whole Microsoft ecosystem, which includes Visual Studio.

Both good and bad. Visual Studio isn't cross-platform, for example.

Well, Visual Studio Code[1] is, so it may be coming in the future.

1: https://www.visualstudio.com/en-us/products/code-vs.aspx

They're entirely different products, Code is built from the ground up. So I'm not sure it makes a cross-platform Visual Studio more likely.

I would say the fact MS is shipping products on Linux, considering their historical stance, makes it more likely, but your sentiment is probably correct in that it may not mean it is likely. Ten years ago I would have laughed at the idea. Today, I have to think quite a bit more about whether it's likely.

I would not use the existence of an editor built on web technologies as opening the possibility that something as entrenched in Windows as Visual Studio would be leaping to cross platform.

How much RAM does a single hello world take in C#?

How much time does it take to create a thread in mono on my Linux VM?

How much does it cost a license for Visual Studio?

> How much does it cost a license for Visual Studio?

Free if your revenue is under $1m, then $40/month including CI, source hosting and issue tracker.

it's worth also asking:

How much does licensing a set of Windows keys run?

How does the .NET GC impact me versus Swift's ARC?

How much RAM does Visual Studio eat up after you've been coding for a while?

How slow, unresponsive or buggy is it these days?

of course there's "ecosystem creep"... If I'm going C# on mobile, I'll naturally be influenced to consider C# on the server... how much do Windows servers cost? and since they're a "first class citizen" on windows, what about SQL Server?

This was my thought. What is Microsoft's answer to Swift?

React Native is not even on the horizon.

What do you mean?

I would expect this just to be basic Swift support including -perhaps- the Foundation library (String, Array and other "low level" functionality). I don't think this Swift port has currently any easy way to create apps with a graphical user interface using some sort of Java bridge. So compared to Xamarin, using Swift for Android apps would be pretty limited.

But please correct me if I'm wrong.

Swift String, Array, etc. are not part of Foundation, they are part of the swift runtime library. They have mechanisms for converting to and from NSArray/NSString representations, though (and because of that, their internal structure is quite similar). But that mechanism is disabled in Linux (and obviously I assume Android).

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib.

NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considered essential but aren't part of Swift's stdlib.

The bridging is actually in the swift libraries. Much of it in C++, not in swift, but still. https://github.com/apple/swift/blob/master/stdlib/public/cor... is where the magic starts (and mostly refers to where the actual work is done).

AFAIK Foundation does not have any special handling for swift at all. Swift is just taking advantage of the fact that the people working on it can act with authority on the memory layout of Objective-C Foundation objects.

Also the OSS Foundation is... not quite the same thing as what apple ships on their platforms.

That's where Objective C bridging happens. That's irrelevant on Linux or Android, since there's no Obj-C runtime.

OSS Foundation (which is composed of pure Swift code, plus the plain C CoreFoundation which is also open) implements bridging between Swift types and Foundation types itself-- see (for example) the Array extension for bridging to NSArray at [1]. That code's what will (again, eventually) ship on Linux and presumably on Android, because it provides compatibility support for Swift libraries originally targeted to Apple platforms and fills out certain core functionality that's not part of Swift's stdlib (networking being a big one). This work is still ongoing and, if one were to try to actually use it right now, you'd run into lots of bits that aren't implemented yet.

[1] https://github.com/apple/swift-corelibs-foundation/blob/mast...

That is true. I recognize that to some extent I was talking past you, but I really just wanted to clarify where the responsibility lies when there is an objc runtime.

Whats with all the NS prefixes? Stands for NextStep?

Yes. It's a poor-man's implementation of namespaces, since Objective C doesn't have them and they didn't want to pollute the global namespace with their core classes.

C# devs like myself are interested in Xamarin are interested because they don't have too learn new language / tooling to do mobile dev. Learning Swift isn't any more appealing than learning Objective C.

I care about syntax so Swift is far more appealing to me. Compare print("Hello, world!") in Swift to Hello World in Objective-C, which the article jokingly calls "gibberish."

https://www.binpress.com/tutorial/objectivec-lesson-1-hello-...

Why? Microsoft will likely offer Swift support in the UWA platform soon, they already support Objective C. I suspect they will announce Swift is now supported under project Islandwood at Build.

My comment was on C#, and not Microsoft.

Far from likely. For those fed up with Java, Android has Kotlin already.

It would be great if Swift could target .Net Core.

I did a little googling because you sparked my curiosity and it's happening. “Silver” brings Apple's Swift language to .NET and I found at least one mention of Silver and .NET Core.

Just my thought.

F# is already spoiling Swift's feathers. And F# has first class support in Xamarin.

Reply on news.ycombinator.com