[webkit-dev] Swift in WebKit

[Ryosuke Niwa]

On Mon, Jul 28, 2014 at 8:44 PM, David Farler <dfarler at apple.com> wrote:

> On Jul 28, 2014, at 17:10, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
> On Mon, Jul 28, 2014 at 12:47 PM, David Farler <dfarler at apple.com> wrote:
>
>> Hello all,
>>
>> I have the following bug to help build out support for layout tests in
>> the iOS Simulator.
>>
>> iOS Simulator LayoutTestRelay
>> https://bugs.webkit.org/show_bug.cgi?id=135269
>>
>> I'd like to include this as a new tool written in Swift.
>>
>> Why I think it's fine in this case:
>> - This tool is specific to the iOS and OS X platforms
>> - Swift is a fully supported, albeit new, language starting in Xcode 6.
>> - Swift is probably the best way to get Objective-C bridging "for free"
>> in the long term
>> - Swift supports script-like "immediate mode" with good JIT-compiled
>> performance
>> - The tool's size and scope is sufficiently small with no complex or
>> WebKit-specific dependencies
>>
>
> There is a precedence of WebKit rejecting the use of new programming
> languages in the past:
> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018837.html
>
>
> Precedence drives opinions of law, for which reinterpretations are
> considered to be an unfortunate correction. I don't think it should be
> invoked to hamper creativity or reject something "new". Still, the main
> difference to that case is that Swift is not an unsupported third-party
> language, it won't require installation of new software, and it's not for
> cross-platform automation.
>

 Swift is an unsupported third-party language for people who don't work on
Mac or iOS ports.

For this project, I think it's a valid exploration for code that would
> already have to use platform-specific Objective-C. Of course, I wouldn't
> presume to argue that all of OS X and iOS WebKit code should move to Swift
> at this point. However, I reject thinking that leads one to only consider a
> new possibility when the current situation is unbearable or even painfully
> obvious.
>
> I'm not saying that Swift is a bad language or anything but I don't want
> to start having people writing random programming languages such as
> Haskell, Scala, Go, Rust, etc... deemed hip/cool at the time to create new
> tools in WebKit.
>
>
> Of course. The main difference is that I don't deem it hip; it's a fully
> supported, productized language that ships with Xcode and it's only going
> to grow in use on OS X and iOS. Even so, that Swift is hip and exciting
> shouldn't be ignored. Developing WebKit should be as exciting to hack as
> much as it is an exemplary web framework too, as both motivations work
> together to make it better.
>

In my personal opinion, "hip and exciting" should never be a reason to do
anything.  However, we can agree to disagree here since this is a very
subjective topic.

>  It would increase the entry barrier of working on those tools even if
> they were specific to one platform.
>
> It is something new to learn. Is it a *barrier?*
>

Yes.  Every new programming language we introduce into the project
introduces a new entry barrier to hack on the project.  Namely, everyone
who ever has to modify that code need to learn Swift in addition to
Objective-C/C++, which is used to write some parts of since Mac/iOS ports.

I personally hate Objective-C syntax and would prefer using something like
Swift.  However, that preference doesn't outweigh the overall cost of
introducing a new programming language into the project of this size with
so many contributors.

I don't think so. I think it's an opportunity. We assumed Objective-C in
> the first place because it was *the only *way to write apps and
> frameworks on OS X and iOS. Now that's no longer true and, while both
> languages are supported, if someone didn't think it was the way forward, I
> don't think it would exist in the first place since Objective-C does a
> pretty good job already and it could've been extended incrementally. That's
> my perspective. Obviously it's not going anywhere anytime soon but,
> if Objective-C were deprecated in the future, and we suddenly decided we
> needed reviewers who knew Swift, where would we look?
>

There has been no indication that Objective-C will be deprecated anytime
soon.

> e.g. what should GTK+/EFL contributors do if they wanted to modify the way
> webkitpy works and needed to make changes to your tool?  Or do you think
> such a scenario is extremely unlikely?
>
>
> Given the pace of webkitpy development ... :) I do think it's unlikely.
>

That's great to hear since the cost of using Swift is proportional to the
number of people who have to maintain the tool.  If you're the only who has
to touch the codebase, then the cost is virtually zero given that you seem
to already know about Swift.

It's just a proxy to a simulator app's standard file descriptors which are
> only accessible indirectly and I'm happy to say that it somewhat pays for
> its debt by removing lots more platform-specific code than it creates (
> https://bugs.webkit.org/show_bug.cgi?id=135374 and
> https://bugs.webkit.org/show_bug.cgi?id=135271). It doesn't exist to
> automate but make it possible to run layout tests on the simulator with the
> current tools. Essentially, it pretends to be DRT/WKTR, so it has the same
> I/O behavior requirements as those tools.
>

It doesn't seem like the benefits you point out are independent of the
language choice.  We can still remove ORWT even if we wrote the tool in
Objective-C.  However, I would point out that DumpRenderTree for Mac port
is written in Objective-C++, and there is a benefit in sharing code with
it.  Have you looked into that?  Or have you decided that there is nothing
we can share between the two programs?

 The larger discussion of using Swift in larger AOT-compiled contexts but
>> is probably going to happen in this thread anyway, so let's have it:
>>
>> *What of future use of Swift in WebKit?*
>>
>
> I would really like to know why we should use Swift in WebKit at all in
> the current stage?
>
> Fine, twist my arm. :) In comparison to Objective-C, I don't think it's a
> stretch to think of these as major achievements:
>

In my opinion, the fact the language is in such a premature stage outweighs
any potential benefit listed here.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140728/57b217c8/attachment.html>