Xamarin now free (and supposedly open source)

Have you published anything to iOS lately? Please, try doing exactly what you just said. Don't just build. Actually publish something, to the storefront.

From memory, Unity's Mono runtime on iOS is 32bit only (or there was some other restriction to that effect). About a year or two ago Apple changed their policy such that only 64bit apps could be published to their store. (So you can still build whatever you want on your end and the hardware is still capable of running it, they just won't necessarily let you put it on their store.) That's why Unity jumped to IL2CPP on that platform far earlier than they'd intended - it was the fastest way to get 64bit build capability to the people making iOS apps in Unity.

In that case, IL2CPP was absolutely a "need".

Edit: This situation as a whole is far more complicated than you seem to give it credit for, and a lot of your proposed solutions simply aren't valid as a result.

 

Yeah, I meant to say converting IL then running it natively; I almost edited it but you jumped on it too quickly. My point is that converting .NET code into something that eventually runs on a native machine is basically the entire point of .NET and Mono (or any language really). And it would be better to use existing tools that do this (Mono) than make a new one.

Some of the platforms did have Mono support but only for newer versions of Mono, which they didn't want to use.

The main reason I don't think it's reasonable is time. If they said IL2CPP was just about finished and so it would only push back the .NET update a few months, then that would be fine. They could release it, and if it sucks, they could switch over to new Mono. If they're pushing the .NET update back a few years just finish IL2CPP, then not much is going to convince me that it's reasonable.

 

I think it's the opposite. You're coming up with complications with solutions that happen to coincide with IL2CPP being worked on. If Apple says only 64-bit apps can be published, then the obvious thing to do is to use 64-bit Mono. It is not to say "Hey let's write a tool that converts IL into C++". They couldn't use 64-bit Mono because they didn't want to buy the new license. I mean, almost any complication that can be thought of in regards to getting .NET code to run on a new and popular platform has already been thought about and solved by Microsoft and Xamarin. One might say that Xamarin's sole purpose is to solve the complications of getting .NET code to run on new and popular platforms.

 

So what? "Some" isn't good enough.

 

That's not what you said a few posts ago, where you seemed to be accepting that 64bit Mono wasn't available to them at the time:

How could they have responded better based on the information available at the time?

I am indeed "coming up with complications", the thing is that they're all genuine and valid ones. You can blame the messenger all you want, reality won't change.

Your solutions all sound great on the surface but, like I said, this situation is far more complicated than you seem give it credit for. A simple sounding solution now isn't necessarily the best course for the long run, since Unity have to look after not just one platform but two dozen, and not just solve today's problems but also provide a platform for tomorrow's. Unity quite understandably wants to keep things as uniform as possible between their platforms, which is beneficial not just for them but also for us. (I hear that having one different .NET backend for one platform was already quite painful, imagine potentially maintaining one for each platform as is the logical conclusion of your suggested approach!) On top of that, others have given plenty of reasons that IL2CPP can be beneficial, and nobody is claiming that it's all roses and unicorns.

It's easy to pick on things if you look at only a part of the picture.

 

I have one potentially, but I need to retest it to see if it's been fixed. At one point, IL2CPP was failing to compile DLLs that were generated using Roslyn (VS2015). I had to compile assemblies for IL2CPP platforms for my asset in VS2013 and the others in VS2015 otherwise it would fail.

 

I'll have to double check... It's been awhile, but I think someone said they'd look into it when I asked about it so I don't recall if I even created a bug (or perhaps one of my customers did).

 

This means .Net is still better about builde time and build size than IL2CPP ?

 

This makes me feel a little better. Like I said earlier, my main problem is that IL2CPP seems to be holding back any other work on upgrading .NET. But if it's really almost ready for prime time and we'll be getting .NET 4.5 some time soonish and a working Mono runtime in the editor and desktop then I will be a happy camper.

I love Unity, but I'm simultaneously working on a Unity game and a large .NET 4.5 project and switching back and forth all the time really makes the missing features stand out and poke me in the brain. I'll try to temper my grumpiness.

 

Yeah badgering unity staff, I take a dim view of and would probably put a stop to it if it went over the line. It's great to enquire, not great to harass, sometimes you bring it pretty close to the wire when you don't need to

 

YOUR FACE IS CLOSE TO THE WIRE... oops, I mean, uh... Well said, point taken.

 

I remember this feeling moving between Java and a certain game engine I used to use with its own scripting/programming language. From there I moved to a system where work was all directly in C++. From there I moved to Unity. (A few side steps in between, but that's close enough.)

My view of Unity's scripting environment is of course influenced heavily by that background. I've never considered myself a ".NET programmer", though in my last job that's certainly what I was considered. The rest of the programming team were somewhat surprised when I explained that as far as I was concerned the system available in Unity was a kick-ass game scripting system, rather than a gimped version of .NET. Comparing it to my prior experience, it offered very nearly the iterative speed and engine integration of a custom scripting language at the same time as offering very nearly the power of working directly in C++ and a (relatively) complete standard library. So I've never really cared about having the latest and greatest .NET features (though I don't deny they're cool) because to me it's just never been about .NET. Mono just happened to be a good functional match for Unity's needs.

 

Xamarin changed their payment model? Is that why they've been spamming the crap out of my inbox?

 

http://www.mono-project.com/news/2016/03/31/mono-relicensed-mit/
http://www.lifehacker.com.au/2016/04/xamarin-goes-free-mono-is-now-mit-licensed-is-this-real-life/

 

Yup. Well, good luck with that. Rube Goldberg machines are by definition slower than doing the action (like flipping the switch) directly.

 

Oh, interesting. Could be worth looking into. I heard they have a nice mobile gui framework.

 

I don't think i'm ever going to be able to look at that work with a straight face ever again..

 

Brace yourselves, .NET for the web is coming...
https://mobile.twitter.com/migueldeicaza/status/715940651745980416?s=09

Can we ditch IL2CPP now ? Pretty please ?

 

It would be pretty stupid to ditch it now after they're practically at the finish line.

 

I'd like to see you drawing pictures at 60hz, then.

 

I've meant whole compilation path is one giant Rube Goldberg machine. And that's why it is so slow to build. They'd have better luck if they'd built direct C# to ASM (IL2ASM?) compiler, then use asm.js to play that.

 

Or IL to WebAssembly (IL2WASM)...

 

I know what you're saying. I'm saying it doesn't make sense.

 

It makes sense to me. C# -> Mono compiler -> IL, will, unless time travel is involved, always be faster than C# -> Mono compiler -> IL -> IL2CPP -> C++. They can make the second compiler faster but it will never be faster than not doing a second compile at all.

 

Though you could convert IL to asm.js without the C++ step and not lose any portability. There's MSIL and LLILC and as someone posted above, MS/Xamarin are working on an asm.js runtime, though that probably won't be ready for quite some time.

 

Well if you want to go hardcore silly: "i love to see pee pee". Inline To C++ is simpler tho

 

IL is for "intermediate language", not inline. And ain't nobody got time to type "intermediate language" on the internet.

 

Yeah brain fart.

 

I prefer the first one..

 

Thank you. Thank you so much.

 

Yes, but that's not actually what the post I was responding to was saying. The system was being compared to a Rube Goldberg machine specifically in order to discredit it, where some other systems that can be described similarly are actually the fastest known way to do their tasks.

And that last bit is key - "do their tasks". The new system does not do the same task that the old one it's being compared to does. In some cases it's similar, but on the whole it is not the same.

 

I don't think this is being entirely fair. Mono outside of Unity was ported to BlackBerry10 and Tizen independently from Unity. (Sony ported it to ARMv6 HF / PSVita) [Which in turn was ported to RasPi]. Its never been "all on Unity". Now that .NET and Mono are under MIT, we will only see more of this (I hope porting work Unity does will be pushed back into the .NET Foundation eco system). Unity should make it easier for the community to help work on lower end peaces of the game engine.

What I find a much more important issue over the .NET version or IL2CPP vs Mono vs .NET Core is the stop the world GC IL2CPP and Unity's Mono are using. The newer versions of Mono have had SGEN and .NET has also had a low latency GC for a while time now. Iv'e been noticing the current GC causes frame lag issues in VR if it hits a collection cycle.

I really hope the GC gets updated more then anything...

 

My main concern is that I've been in the software development business long enough to know that "practically at the finish line" can stretch into months and years. The .NET upgrade's not even on the roadmap yet. And the Unity GUI update was "practically at the finish line" for.. what... five years?

 

Yet the alternative, at least if Unity's developers have been any indication, would be "guaranteed n months/years" whereas their current path is only "maybe months/years". Better to stick it out than to suddenly about face a significant way into development. That said I honestly don't expect IL2CPP to be complete until Unity 6. Or at best a very late 5.

 

I don't think IL2CPP is a creature that can be completed, merely be up to date as it can be with new features and performance as time goes by.

 

Right, my wording was pretty bad. I blame a distinct lack of sleep. What I meant was when it's released for all platforms.

 

Oh I'm not picking on your points or anything, just mumbling my thoughts as I do.

 

Miguel de Icaza said on a recent Reddit AMA:

“. . . Second, while .NET and Mono are fabulous there are so many great ideas that we have in our backlog to improve the platform, that if anything, we need more time and people to join us.

We want anyone that comes in contact with C# or F# to have a delightful experience.

As for specifics of projects, we want to help Unity upgrade their .NET stack and support them all the way to do so.

What Unity has done embedding C# into a game engine is brilliant, and we want to replicate this both across other game engines, but also to other applications. I want to make .NET the scripting language of choice for all developers.

To assist developers in this goal, we have been working on a rich REPL/console that any .NET or Mono developer can add to their apps.

So essentially, embed Mono or .NET in your app, and get a great scripting, prototyping, learning and interactive console for free:”

Storms a comin' A storm of Awesomeness!

 

Yes I do want.

Tasks are not exactly about threading, they are about async operations. I'm using outdated port of TPL for Tasks as futures with no threads, just to wrap coroutines.

 

Realized I'd prefer Unity to be a little less cross-platform. So users don't have to pay for things they are not using. It's great that one can target Tizen, or Samsung Smart TV, or I don't know. But the rest of us, who are interested only in Android, iOS, UWP and desktop Windows, implicitly have to pay for these marginal platforms too.

 

I don't know if that's the case. I'm pretty sure Unity wouldn't have added them in the first place if it wasn't going to bring in enough new customers to pay its own way. At least, that logic has been applied by Unity staffers before when people asked for support for a given platform.

As for the rest... sure, I'd love it if Unity only supported the platforms that are relevant to my projects. But so would everyone else, and while there's certainly a few common ones I bet that a lot of developers have slightly different lists of which platforms they'd consider to be important.

 

(Sorry, I don't know how to derive noun from adjective “cross-platform” correctly; so I'm going to introduce term “cross-platformness”.)

I mean, that “cross-platformness” is used as excuse for not using mature Framework; because some platforms have no Mono support, so Unity needs to ~reinvent the wheel~ develop their own nonstandard toolchain. In this context “cross-platformness” actually sounds like disadvantage. And Xenko (mentioned above) has advantage over Unity being not that cross-platform: it targets only Android, iOS, mobile and desktop Windows, so allows just to use latest Xamarin or .NET 4.6 with async/await, etc. It does not require a lot of months of “porting Mono” to marginal platforms for developers; and users don't have to wait for years until runtime replacement is developed and polished.

 

One of Unity's primary advantages is that cross-platform support. Removal of that support would be counterproductive to the engine. Additionally in the long term this migration to IL2CPP may seem like a mistake but it will bring benefits that the framework alone cannot provide. There is simply a slight hiccup phase while everything is prepared for prime time.

If it does a better job then why are you still here? Choose the engine that best suits your needs.

There is nothing marginal about the consoles.

 

This. Unreal supports less platforms. And by all accounts it's a good engine.

Unity has managed to mop up every indie and mobile dev in the business, by virtue of being so cross platformy. I doubt they will abandon their key selling point anytime soon.