Vapor VS swift

Botter works in tandem with Vapor, which handles the server-side functions of your project. This powerful combination allows you to focus on what matters most - creating an engaging and effective chatbot.

// swift-tools-version: 5.8 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: "MyServer", platforms: [.macOS("12.0")], products: [ // Products define the executables and libraries a package produces, and make them visible to other packages. .executable( name: "MyServer", targets: ["MyServer"]), ], dependencies: [ .package(url: "https://github.com/vapor/vapor.git", .upToNextMajor(from: "4.70.0")), // Dependencies declare other packages that this package depends on. // .package(url: /* package url */, from: "1.0.0"), ], targets: [ // Targets are the basic building blocks of a package. A target can define a module or a test suite. // Targets can depend on other targets in this package, and on products in packages this package depends on. .executableTarget( name: "MyServer", dependencies: [ .product(name: "Vapor", package: "vapor") ]), .testTarget( name: "MyServerTests", dependencies: ["MyServer"]), ] )

Otherwise there's https://github.com/vapor/vapor

The Swift/Vapor project is a relatively easy way to do it.

Opening this webpage (https://vapor.codes) cranks my CPU (5800x3d) to 100% instantly. Why?

Vapor is the most popular non-Apple-ecosystem Swift project. There have been a few others, but none particularly popular.

Server-side apps (typically via Vapor)

My first option other than PHP was using Swift and Vapor. I have made some projects with iOS and Objective-C, maybe I could also learn Swift and create both native iOS apps and backends with the same language.

StreamCam is written 100% in Swift, SwiftUI & Combine. The serverside is handled with Vapor.

I remember several years ago when differentiable programming was an object of interest to the programming community and Lattner was trying to make Swift for Tensorflow happen[1].

I'm of the opinion that it was ahead of its time: Swift hadn't (and still hasn't) made enough progress on Linux support for it to be taken seriously as a language for writing anything that isn't associated with Apple. However, as a result, Swift now has language-level differentiability in its compiler. I'd love to see Swift get used for projects like this, but I suppose the reality of the matter is that there are so many performant runtimes for 2D/3D physics that there just isn't much of a need for automatic differentiation (and its overhead) to solve these problems. The tooling nerd in me thinks this stuff is fascinating.

https://github.com/tensorflow/swift

there was a time when google attempted to integrate swift with tensorflow, but the project was abandoned, and the repo is archived now. I believe the swift community picked up some of the features, and they are still working on it.

Apple really is focusing on CoreML rather than differentiable swift, that was more of the vision of Swift4TF, which really was driven mostly by Google, until it was cancelled (I assume because of Chris Latner leaving google for SiFive): https://github.com/tensorflow/swift

to be fair, Swift for Tensorflow was dropped (Feb 21) way after this article was written (Aug 20) https://github.com/tensorflow/swift

Neat! This may have not been well known when they kicked off the project and wrote their reasoning. Here is what they had to say about Scala at the time of the document linked up-thread[0]:

"Java / C# / Scala (and other OOP languages with pervasive dynamic dispatch): These languages share most of the static analysis problems as Python: their primary abstraction features (classes and interfaces) are built on highly dynamic constructs, which means that static analysis of Tensor operations depends on "best effort" techniques like alias analysis and class hierarchy analysis. Further, because they are pervasively reference-based, it is difficult to reliably disambiguate pointer aliases."

If they were wrong about that, or if the state of the art has progressed in the meantime, that's great! You may well be right that Scala would be a good / the best choice if they started the project today.

[0]: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...

It was not in the README