Perl vs Swift: What are the differences?
Perl: Highly capable, feature-rich programming language with over 26 years of development. Perl is a general-purpose programming language originally developed for text manipulation and now used for a wide range of tasks including system administration, web development, network programming, GUI development, and more; Swift: An innovative new programming language for Cocoa and Cocoa Touch. Writing code is interactive and fun, the syntax is concise yet expressive, and apps run lightning-fast. Swift is ready for your next iOS and OS X project — or for addition into your current app — because Swift code works side-by-side with Objective-C.
Perl and Swift can be primarily classified as "Languages" tools.
"Lots of libraries", "Open source" and "Text processing" are the key factors why developers consider Perl; whereas "Ios", "Elegant" and "Not Objective-C" are the primary reasons why Swift is favored.
Perl and Swift are both open source tools. Swift with 48.4K GitHub stars and 7.76K forks on GitHub appears to be more popular than Perl with 435 GitHub stars and 152 GitHub forks.
According to the StackShare community, Swift has a broader approval, being mentioned in 993 company stacks & 541 developers stacks; compared to Perl, which is listed in 133 company stacks and 64 developer stacks.
What is Perl?
What is Swift?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Swift?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
By mid-2015, around the time of the Series E, the Digital department at WeWork had grown to more than 40 people to support the company’s growing product needs.
By then, they’d migrated the main website off of WordPress to Ruby on Rails, and a combination React, Angular, and jQuery, though there were efforts to move entirely to React for the front-end.
The backend was structured around a microservices architecture built partially in Node.js, along with a combination of Ruby, Python, Bash, and Go. Swift/Objective-C and Java powered the mobile apps.
These technologies power the listings on the website, as well as various internal tools, like community manager dashboards as well as RFID hardware for access management.
At the heart of Uber’s mobile app development are four primary apps: Android rider, Android driver, iOS rider, and iOS driver. Android developers build in Java, iOS in Objective C and Swift. Engineers across both platforms land code into a monolithic code base that ships each week.
They use some third-party libraries, but often build their own, since “Many open source libraries available are general-purpose, which can create binary bloat. For mobile engineering, every kilobyte matters.”
On Android, the build system is Gradle. For the UI, Butter Knife binds views and callbacks to fields and methods via annotation processing, and Picasso provides image loading.
As for iOS, all of the code lives in a monorepo built with Buck. For crash detection, KSCrash reports crashes to the internal reporting framework.
In addition to our fancy Docker setup, we have captured and sanitized production logs for the behavior of our legacy Perl MTA, and we can test that the log output from the new Go version behaves the same way as the old version. These tests are set up to allow us to switch between the legacy and new version of the MTA and ensure that both systems behave in a legacy-compatible way. Not only can we ensure that we operate against a variety of issues we've seen over time from inboxes, but we know that the newest version of our MTA continues to cover all the same expected behaviors of the legacy version. #CodeCollaborationVersionControl #ContinuousIntegration