[webkit-dev] Swift in WebKit

[Ryosuke Niwa]

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

>
> On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
> 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?
>
>
> I did look into it. However, CoreSimulator is an OS X framework, and
> DRT/WKTR are built as iOS Simulator binaries. The linker will not link OS X
> dylibs to iOS executables and vice versa - although the CPU architectures
> the same, the platform load commands conflict and cause a fatal error at
> link time. Even if that were possible, it would involve some kind of
> self-hosting, self-installing voodoo. A new OS X executable target is a
> minimum requirement, as CoreSimulator is the gatekeeper to the simulator
> device. Additionally, a single xcodebuild invocation does not like mixing
> targets with different SDKs. However, in the future, I would like to
> combine the DumpRenderTree and WebKitTestRunner projects. There is plenty
> of code to share between those two targets and they aren't cohesive at all.
>

I didn't mean to use the same binary but rather to share the source code to
avoid the code duplication.

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