- I was worried about Google's intention, but I didn't claim one.
- I chose the word "fork" because it was what actually happen.
I tried to be dry as much as possible to deliver just a fact.
Making people confused was not my intention.
Anyway, I'm sorry for that confusion.
- I didn't think the word "fork" is abusive or bad wording at
the point of posting. I simply forgot the other
meaning of "fork" at the point of posting.
Now I remembered how it's different.
- Now I agree that the word "fork" could make you
(and many other people) confused.
I'm sorry.
- If the wording "fork" made you confused, I think you also need
to blame Github for why they didn't use the word "clone"
on their website.
- I blame Github because this is major reason of why I forgot
the other meaning of "fork" nowadays.
- You are telling me to find out before posting this to here, but how?
At the point of posting, there was literally no one was
discussing on this. No one around me could explain Google's intention.
I googled, and there was no result.
If you know a good place to ask, please let me know.
I'd love it.
- Google engineers came and explained their intention.
IMO, this posting ended up in the best way it could.
How do you know the intention of a fork without their own explanation? It was unknown at the point of posting, and posting title is still technically valid.
This posting let you know their intention. Isn't it newsworthy?
Such cross platform apps are meaningful only if your product doesn't need great UX. But the question is, if your app doesn't need it, why do you need a native app? It's better sticking to a web-app. Make a web-app and cover all platforms at once.
I believe you're going to learn a new language for future problems, and I strongly recommend Rust.
If your performance (throughput and latency) requirement is not very critical, language really doesn't matter. Even scripting languages like Python, Javascript or Ruby performs very well by spawning servers on each cores.
But if your performance requirements goes serious, I believe you will get unusual bottleneck (e.g. GC, VM, memory usage pattern, specific hardware,... ), then you'll want a kind of "full-control". In this case, the only traditional choice was C/C++, and that's why many large-scale companies like Google and Facebook are using C++ internally.
Anyway C/C++ cannot provide enough level of safety that required to provide good productivity. As a workaround, you can use a sort of dynamic checkers (sanitisers), but the dynamic checkers are very immature, and fundamentally dynamic.
A new, and the only current alternative for this case is Rust. Rust provides far batter safety from first at "compile time". It also provides far better linguistic constructs and semantics. But the language itself is immature.
Anyway, (1) there is huge demand for this kind of features from C++ community and (2) Rust is completely engineer community driven (3) and fully open-sourced. So I expect the maturing speed of the language will be incredible that never been existed in language history. And it's fully open sourced.
I feel like Apple software quality has been degraded because I always expected kind of top and flawless. It has been and must be to keep its position.
As far as I remember, in earlier versions of OS X, I just didn't care on visuals so much because it was very flawless, so everything felt smooth like a fluid and nothing bugged me.
With 10.10, I see visual/animation glitches very frequently on same hardware. And it is getting bugging me up and it feels flawed. I believe this is because of moving on to a new visual styles. But if this sustains, it's just a matter of time to hit the bottom.
I think Nim author need to documentate/explain/illustrate a lot more about its GC. I once have interested in Nim, but I couldn't figure out how its GC is proper (predictable & deterministic rather than throughput) to RT apps. And that dropped my interest on it. I believe this is a biggest obstacle to RT app programmers to take interest on Nim.
Nowadays the term "GC" almost implies "tracing GC", so "non-tracing GC" need to be well explained. Or need to adapt some new term to explain new concept. Currently, Nim's GC explanation just looks like incremental RTGC that is not really attractive to existing RT app programmers.
I disagree to optimisation, but agree to portability.
It's difference of 100% and 99%, but sometimes the 1% can be significant. And of course, it also can be insignificant.
Swift is just a fresh new language which is compiled statically just like C/C++.
Swift's Objective-C compatibility mode is a kind of ugly extension feature to support their legacy code. The compiler makes inter-op stuffs automatically.
You can target only down to 7.0 because Apple set the goal of 7.0. There should be some stuffs required to support Swift, anyway it doesn't matter unless you're a runtime engineer. Point is earlier than 7.0 is out of support by Apple.
DVCSs are designed for full error-tolerenceable text based source files. It requires the files are fine to be broken (e.g. for compile). This is the premise to merge data files without any issue.
Storyboard/IB data files are zero-tolerence. They always require full integrity for their data files. As the internal data is described as a interconnected graph, there's no effective way to manage Storyboard/IB data files in broken state. Most data files are in this form, and cannot be used in DVCSs.
Then, trying to use zero-tolerance data in a system which require full tolerance doesn't make sense. At least for merging.