It's not a "made up title", Google did in fact fork Swift on GitHub. That doesn't mean anything in an of itself, thousands of people/organizations have also done so, but it's mildly interesting since it's Google, and because it was posted here, we now know why.
The problem is that "fork" means two different things at this point. Compare "FFmpeg developers fork FFmpeg" in the sense of "...and create libav" and in the sense of "...so they can submit pull requests." One is extremely newsworthy, one is extremely not. If you're posting something to HN, it's a reasonable assumption that readers will think you're posting a newsworthy thing as opposed to not.
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?
"Google employees are contributing to another project" is not newsworthy, no. Neither is them creating a github fork unless you have evidence that they do not intend to use the fork for the main reason people create GitHub forks: contributing.
No, that doesn't make sense. You didn't think they merely made a github clone - as you yourself said above, you thought Google was going to make their own version of the language. You posted suggesting that they are. But it wasn't true. People working at Google had to correct you. Other users flagged your post into oblivion. Those thing wouldn't have happened if the title wasn't wildly inaccurate. You should have tried to find out if it was, instead of posting an inaccurate thing on HN.
- 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.
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'm working on that! Long story short, it's hard. Most functions are big ones, and knowing where to look in the infinite set of functions is a big challenge. But it's a super fun problem :-)
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.
