Crowdfunding world domination

Using Swift
41

As a person who has worked on two platforms (macOS and Ubuntu with i3) simultaneously, I much appreciate that IDEA et al. work and look the same way on either. That keyboard shortcuts are different is painful enough.

I daresay that single-platform users are better served by "fully integrated"/"native" applications because they don't have to re-learn. Cross-platform users are better served by "always the same" applications because they don't have to re-learn.

(Responding to your other points would open too many tangents.)

1 Like
42

Personally, I think that if I use an IDE, my main concern is with its practical utility. To the extent that design matters this mostly includes some customisation (e.g. colour schemes, fonts) and some general readability and discoverability. In that latter aspect, I find XCode to be quite bad, tbh, there are a lot of random icons where it's not at all obvious what they mean.

Whether the IDE is "beautiful" or fits with the OS is really a secondary concern at best.

43

Can we please split the IDE discussion into a separate thread to keep this one on topic?

6 Likes
44

Both are linked, there can't be world domination if swift can only be used on macOS with XCODE for IOS only
This is why there is still no windows support, because the way you think is closed minded

45

Please keep the discussion civil. Insulting others is not going to get you anywhere and is not acceptable behavior for this forum.

4 Likes
46

First of all, Xcode not single IDE in the world and definitely not the best. Despite that IDE is a good commitment into the language infrastructure, it is not necessary, you free to use any editor that you want to write your code and then compile it. As was mentioned it this topic earlier, you can find or even write extensions, e.g. for Atom editor. From my point of view, C/C++ got really good cross-platform IDE just about two years ago with CLion release (which also has Swift plugin), because before this I really hated all IDE like NetBeans (note that this is only my opinion, I heard a lot of good feedback from many people about this IDE, but I think this just about habits and expectations).
Second one, Swift is not only about macOS and iOS development. Yes, it does not support Windows yet, but if you'll take a look at the docs folder (https://github.com/apple/swift/tree/master/docs) you'll see there some information regarding building on Windows. But Swift is available on Linux, which I think is more important at least for now.
So, I should disagree with your statement that

swift can only be used on macOS with XCODE for IOS only

47

(i am the author of the atomic blonde plugin) this is a bit of an oversimplification. Swift support on anything other than XCode is hacky and incomplete at best. some of it is atom’s fault — it really isn’t designed for a language with as convoluted syntax as swift,, its target audience is js developers after all. (though the situation isn’t as bad as with c++). a lot of it is swift’s fault though. For example

  • Swift doesn’t “install”, it’s distributed as a swiftc binary, blender-style. this means you can’t rely on the swift toolkit always being available, which you need to plug into to be able to do things like syntax highlighting and code completion

  • The operating system has no clue swift exists. you have to do .bashrc / .profile hacks to get your terminal to know about swift. for ides, this makes it really difficult to link editor plugins to the swift runtime libraries, if the user even has them installed. right now, atomic-blonde users basically have to build and link the plugin locally to use it which it why it’s basically still an experimental plugin. in theory you could use dynamic linking and ask the user to tell it where the runtime libraries are but it’s still a major point of friction and most people don’t know where their swift runtime libraries live anyway

  • swift SourceKit really isn’t that well suited for atom in particular. Atom is optimized for regex grammars, which is integrated into its own rendering engine, so invoking an external highlighter like SourceKit requires translating through several abstraction layers. it’s generally still fast enough for average-sized swift files but the lag starts to become noticeable once the file reaches a 4-digit linecount. this is really atom’s fault but it doesn’t have a great solution

  • SourceKit documentation is bad. like,, really bad. obviously this makes writing plugins v v difficult.

  • there’s a lot of weirdness that results from swift, sourcekit, and atom’s disagreements over what a ‘character’ is.

1 Like
48

Wow, thanks for such description, this is really interesting!

Does this true for some other languages, e.g. Python or Rust? As I understand, this is problem until Swift not in the system by default. I'm using Python for some automatization (I think as most do), and I've tried Atom/Sublime Text for writing code with some plugins, but they rather interfered then help. Same for Rust, I've just started learning it and has been surprised that despite powerful compiler there are no good tool to write code and quickly get warnings.

I'm not saying that for Swift we should leave things as it is, of course there are ways to improve (especially if Swift oriented on people who's new to programming). And I agree that there are a lot of differences for people who use Swift in perfect conditions on macOS and who try to start with Linux. But anyway situation is not so sad as pointed above by @RUSshy.
And as I understand this topic is to discuss processes required which will lead to improvement of language infrastructure. And I think pointing such problems as integrating Swift and Atom is good way to define drawbacks. Because if having IDE that perfectly designed for one language is interesting, have an ability to integrate language support into any editor is important for language evolution, e.g. a lot of developers use vim.

49

I agree completely, which is why I think that all attempts to solve the Linux problem by just developing the one IDE - even if it is cross-platform and all - is going to disappoint. Linux devs are often way too opinionated and want to choose their own tools (for better or worse). That's why IMHO the primary focus should be on building good CLI tools first (the ones we have right now are really not up to speed compared to most other server-side languages) and then build IDEs and editor plugins around them. Even the IDE-heavy Java world has learned this by now.

(The other reason why good CLI tools are absolutely vital is in order to have a good CI experience. Currently, if my build fails on Jenkins I have to scroll through a lot of noise to find out which test failed.)

But I think what many people are arguing is that XCode is (kinda, almost, I've tried it without and it's not that pleasant) currently necessary because many things are really awkward to do from the console or other editors.

3 Likes
50

I'm one of those developers that solely uses vim with Syntastic and YouCompleteMe to get more IDE-like features (Almost all of my swift dev work is done on a headless linux server), so building tools specifically for swift IDE integration doesn't really excite me. I'm more than happy with my setup and even though I used to be a heavy Xcode user, I find it difficult to switch back to an IDE now that I'm so used to vim's hotkeys, macros, plugins, etc.

The only reason I'll clone my code onto my Mac and run it in Xcode is for its debugging/profiling tools (or to test that my Darwin code works properly). I'm decent with lldb, but swift test doesn't work through lldb (using lldb -- swift test I can run tests, but setting breakpoints doesn't work). Xcode makes issues that are difficult to debug much easier to solve (its Tsan interfacing is wonderful and I love the profiling tools). I would love it if there were a way to pause on issues when a project is compiled with sanitization and run through lldb like how Xcode can do. And if there were CLI tools that could do what Xcode Instruments can do.

1 Like
51

I've gotten a request to split this thread into separate threads for funding language development and funding the creation of a portable IDE.

I'm considering doing that, not because the idea of developing a portable IDE for Swift is in any way off-topic for the Swift forums, but because:

  • they do seem to be somewhat different conversations,
  • the IDE discussion is definitely drowning out the other, and
  • IDE development is a much larger project than the individual slices of piece-meal contracting work that (IIUC) are being imagined for language/library development.

At the same time, I'm always reluctant to actually perform surgery on a thread because it takes posts out of their original context and inevitably raises a number of awkward questions about where best to put certain posts.

I think that perhaps the best solution at this point would be to "split the baby" and create two separate threads, one to discuss the development of a portable IDE for Swift, and another to talk about how to organize crowd-funding of smaller-scoped language/library/tool development work. Does that seem reasonable to people?

13 Likes
52

Only one person asked for IDE development, everyone else seems to promote the idea of CLI tools, language server and such

You seems to jump to conclusion easily, have you read the whole post ?

53

Yes, I've been reading the entire thread. What I have seen is that there is a very active discussion in this thread about developing things in the general space of language-aware editors — IDEs and IDE plugins and language servers and syntax highlighters — and it is drowning out the discussion that other people would like to have about developing the core language and libraries. I am not trying to stop people from having that discussion about editors; I am just trying to make sure that other people can also have the discussion they want to have.

2 Likes
54

I am the one who suggested splitting the thread, first in the thread and then in a private moderation request. I don’t see why this should be a point of contention. I think the discussion about IDE and tooling in general is a good one, but the original point of the thread, at least as I read it, was the funding itself:

So I suggest splitting the discussion of how to fund from the discussion of what to fund. Both are needed, both deserve a separate topic. Doesn’t that sound reasonable?

1 Like
55

This is a bit confusing, because motivation of splitting differs from message to message:

I'm not sure if we need what to fund, I think this more general topic than just constraint to the funding. I'll prefer separation between evolution of the language and tools around the language. And then funding question became totally independent.

56

The reason I think splitting by technical area makes sense is that the structure of the funding seems like it would have to be quite different:

  • Most language / library development is small-scale independent work, and different sponsors are going to have very different idea of what work they want done. Both points suggest that it would be better to have something more like a contract / sponsorship marketplace than a central foundation that employs programmers on a more permanent basis and assigns them tasks based on incoming funding. If I as a sponsor want to add a WeakDictionary type to the standard library, and the central foundation is currently focused on an Amiga port, I probably don't want to just throw money at the foundation in the hope that they'll decide to work on my data structure next.

  • Writing, maintaining, and improving a Swift language server for some specific editor infrastructure is a much larger project with complex interdependencies between different sub-tasks and significant and predictable ongoing maintenance costs. It's either a multi-person project or at least a rather long one; it seems more like a permanent job than ad hoc contract work.

6 Likes
57

But IMHO, this thread has never been about "small-scale language / library development"; if company A wants to add a WeakDictionary to the stdlib, they can write it as a library first and then make a pitch to add it to the stdlib; this shouldn't be a problem.

It seems rather that some people are realising that "cross-platform Swift" is not going to become a thing as long the tooling doesn't significantly improve. For example, @svanimpe is interested in being able to use Swift in CS education; with the installation story (esp. on Windows, but also Linux) being what it is right now, this is basically impossible. For me and some others, it's server-side Swift that's interesting. Maybe some other people want to create Windows GUIs with Swift, who knows? All these scenarios are difficult because of limitations with the language and tooling. What has been proposed is a foundation that drives cross-platform Swift, instead of multiple independent contractors adding little fixes here and there.

Therefore, I also don't think that splitting off the IDE topic is a good idea. The community (and the core team) hasn't even decided whether such a foundation is something worth pursuing; so we need to build up an argument for why it should be, and the whole discussion about the lack of cross-platform IDEs, good CLI tools, etc. is hugely important for this. Splitting up the topic now seems much too premature.

4 Likes
58

^^ This. I would be a huge fan of a Swift Foundation that works on...well the Swift Foundation (at least at first). Since even just so much of Foundation is NSUnimplemented(). If the Foundation framework could just be finished/refined to behave the same on Linux and macOS then so much more cross-platform code would be available. I see Swift projects all over the place (like server-side swift) that are baking their own libraries because Foundation API's are unavailable or inconsistent on Linux (I've even done this myself). It feels sometimes like more effort is going into evolving the language for new/cool features than into porting the existing language from Mac-only to cross-platform compliant.

My highest priority would be to finish the Swift Foundation implementation. Once that is completed ported and Linux compatible, then I think we can begin working on an IDE or CLI tools or whatever (but this is just my opinionated priority list).

I think that the IDE topic is a separate but related topic. It is not necessary to have a cross-platform IDE to have cross-platform Swift (but many people would find it worthwhile). The IDE topic has been brought up and briefly discussed and is a valid reason to have better cross-platform Swift, but the actual discussion around building/designing the IDE can easily be separated into its own thread.

2 Likes
59

Alright, well, if you think a central foundation is the right way to go to fund the work you're interested in, I won't try to argue you otherwise.

60

@John_McCall Can we ask the core team for some feedback on this?

I would like to make the case that:

We need something like a foundation

First, we need to acknowledge that Swift (so far) has failed at becoming a general purpose cross-platform programming language. To give just one example: We've claimed to have Linux support for 2.5 years now. Yet, after all this time, swift.org still supports only one Linux distro, doesn't even support the latest release of this distro, requires a cumbersome installation process (anything more complex than apt install swift is too complex) and has little to no editor/IDE support. In my opinion, Swift doesn't really support Linux. It supports iOS developers who want to host their server-side projects on Linux servers. That's awesome, but it doesn't help us reach non-Apple developers.

While there is a lot of interesting community work out there, some issues are simply too important to be left to the community (by which I mean: unpaid developers). Platform and IDE support are two major examples here. To use myself as an example: I've been using Swift professionally (in education) since 1.0 and ever since it was open sourced, I have been looking for ways to break it out of its iOS confines and into other courses. I am a heavy server-side Swift user and regularly attempt to develop on Linux using whatever IDEs and editors I can find. I've taught introductory programming courses that use Swift and in doing so, confirmed both that Swift is an excellent language for education, and that Linux support is nowhere near what is required for education. All of the students who attempted to use Linux as their development platform quickly gave up.

Something clearly needs to happen here, and it needs to happen sooner rather than later. We're already losing a lot of potential developers because of our platform support and tooling issues.

You can't take over the world without an army (of developers) and as history shows, that army needs to be fed (paid) or they'll quickly turn on you. We can't fault companies like Apple for not allocating company time to projects they don't benefit from directly, which is why we need another way to fund these projects. I believe a foundation is the best solution here.

Another, unrelated, reason why I think we need a foundation is that we need someone to represent and promote Swift at conferences. This is something Apple is particularly bad at. When I attend open source conferences, I find it sad to see that languages like Rust and Go get a lot of attention, sometimes even have their own track/room, while Swift is nowhere to be seen. What's even more inexplicable is that Apple isn't even present at conferences that focus on app development and where thousands of senior year students are present, ready and eager to have their career choices influenced.

Involvement from the core team is required

If a foundation is erected, involvement from the core team (and other senior developers) is crucial. As part of this foundation, a trusted body (board of directors?) is needed to judge proposals and allocate funds. A process similar to SE could be used to let the community propose and discuss projects. The trusted body could then make the final decision on how to allocate funds.

12 Likes