eonil

What do they actually want? I'm so curious.

I'm not sure on this. Rust has some users all over big tech firms including Google, MS, FB, Apple and Intel.

I seriously doubt that whether any of their “end users” are allowed to use Rust.

Well, I'm gonna make some excuses and questions.

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

Does it feel differently? "fork" as a noun and a verb?

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

I see your point. Thank you for your opinion, and I don't agree. Please see https://news.ycombinator.com/item?id=15701539 for why.

Made-up title? Github says "google/swift forked from apple/swift". Is that wrong?

I also worried having two different languages -- Google Swift and Apple Swift.

What you have to deal with;

* 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

Can I ask the products you have worked on with Xamarin?

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.

What if we combine this with AI?

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.

The best way for this is avoiding Storyboard.

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.

more open? what a funny joke i ever heard. please define the meaning of the more, and at least tell who is the more open one.

Obviously C/C++. The most insane choice but also the only sane choice. C/C++ is supported by literally EVERY platform. Whatever platform you try, it will support C/C++, so that's most useful. Even you can't find usefulness from it, it will make you to feel any other language just easy.

Can I expect this would allow me to write an IDE plugin in C++?

Before Clang, we had GCC monopoly which was even worse. Situation is getting better.

It seems attacking Adobe shit (by writing a blog post) is the best way to get their correct support.

Oh it's getting even more interesting!

Do you have any plan to add hygienic macro and coroutines? AFAIK, coroutines were always supported in traditional Smalltalk, but if you're based on objc runtime, it may not possible. So I am asking this.

Interesting.

I had a quick look, but I don't see any mention about memory management. Because it must have fully deterministic realtime aware architecture to replace or complement Objective-C, and memory management strategy is one of the most important stuff. If it's based on typical (non-deterministic) GC, then it won't be that much interesting anymore.

Also, I think using `<-` instead of `:=` would be better for a new Smalltalk dialect. With proper editor support, the arrow sign will look far better then colon-equal sign.

Deterministic realtime attribute was required condition on Apple product, and any GC based language was not acceptable at the time. But sometimes I think they could solve the issue if they could research longer.

I agree.

In other words, automatic program-correctness check is a crucial feature if project goes larger. And type check is actually one of the simplest, easiest and fastest way to archive that.

But most dynamic languages doesn't provide type-check. Really sad.

Adding type annotation on dynamic language is a kind of best mix of two worlds, and Julia seems pushing this approach even further - JIT static types from type annotation.

Does Julia have AOT compiler which produces a binary which can be linked to a C program? I am asking this because I have to consider availability on iOS - which is a platform prohibits JIT.

International Virtual Machine