Perfect should be more "Swifty"

[SeanStephens]

We'd heard from a few people that Perfect isn't as "Swifty" as it should be. We'd love to hear what this means to you, and where you think we could improve Perfect to be more so. What is "Swifty" to you that Perfect isn't?

[siejkowski]

Hi :) There were two main points that I've stated during presentation when I was sharing that opinion: the lack of Swift Package Manager support and the lack of modularity. Both makes it way harder to use Perfect along with the rest of Swift ecosystem.

However, I can see there's already work in progress on SPM support, which is great. It will hopefully make it way easier to switch some components, like adding alternative templating engines or data serialization/deserialization libraries.

I guess I haven't said much new, since this is what you've already doing :)

[ghost]

Thanks @siejkowski - you're right, we're working on both SPM and modularization, and your comments reinforce the need for us to work on these.

Was there anything in particular - for either, or anything else that comes to mind - that you thought we should consider?

[ejohnsonw]

"More swifty" I think that is what i was trying to say when I opened #134.

[kjessup]

My personal take, as the main author:

The project was created in a modularized fashion to begin with. We had a core library of utilities, around that a variety of server types as separate executables, and a variety of database connectors as separate modules. It's true we include a templating engine and JSON encode/decode utilities, but those are provided as a convenience and nothing in the system forces you to use them or prevents you from using your own. EDIT: I should also point out here that your code, which the system dynamically loads, exists as one or more separate modules. Nothing gets compiled as one monolithic executable.

We are marching towards SPM but it's important to remember that SPM is still heavily in flux, has not yet had a full release and isn't slated to do so for quite some time. While it certainly shows promise, it's currently a bit limited (unable to incorporate C targets) and somewhat cumbersome (git repo all the things) to use. Not to get all stodgy, but I'd prefer a generic makefile. :) It is steadily improving though so I don't mean to be disparaging.

Also please note that Perfect was released before SPM existed, so yes, we have a little work to do to fit into how it wants things done.

[SeanStephens]

Other than modularity and SPM compatibility (both active discussions with ongoing effort being expended to address them) - I'd love to unpack if there is anything else that we could address on the subject of "swiftness" vs. other platforms or just "for swiftynesses sake". Any suggestions on other developers we could ask about this?

[Danappelxx]

I think the bigger topic here that hasn't been mentioned is the quality of the codebase. While I don't want to just flat out say that the code is "ugly", I think I won't be the first to say that it's not "swifty".

The things that makes Swift beautiful and modern are, in my opinion, the shifts from (this is not a comprehensive list):

• inheritance to composition (class -> protocol with extensions, final attribute used by default)
• imperative code to functional code (use of higher-order functions)
• primarily reference types to primarily value types (struct over class where possible)
• mutability to immutability (let by default, var only if necessary)

Perfect's codebase doesn't do a wonderful job of following these patterns. I don't think its fair to say that Perfect has been written in idiomatic Swift until it does a better job of doing so. Unfortunately, fixing this means rewriting a large part of the project, potentially from scratch.

I hate to be so brutal, but if Perfect actually wants to be "perfect" in the context of Swift libraries, there's a lot of work to be done.

[SeanStephens]

Great feedback! Thanks! Although I can't help but consider that as one of the lead contributors to other "competitive" projects to Perfect from before Perfect was released (Zewo and Taylor), you might have a slight bias. ;)

Quickly picking through Perfect, I genuinely don't see many examples of what you are suggesting. For example, mutability to immutability - I couldn't find a single instance in Perfect code. Although as Perfect is the largest codebase in the server-side swift space by far, you would be correct in saying that if we have been doing something wrong for the last 14 months, it would be a big rewrite.

Perhaps I'm coming off as defensive, for which I apologize - but if you can show us specific examples, it would be very helpful. (Especially ones which aren't just one person's coding style, but visibly a departure from idiomatic Swift).

Thanks @Danappelxx !

[tanner0101]

public func PerfectServerModuleInit() {

    // Install the built-in routing handler.
    // Using this system is optional and you could install your own system if desired.
    Routing.Handler.registerGlobally()

    Routing.Routes["GET", ["/", "index.html"] ] = { (_:WebResponse) in return IndexHandler() }
    Routing.Routes["/foo/*/baz"] = { _ in return EchoHandler() }
    Routing.Routes["/foo/bar/baz"] = { _ in return EchoHandler() }
    Routing.Routes["GET", "/user/{id}/baz"] = { _ in return Echo2Handler() }
    Routing.Routes["GET", "/user/{id}"] = { _ in return Echo2Handler() }
    Routing.Routes["POST", "/user/{id}/baz"] = { _ in return Echo3Handler() }

    // Test this one via command line with curl:
    // curl --data "{\"id\":123}" http://0.0.0.0:8181/raw --header "Content-Type:application/json"
    Routing.Routes["POST", "/raw"] = { _ in return RawPOSTHandler() }

    // Check the console to see the logical structure of what was installed.
    print("\(Routing.Routes.description)")
}

class IndexHandler: RequestHandler {

    func handleRequest(request: WebRequest, response: WebResponse) {
        response.appendBodyString("Index handler: You accessed path \(request.requestURI())")
        response.requestCompletedCallback()
    }
}

This code snippet shows examples violating all items on @Danappelxx's list. It also has a lot of shared state which wasn't explicitly mentioned on the list, but is related to using structs and immutability.

(Disclosure: I work on Vapor, Zewo, and SwiftX)

[Danappelxx]

Ah sorry, to make good on those two points:

• Full disclosure, I am on the core team of Zewo and Taylor (though Taylor isn't following a lot of those either, and has pretty much been abandoned at this point)
• Immutability vs mutability isn't a very strong point, but here is an example of what I'm talking about. It is a global, mutable variable which is in many ways an anti-pattern. I hate to bring up Zewo as a counter-example, but the approach Zewo uses is, in my opinion, much better - all the routes are finalized at initialization.

I could look harder and bring up more examples, but I don't think its necessary to find a comprehensive list of examples to show my point. Again, I appreciate how much hard work has been put into Perfect and I'm really just playing devil's advocate here.

[SeanStephens]

Hey! The whole gang is here! (Where's IBM?)

EDIT: (Note @tannernelson - that's not the Perfect codebase)

Thanks guys - we'll look into your suggestions. :)

[loopbum]

@SeanStephens Looks like PerfectlySoft is coming along great. May I ask how well it will work with IBM's Kitura project as you mentioned IBM? I am very interested in using Swift on Ubuntu LTS on Amazon EC2 where I am also using Python 3, Anaconda and TensorFlow. I'd like to integrate TensorFlow into a REST based access API. I know there's a DeepLearning Kit on Github here for Swift but it's an Apache 2.0 license and doesn't look like there's much activity.

[Danappelxx]

Just wanted to respond to a couple thing I saw you mention off hand - this isn't entirely related but I still think they should be set straight.

Although I can't help but consider that as one of the lead contributors to other "competitive" projects to Perfect from before Perfect was released (Zewo and Taylor), you might have a slight bias. ;)

I think this sort of attitude isn't very healthy for the community. While competition is good for a growing ecosystem, I think that collaboration is even better. As programmers, we don't want to reinvent the wheel at every step and end up with a giant mess of incompatible frameworks and standards. For this reason, Zewo teamed up with Vapor, Swifton, and (partially) Kitura and began work on SwiftX, which is a set of cross-platform standards. Through SwiftX, one could take their Vapor application and without changing a single line of code, serve it from both Zewo's and Kitura's servers. I really don't want to see Perfect as a competitor, but due to certain architectural decisions (SPM and modularity, mostly) its difficult to imagine collaboration or even compatibility with one another.

Although as Perfect is the largest codebase in the server-side swift space by far, you would be correct in saying that if we have been doing something wrong for the last 14 months, it would be a big rewrite.

Just wanted to say that the first part of this statement is not true. Here are the outputs of counting the LOC of the entirety of the Zewo organization (with all of its subprojects) vs Perfect.

zewo: 34424
perfect: 20576

EDIT: (Note @tannernelson - that's not the Perfect codebase)

While it's not a snippet from the codebase, it's an example of consuming the API's provided by Perfect, which is really more telling than the implementation itself.

[SeanStephens]

@Danappelxx - it looks like we are in violent agreement! I used the word "competition" in quotes, as we are hardly competitors, except in the friendly sporting spirit sense of the term. "Competition" isn't an evil term and can be very healthy, unless it is used with malice - and I certainly do not use it in that sense.

One of my friends - the owner of one of the largest duck farms in North America - once said to me - "Duck farmers don't compete with other duck farms. They compete with chicken farms." Methinks that in the server-side space, we are beset with "competitors" (from Python to PHP, from Node.js to Java). Ultimately, if we genuinely want to see the possibilities of Swift be realized, we should be working together. "To go fast, go alone; to go far, go together".

Perfect has some unique advantages already, outside of this GitHub thread. We have years of funding in place; we have access to the massive closed-source codebase of Apple's first server-side language (Lasso - Wiki, Guide - from Lasso version 1 to 9) and the team and community who supported the language for the last 22 years, and the BDFL of the same; we have world-renowned development advisors who have proven successes on speed dial; we have many Apps in production already we are supporting (some with Fortune 500's); we have a strong digital marketing firm and PR firm to lean on; we have a CEO with green hair, etc. This project will never be abandoned - it will be driven hard for years to come with constant ongoing improvement.

Given all of these facts - if it turns out that we need to re-write the whole codebase from scratch because it isn't, well, Perfect, we will. Over and over and over - because that is what we love to do as developers. The name Perfect wasn't intended to be descriptive, it was intended to be aspirational. This is not a quick project idea for us. It's a life choice.

You and @tannernelson, amongst others here, are clearly remarkable individuals with visionary skills and deep understanding of our mutual new love: Swift. Would you consider helping us learn as developers and additionally help improve Perfect's Swiftiness?

I propose we start a transparent wiki discussing your suggestions, and get you and others in the community to add what they think epitomizes Swiftiness, describe examples and possible fixes of the same, and help flesh out what Swiftiness really means. To a degree, Swiftiness will always be in the eyes of the beholder. But as a community, we could define and realize best practices that we have missed and clarify what styles are best. In the short term, we'll arrange to go fix these things in Perfect - possibly even together. ;)

Then, as a group, we could make something remarkable and useful for years to come. Something as close to Perfect as we together can make it.

Interested?

[paulofaria]

I'll be straight. I'm Zewo's founder. All opinions stated are mine only.

Currently I have a problem with Perfect. That might change after theses events, who knows. My biggest problem with Perfect is that, in my opinion, you guys are staining Swift's reputation on the server side. This issue was raised because of the code quality. Mainly the "swiftyness" of the code. That's a big problem, but not the biggest. The biggest problem is that you are not community driven. Take those problems with the heavy marketing you have and you get a framework with 6,551 Github stars that does not represent the best for the server side swift community. You guys are a company, so you're obviously profit oriented. I don't know how you plan on monetizing and how far you would work in the community's behalf as a result of that. As @Danappelxx mentioned we (different server side swift frameworks) started SwiftX (Swift Cross Project Standards). We think this will really make the community grow. If you want to be Perfect for the community, here's your chance.

[SeanStephens]

@paulofaria Wow, that's heavy! A stain, even!

Obviously Swiftiness is easily curable - it's just time and input from well-meaning developers, and ongoing pressure to improve and tweak - internally and externally.

Where are we failing on the community side? We have hundreds of developers engaged in dialogue with us on chat channels, thousands of developers engaging with us on Twitter, we've been all over the world talking with and engaging with developers at conferences and Meetups in multiple languages, and have dozens of large companies working with us on innovative new ideas and deployment mechanisms. We've connected with tens of thousands of developers in the last few months - and most of them (with the exception of the ones in this thread) seem to be very happy with our efforts and very excited with our project.

Sure, we are a company. But the word "company" isn't an inherently evil concept. We just came together as a unit to provide strength of branding and as an investment vehicle to ensure we can create a stable, reliable product that stands the test of time - and pay people for their efforts. That's not an evil idea (neither is the idea of profit, IMHO), but rather symbolic of community unto itself. Getting paid to do work isn't wrong. We are humans, too. We have kids. They need to eat. Why not make it a company and market our efforts? ¯(ツ)/¯

Or is this an attempt to get us to look at your new SwiftX idea under the guise of the "community" banner? It appears to be a new idea (previous links to it didn't work - your post is my first time seeing it - certainly no-one reached out to us in a magnanimous community way), with only a few people engaged. Two people does not a community make.

We'll definitely look into it, now that we know it exists - thanks! :) Maybe we'll bring some laundry soap with us so we don't leave a stain. ;)

[Joannis]

I'll have my word here too. I'm not a part of Zewo or QuTheory. But I'm a part of SwiftX and created MongoKitten and I'll explain why your library is horrible for developers, and libraries alike. Not just our but also your libraries.

Your library is bloated. You offer a complete package like Zewo does with the main difference being that you force the developer to use all or none of your libraries. Everything's so integrated that switching away from a part of your library makes you fight the system.

I think some of your things are great, and I think some are horrible. I want to use the great parts and ditch the bad. But I can't. I need to fight the library and write more code than I should just to make it work.

One day your, mine or anyone's library will not suffice for someone. And they'll do it better. With SwiftX I can change from HTTP Server A to B. From MongoDB Driver A to B, and from router/middleware/socket library from A to B whenever I damn please.

So by locking your developers into a complete package everyone loses.

Your developers spend more time working around issues they have with some of it. Or they'll decrease in productivity opposed to different libraries.

Your library will suffer because once a big portion of your features aren't relevant anymore and other libraries just do it better you'll lose customers.

And other libraries will suffer because developers are stuck in your bloated library.

[SeanStephens]

Where was all this great feedback months ago, guys? ;) We could have explained our rationale then.

Methinks there is some confusion as to our intent, or how Perfect is structured at this time. There is no trap, no grand attack on other people's work, no handcuffs keeping anyone using any one part of Perfect or restriction to do so. In fact, our first product had a FastCGI connector for Apache, plus a stand-alone server - giving you various options, from day one. With Perfect you can "change from HTTP Server A to B. From MongoDB Driver A to B, and from router/middleware/socket library from A to B whenever you please". Methinks there is much confusion and FUD being created here. Perhaps people feel left out? That was not our intent. We'd love to work with you guys.

However, a self-respecting professional doesn't keep all their tools scattered around the shop. They keep their core tools neatly arranged in a toolbox. When you need the core tools, there are easily accessible for you - you don't have to spend hours looking for them. Then when you need special tools, you go looking for them. If you need a stronger set of pliers, you add them to what you are carrying. This is core to the principles of lean manufacturing, and also apply to development.

If you only need a single screw driver for a single hobby project or you work on a small team, projects should exist to do so. If you want to get a full-featured toolset to build epic projects and want consistency across your organization - you want a strong, reliable core library accessible in one place. You shouldn't be wasting your time looking - you should be spending your time developing cool new projects.

In fact - a scattered set of tools also makes it very difficult for a new developer to get up and running, or for an older project to get started again after a period of pause. If we are trying to create a gated community for "special" people, every tool should be hidden in a different corner. If we want people to be able to get up and running quickly and effectively, we'll want one toolbox with a quality default toolset that allows people to pick up and run. This makes it easier to work with, and easier to build a strong community.

Whether we like it or not - server-side Swift development is a new category. Server-side Swift developers are unicorns at the moment. They need easy mechanisms to get up to speed, they need everything in one place. This is why we started Perfect this way - to make it easy for new people - to make it easy to build a community around great tools with a great new language - not scrap about whose MongoDB connector is better. That will just be divisive and limit Swift's growth. (And IMHO, this is why we have collected 25,000 Twitter followers in that time - we make it easy for people to understand.)

An example of a toolset that does things in this manner is... Swift. You don't download thousands of pieces to get up and running. You download one project, and use it. And when you need more tools that don't come default in the package, you go get them. I'm also confused - if marketing and capitalism really rub people the wrong way, should you really be working with Apple-backed products? ;)

I will note, we are not against you. I would hope, one day, we can all play in the same sandbox nicely together. We are listening to your suggestions, as a community, and we are working on modularization of our core library (e.g. we released a stand-alone MySQL connector today). We will happily work with you, co-exist with you, and improve with you - and not get in your way. But we aren't giving up, either. Ever.

We will provide a core toolset for developers, all in one package, that makes it easy to get up and running and provides a reliable foundation for the future - a default of excellence. And that doesn't need to be contrary or incompatible with all of the great stuff everywhere else - and SwiftX. Why do people think these ideas are incompatible? That's just silly.

This is a great time to have this conversation, however - as the whole idea is only a few months old, and we have many, many years of future work together. Just because our popularity is high and marketing is good doesn't mean we are the enemy! Let's work together!

[GJNilsen]

I wish you could provide just a thin layer between the web and our own code, no mySQL connectors, or anything else. Only requests are interesting. I wish someone could just cut the cr*p and make something like this.

[Joannis]

I agree. We should work together, not against each other. We're all part of the swift community in the end. But I fundamentally disagree with your statement on the developer's toolbox.

I think you're right in one aspect. There mustn't be a need for your boilerplate for a project to contain tens if not hundreds of dependencies. But that is where you misunderstand the need for SwiftX.

SwiftX doesn't require us to split up into tiny fragments. But it allows the user to unify his libraries more easily.

For example: Vapor has it's own build-in webserver. Yet it allows any other SwiftX compliant webserver to plug in as a replacement.

This allows Vapor to be easy to set up (no additional dependencies required) without withholding you from replacing their server with another one that you prefer.

A project like Perfect can still offer the complete package. But there are only 2 ways Perfect could be viable in my eyes.

• Perfect adopts a standard like but not necessarily part of SwiftX and cooperates actively with other projects
• Perfect splits up into tiny libraries and has a bigger one (Perfect itself) that unifies them

Even if Perfect were to make it's own standards like SwiftX does that'd be a much better option than the current state is.

[Joannis]

I'll give you a list of concrete points Perfect can improve on. Some of which might require patience for an upcoming update to swift/SPM:

• Get rid of C dependencies where you don't need them
• Compile C dependencies with Swift where you still need C dependencies
• Don't try to do everything yourself. Other projects with a smaller scope are better able to focus on the goal. Doing a hundred things at once will never be as effective as focusing on a few. We're not programming in Java. This is Swift
• Swift has guidelines over here for developing APIs. Try to stick to that as much as possible
• Collaborate. Opensource is about collaboration, not competition. You're a company.. I get that. But if you're developing an OpenSource product. Act like it. Your Apple argument above is completely invalid. Apple collaborates with swift. You compete with the community.

[ejohnsonw]

I guess this is when I say I'm not affiliated with any of the teams/frameworks mentioned.

@SeanStephens @kjessup. I commend you for being open to listen, it requires a special kind of "loving what you do".

A few thoughts:

I relatively new to Swift to make much sense of the code issues mentioned. Being mostly a backend developer I definitely agree a couple of things said there: that the "compet*tion" is not within but with other frameworks, other languages, and that collaboration would be beneficial to this nascent ecosystem.

In my case, I like the the concept of "starter kit" that you mentioned, which is very convenient specially if you don't have a lot of time to shop around or ...like in my case you are new to the scene and don't know what to choose, just wanted to be able to use SPM, and a way of checking out only certain parts of the repo (submodules).

I'm looking forward to see where you guys are going to take Perfect, knowing that in fact it's not perfect, but it's perfectible.

[SeanStephens]

@Joannis - absolutely fantastic feedback, this is exactly the help we need to make our community stronger. (and @ejohnsonw - thanks of the vote of confidence!)

We could continue ad nauseam on the merits and benefits of a centralized code base vs. hundreds of separate dependencies. Although those who came from the NPM world will be prone to inspirational dependency trees, it's certainly not always a strong coding practise to rely on breaking everything up into little bits and relying haphazardly on everyone else.

I also appreciate - despite many of the contributors to this thread being the leads for the largest server-side projects in the Swift world - that most iOS developers have been well trained to pick and choose what they want like candy at a candy store from different boxes. And for App development, that's a dandy practise.

But those of us who have run companies where thousands of people are calling in after a server melts down (or a cloud node frys), the backup server failed, GIT is down and the codebase fragmentation means it will take weeks to figure out what you did and where you got it from, not minutes - realize that in the server world, reliability and simplicity trumps fancy choices, sometimes. The toolbox idea isn't a bad one - it just may be something you aren't used to. For App work, great. For server work... after 23 years of server-side language work, we'll be hard-pressed to capitulate on breaking up the continent into little countries.

Ergo, fragmenting into a thousand tiny libraries doesn't seem like an effective strategy for Perfect at this time. Nor, in the context of a thousand other magnificent libraries already available (Zewo! Vapor! Kitura! etc.), does it make sense to have one more random set. One big library with a marketing engine behind it is still a great flagship for the server-side Swift community, and benefits everyone.

Having said this - @Joannis , your point on becoming modular and compatible with other community libraries is genius. I'm a little concerned that this thread didn't smack of a magnanimous community engagement, and that we'd be bullied and finger-waggled in SwiftX in particular rather than welcomed - but we will certainly approach the idea carefully and with great interest. And all of your other suggestions are bang on. Some of the suggestions by both yourself and @Danappelxx (and others, off list) have been very constructive and helpful - we have work to do. Thanks for the help. :)

There's room in our nascent ecosystem for both ideas to work together harmoniously. We look forward to working more with you!

[tanner0101]

we'd be bullied and finger-waggled

That's definitely not true! The first rule of SwiftX, as stated on its documentation, is that it's Inclusive. We'd welcome Perfect with open arms.

The issue here is honestly not the code quality. None of us our perfect. That's why we're working together to create the next generation of server side applications with Swift.

The issue is the marketing strategy that Perfect is employing: referring to the project as an "enterprise-grade web server" and posting it repeatedly on multiple channels to the point where it's considered spam. Server side Swift is not ready for the prime time yet. It literally cannot be until Swift 3.0 is released. I think the way you're advertising is misleading to the community. And it's ultimately leaving people with a bad taste in their mouths about Swift in general when they see how unstable it currently is. I know you want to take advantage of Swift's hype to rack up the stars and the followers–everyone wants to be recognized for their work. But that's just not going to help us out to have someone advertising server side Swift as something it's not.

[SeanStephens]

Methinks we've turned to a new subject now: marketing. Lovin' the transparency! It's helpful.

Technically, an "enterprise" is a business or company. Since we seem to be the only fans of companies in this group, doesn't it then seem appropriate that we use the word "enterprise" in our marketing? ;) We aren't the only ones (is IBM here yet? James? You awake?).

http://www-03.ibm.com/press/us/en/pressrelease/49157.wss

I'm not sure I agree that Swift isn't ready for "prime time". Sure, it's not finished. But art is never finished, it's only discarded. We already have dozens of "enterprises" using Perfect in production, happily and safely. Who has a bad taste in their mouth because of Swift's failure to perform? I haven't met a single person who has said that yet, anywhere in the world. On that note - I have to honestly ask, by your line of reasoning: when will PHP be ready for prime-time? Hehe.

As a marketing guy (hey! this is my territory!), I can tell you without reservation: no developer in the world is going to throw everything they have ever done out the window and just jump into Swift because our website says "company-grade". So should we spend the rest of the year marketing that "Swift is pretty pathetic right now - but you should start thinking about it in four or five years and get involved now anyway"? A) it's not true, Swift rocks and b) we should all give up now, because the community is going nowhere, fast.

Big ideas require big claims. Be bold, and then back yourself up. Marketing is based on aspirations, not limitations. "Buy my product because it only sucks a bit" rarely works. "We believe Swift is the future" is the truth.

Just like companies aren't The Devil, marketing isn't The Devil either. And I'm certainly not embarrassed by accusations of successful marketing against us. We are bold, it works, and I don't feel we should apologize for that - cause its helping everyone. A rising tide lifts all ships. Wouldn't you rather have a marketing machine on your side, pushing for the adoption of server-side Swift from every angle? Are we not a massive asset to your work, instead of a thorn? To fight the chicken farmers of the world on your behalf? To win over PHP and Python and Node guys to come play in our sandbox?

Having said that, if you guys believe using the term "enterprise-grade" is the unique limitation from us from being friends, I can only think of one place in the entire world it exists (our front page), and it doesn't hurt to replace that with something that doesn't rub you the wrong way (Kyle hated that terminology anyway). But we aren't going to stop building enterprise-grade applications in Perfect and Swift just because we are afraid Swift isn't good enough for prime-time yet. It's good enough for us, just as it sits - and it's getting better every day. The phrase isn't untrue.

I'm not sure where we are leaving people with a bad taste in their mouths about Swift - or that really anyone has a bad taste in their mouths about Swift - our how it is "misleading to the community". I've never heard that sentiment before today, nor do I believe we've mis-led anyone. Marketing is a good thing. At the end of the day, Swift exists because of Apple, and Apple exists because of good marketing.

In any case - thanks for the comments about open arms - we feel the same back.

Onwards!

[paulofaria]

Just want to be clear that my reason to be here is simply because I care about the Swift server side ecosystem. My opinions might be strong but they are well based. I know it's hard to hear such criticism. I'm sure it would be tough for me if I were on your spot. But that's what you get when you're in the spotlight. You should be prepared for this, and this is part of the reason I don't like your marketing machine. You are heavily marketing something that in my opinion doesn't reflect the best, the perfect. And that's what I mean when I say you're staining server side Swifts image. You know that the main author of Perfect does not have a strong Swift background. So you know that the code will show it. This wouldn't be a problem if you didn't have your marketing machine. But when you have code that's not following Swift best practices that's being exposed to a lot of people who never saw Swift before. They're going to think that that is Swift. But it isn't. OK, you're working on that now, and that's awesome. But the damage is done anyway, because you guys decided to heavily market something that's not the best it can be. You just heavily marketed something built quickly in a small time-frame by someone who doesn't have a strong Swift background. So that's going to piss off people that really know swift. I say this as a Swift developer. Not as Zewo founder. Even if I haven't started Zewo when Perfect was launched I would feel the same way.

Methinks there is much confusion and FUD being created here.

There's no FUD. We just care about Swift on the server side.

Sure, we are a company. But the word "company" isn't an inherently evil concept.

I never said that companies are evil. But we all know companies use walled gardens as a strategy. You claim you're not one of these companies. I really hope this is true, because up to now, you haven't proven it with actions. I really hope this will change.

Or is this an attempt to get us to look at your new SwiftX idea under the guise of the "community" banner?

To be honest I was unsure about mentioning SwiftX and actually about showing up here at all. But I couldn't keep these thoughts I'm expressing now to myself. As an active member of server side swift I have this responsibility. The reason we didn't reach out before it's because of this walled garden image you guys pass. And you can't blame it on us for having this view. It's the sum of your actions that made us see you like that. From the first license to the whole company thing to the monolithic architecture.

And now we reach the Toolbox example, which is perfect (pun intended haha). You use the analogy of tools for the modules and the toolbox for a collection of modules. Well, that's exactly what Zewo provides. We have a set of tools, which you can use separately any time you like, and a toolbox which is nothing more than an umbrella package importing the most important modules. I agree with everything you say, and it applies perfectly for Zewo. But unfortunately it doesn't apply to Perfect. You don't have a toolbox. You have a blackbox, which you can't take things out. I'm really happy that you guys are working on modularization now. I just think you got the application of the toolbox concept wrong. Hopefully you'll see that having separate modules gives all the advantages you claim if you have an umbrella package containing the best tools.

Just because our popularity is high and marketing is good doesn't mean we are the enemy.

I don't want to be your enemy. I really want us to grow together. I just have strong opinions, which I'm sure it's hard to take.

One big library with a marketing engine behind it is still a great flagship for the server-side Swift community, and benefits everyone.

If this library has good Swift coding standards and allows freedom for the community, I couldn't agree more.

bullied and finger-waggled in SwiftX in particular rather than welcomed

I'm sorry we came down so hard. But it's simply what we think. You guys are more than welcome to join efforts in SwiftX. I really wish we didn't have this harsh view of you guys. But again this is all a product of your actions. If you guys are really willing to go for it. We're here.

[tanner0101]

I have to honestly ask, by your line of reasoning: when will PHP be ready for prime-time?

Lol. True.

A rising tide lifts all ships. Wouldn't you rather have a marketing machine on your side, pushing for the adoption of server-side Swift from every angle?

Yes, definitely. But there's a difference between pushing for adoption and scaring people away.

I'm not sure where we are leaving people with a bad taste in their mouths about Swift

If you want me to send you some of the (unfortunately many) complaints I've gotten in my Slack channel about Perfect, I can. But I don't know if that would be constructive. I'm not trying to make you feel bad about the work you're doing. It takes courage to post your work online for everyone to look at, and I respect that. There's really no wrong that can be done by contributing to the OSS community. I just wanted to help you see how I have seen developers responding to Perfect.

[ghost]

The conversation has kind of moved beyond the original question, which is how Perfect could be more "Swifty".

It's an option to start new threads around the topics that have emerged in the discussion (don't get me wrong, they have been insightful), but keeping to this particular thread, I'm curious to understand if there are other things we should consider, in order to make Perfect "Swiftier".

So bringing it back, this is what I've noted:

• Swift Package Manager support
• Modularity
• Composition (protocol with extensions, final attribute used by default)
• Functional code (use of higher-order functions)
• Primarily value types (struct over class where possible)
• Immutability (let by default, var only if necessary)
• Flexible library
• Thinner layer between web and developer's own code
• Get rid of unnecessary C dependencies and compile required C dependencies with Swift
• Align to Swift guidelines for developing APIs

There's value in having a "starter kit" for those beginning in Perfect. And we'll take a deeper look into SwiftX too.

Anything else come to mind?

[SeanStephens]

In addition to the initial question of "Swiftiness", this has been an inspirational thread. One of the most incredible parts of this is the various individuals who came to the table for discussion;

Lead contributors of some of the most "starred" server-side frameworks on GitHub;

Perfect (@kjessup, @seanstephens, @LucasC53) Vapor (@tannernelson) Zewo (@paulofaria, @Danappelxx) Taylor (@Danappelxx) MongoKitten (@Joannis)

I did take away some incredibly helpful points from this thread that we will address ASAP.

Perfect isn't, yet (Nobody is, yet) We have an opportunity to clean up much of the Perfect codebase to be more "Swifty", and more modular. As most of Perfect was written before Swift open-sourced, this was somewhat inevitable. (We've been working on this for weeks, so suddenly we feel like geniuses). Onwards to glory! Swiftiness incoming.

Companies give developers the Jitters We are a company, not of thousands, but of a few (a micro-community within the community). It's just a piece of paper indicating that a few of us are working together, in the same office, at the same time, on the same project. We are born from the union of an agency that loves people (Treefrog Inc.) and a server-side language from Apple (LassoSoft Inc.), who together have a reputation for being amazing companies. Treefrog is predicated on community, people, environmental awareness - and lastly, profit. It is not a scary place, it's progressive and awesome. PerfectlySoft comes from this, it lives in this. We are not Big Blue, we are Little Orange, inside green and blue.

Our Marketing is Aggressive Sorry about that guys, but not really. Our aggressive marketing will bring interest and passion from other communities and drive people to appreciate your work and be part of our new and emerging community. Think of us as your greatest asset, not a stain. Help us get better and be better, don't just point and cluck your tongues. We are not trying to take over the Swift community. We are trying to take over the world of alternate platform server-side development, on the Swift community's behalf. Our constant streams of horrendous orange logos are going to ultimately increase your salary. (We didn't pick the orange, Apple did). Our own project not sucking is key to this, too.

We should Standardize, together This is one genius idea we hadn't considered before. Of course we will join you guys, and work towards interoperability and compatibility and community standards. (Though as a marketing guy, I hate the name SwiftX, sorry... troll). In the short term, we've stopped calling ourselves "enterprise-grade", by your request. We had previously removed "One Language to Rule them All" because a Java developer got really, really cranky about it. Whatever, we'll add those comments back in later, once we've proven the point. It's not that I don't believe the points myself, but rather that we aren't here to detract from the real goal: world-wide Swift domination. ;)

I have two final things to say, that I feel need not to be missed in this crazy thread.

One, this appears to be the first and largest gathering of minds in server-side Swift's history, the most stars in one place. This, this thread here, is the thread people will talk about in many years to come, where everyone got together and butted heads, out of which came the future of SSS programming. You people are the leaders of this new community. I appreciate that people have strong opinions, and want to piss on the fat kid and talk about "Slack channel complaints", but it's not helpful to the larger Swift vision. If we are to work together, we can't start off acting like the Perl community. We have to lead not just in developer genius, but also collaborative genius. We have crushed any negative comments about any of you in any of our channels - you won't find any, and we don't support the idea of poking at one another. In other words: you guys are the leaders of this new world order, with us in tow. Act like it. :)

Two, we are going to continue our work with Perfect until it is. We are not slowing down or going away or nerfing anything we do - improve, yes, sleep, no. If you are interested in helping us (while we help you), we'd love to work together. In fact - if you are interested - we are looking for individuals interested in working full time on our server side Swift libraries to improve them. THIS is why we have a company. Want to get paid for your Swift community contributions, either as a full time salaried developer or as a contractor? Lots of people do, including the creators of Swift itself. Contact me off list, and let's chat. Programmers have a right to eat, too. This is the future, and we are going to be integral to it - we have all of the trappings in place. Come play in our sandbox. Let's work together.

And lastly, I would say - I'd love to personally be connected with any and all of you. My lines are open, I/we are not a closed box - in fact, I'm quite open and transparent, all the time. Here's my personal info, I'd love to hear from you any time - you don't all have to wait to gang up on us at once, hehe;

sean@perfect.org CEO, PerfectlySoft Inc., Treefrog Inc. and LassoSoft Inc. http://lnkd.in/QM5j5b http://www.treefrog.ca/sean-stephens 905-836-4442 x109 https://twitter.com/treefrogCEO

We'll be working away for a while to clean up our act (based on your input), and then we'll join you at the standards party. Happy coding!

[SeanStephens]

Nobody sends birthday invitations any more. ;)

Methinks the project could use some better marketing, if it is to be inclusionary.

EDIT: Where might one find such a Slack channel?

[tanner0101]

@SeanStephens It looks like the poor free Heroku instance powering the Slack inviter is exhausted (http://slack.swiftx.io). An invite has been sent to your email.