Comments URL: https://news.ycombinator.com/item?id=20006677

Points: 1

# Comments: 0

- 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.

This posting let you know their intention. Isn't it newsworthy?

No offense, just a question. Because I'm not a native English speaker.

Comments URL: https://news.ycombinator.com/item?id=15700902

Points: 118

# Comments: 73

* Xcode = iOS bugs + UIKit bugs

* Xamarin = iOS bugs + UIKit bugs + different runtime, language, memory model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs & overheads + C# bugs + slow followup of platform updates

* Xamarin Forms = iOS bugs + UIKit bugs + different runtime, language, memory model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs & overheads + C# bugs + slow followup of platform updates + extra UI abstraction layers + lack of fine level controls & features

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.

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.

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.

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.