[HN Gopher] Swift AWS Lambda Runtime
___________________________________________________________________
Swift AWS Lambda Runtime
Author : NobodyNada
Score : 118 points
Date : 2020-05-29 17:02 UTC (5 hours ago)
(HTM) web link (swift.org)
(TXT) w3m dump (swift.org)
| mrtksn wrote:
| That's great news. For some reason cloud function run extremely
| slowly for me on Firebase. Like a few seconds slow on the first
| call if not called frequently, then it drops to milliseconds
| level.
| WrtCdEvrydy wrote:
| Yeah, this is called a 'startup effect' in most cloud function
| environments. Lambda has a thing called 'prewarming' which
| basically hits it every 15ish seconds to make sure it's still
| active...
| mrtksn wrote:
| I am considering to implement something like that by myself.
| It's not an acceptable performance otherwise. Alternatively I
| am looking into running it on different tech, I would have
| moved already on Swift on Linux if Fireplace had a library
| for Swift beyond iOS.
| gnulinux wrote:
| Does it really sleep in 15 seconds such that it needs to warm
| up? Why call it every 15 seconds? Why not every hour, every
| day? Is there a documentation how often it needs a warm-up?
| asadlionpk wrote:
| That's by design. Your server 'sleeps' and
|
| - wakes up on for a request(few seconds delay on request),
|
| - stays awake (requests are fast here),
|
| - goes back to sleeping if idle for sometime (15mins?)
|
| This is what keeps the costs low (or free). Same is true for
| Heroku, Lambda, Vercel, Azure Functions, etc.
| mrtksn wrote:
| Sure but it is not an acceptable level of latency when the
| product is supposed to respond on user input. When the app or
| the feature is new or obscure it would fall in this state all
| the time.
|
| Last time I checked I wasn't renting a server, it was
| supposed to be a service that's fast at any scale.
|
| A 5$ DO instance would provide much better experience. They
| should give an option to keep it awake albeit at a cost.
| oldmanhorton wrote:
| Azure functions has that option, but at some point... Why
| not just use a "real" web server if you want it always
| online? The whole point of serverless was that you don't
| need a server always running in the background.
| ncw96 wrote:
| Lambda also provides this functionality -- they call it
| "provisioned concurrency": https://docs.aws.amazon.com/la
| mbda/latest/dg/configuration-c...
| mrtksn wrote:
| I don't want to deal with it until it's worth dealing
| with it. That is, until the cost of managing a server and
| it's integration is less than the cost of using
| Firebase(which comes with free integration and no
| management needs).
| asadlionpk wrote:
| The easiest way around it is to keep ping-ing it every 5
| mins from either from a third party (like pingdom,
| uptimerobot.com) or a cron function
| (https://cloud.google.com/scheduler/docs/creating).
|
| But I would recommend using Cloud Run instead.
| soamv wrote:
| Isn't Cloud Run's cold start latency even worse?
| asadlionpk wrote:
| Actually you are right. I was under the impression that
| we can define minimum-maximum instances to run. But
| apparently it scales down to zero and there is no way to
| prevent that.
| jtdev wrote:
| All of the closure obsession in Swift is extremely off-putting to
| me.
| magnetic wrote:
| Can you elaborate?
| jtdev wrote:
| Closures everywhere... why? They make code difficult to
| reason about and read and only seem to satisfy the FP
| zealots.
| saagarjha wrote:
| You don't have to be a functional programming zealot to be
| able to recognize the value of not having to define a
| function just so you can sort a list using a different
| predicate.
| avolcano wrote:
| Is there any recent rundown on the state of server-side Swift in
| general? I know there was a lot of discussion when IBM stopped
| working on it back in January.
|
| At the broadest level, I wonder what the footprint of Swift at
| runtime is, both in terms of CPU and RAM. I've been really
| enjoying Kotlin as a server-side language - it's a massive step
| up in productivity from TypeScript - but the overhead of the JVM
| certainly is notable, even in small personal projects (my small
| Javalin app uses four times the RAM at rest as my Express app
| did). Swift is really interesting to me because it is very
| similar in practice to Kotlin, but with some very cool and
| powerful additional language features. So, if server-side Swift
| has a smaller footprint at runtime and equal or better
| performance than Kotlin on the JVM[1], that'd be a really
| compelling language for me.
|
| [1] yes, I know GraalVM/native options exist for Kotlin, but
| every time I've tried to investigate ecosystem compatibility, it
| leads to me glancing at pages long-articles about "how to
| configure X framework for GraalVM" that make it not seem worth
| the effort yet
| albertop wrote:
| This one is very interesting and unexpected. Swift for
| TensorFlow: The Next-Generation Machine Learning Framework:
| https://www.youtube.com/watch?v=s65BigoMV_I
| sdkjfhskjfh wrote:
| > my small Javalin app uses four times the RAM at rest as my
| Express app did
|
| Are you looking at used heap space or just the amount of memory
| used by the Java process? I have a few small Java services
| using vert.x and they hover around 7-15 MB of used heap space.
| For small services I usually just restrict the maximum heap
| space size because the default is unnecessarily large.
| akmarinov wrote:
| Here's a quick summary of things -
| https://www.timc.dev/posts/future-of-server-side-swift
| oflannabhra wrote:
| Probably one of the best, recent overviews of Swift on the
| server is by Tim Condon [0]. TLDR: nightly Docker images of
| Swift, shared libs (Swift Crypto an example), more Linux
| distros supported, Amazon's 2.0 release of Smoke [1] (which is
| probably involved in this runtime), all indicate that Swift's
| future on the server is probably bright, even if it is still
| early.
|
| [0] - https://www.timc.dev/posts/future-of-server-side-swift
|
| [1] - https://github.com/amzn/smoke-framework
| technics256 wrote:
| What about Kotlin make it a step above typescript in terms of
| productivity?
| avolcano wrote:
| This is a blog post I've been putting off writing for a
| while; I'll try to tl;dr it best I can given it's somewhat
| off-topic:
|
| * TypeScript's lack of runtime types and stable reflection
| APIs make it hard to have any guarantees of type soundness
| without either code generation (e.g. schemats) or complex
| type programming to convert a runtime representation of a
| type to a static type (e.g. io-ts). I find this very
| frustrating when doing web backend programming, where you are
| constantly doing i/o with external services (whether HTTP
| APIs, or input from client requests, or database
| interaction).
|
| This is particularly maddening because there's no de facto
| standards (seriously, there are a lot of these libraries:
| https://github.com/moltar/typescript-runtime-type-
| benchmarks), so it's not easy to e.g. find a DB library that
| will let you define an io-ts schema that a query should match
| without re-wrapping things yourself.
|
| Basically: if TypeScript had runtime types, and an `as` cast
| threw an exception when a value doesn't match the specified
| type, I'd be much more inclined to keep using it. I genuinely
| think that's table stakes for a type safe language.
|
| (and lest you think this _has_ to be how TS works given the
| nature of how it 's compiled to vanilla JS, I suggest you
| take a peek at Sorbet, which knew this was necessary:
| https://sorbet.org/docs/runtime)
|
| * The TS ecosystem is generally underwhelming. I don't think
| any HTTP framework for it is particularly good, nor any
| ORM/query builder. I think there are a lot of really neat
| experiments still happening in this space, and it seems like
| every day GitHub's little "explore repositories" sidebar
| shows me another cool library someone's built for TS trying
| to solve some of these problems, but it's all early stage
| stuff with a bus factor of 1 and a long todo list.
|
| To be fair, _Kotlin's_ ecosystem actually has a lot of these
| problems; the semi-official Jetbrains-maintained Kotlin web
| framework and DB access library both have a ton of untriaged
| issues and seemingly little production use. The good news is,
| at least on the server, you can completely ignore the
| "Kotlin" ecosystem in favor of the Java ecosystem, and this
| is _shockingly_ effective. Just about every JVM framework
| I've seen has some kind of officially-maintained Kotlin
| adapter, presumedly because it's not hard to sell Java
| developers on "what if you could keep using the exact same
| tools with a nicer language." These adapters aren't even
| needed, mind you, they just provide nicer APIs that can use
| Kotlin language features. Javalin + JDBI is infinitely nicer
| out of the box than trying to turn Express and Knex into a
| production-ready API with anything approaching type safety.
|
| * This isn't a make-or-break thing, but Kotlin is just
| generally _nicer_ than JS or TS in a lot of ways, while still
| having a very similar programming style. For example, the
| collection types are far more robust than something like
| Lodash (let alone the absolute joke that is the ES6 Map/Set
| API).
| colinmorelli wrote:
| I actually went back and forth with these exact same
| options recently. To the extent any of this is helpful:
|
| * Agreed with the problem, although I've found io-ts to be
| great. For incoming client requests: GraphQL is helpful if
| you're using that, but it's also relatively trivial to
| create an io-ts middleware for express that will get you
| similar guarantees. For database interaction, assuming
| you're talking about relational data stores, this is a
| challenge. Personally, I'm using Mikro ORM and it has been
| great so far. The one blessing here is that you're probably
| not dealing with unknown data types when talking to a data
| store, so it hasn't felt like as much of a concerning
| surface area for me personally. HTTP is valid, but I
| actually like io-ts as an approach here possibly more than
| using Jackson with static types due to its failure model -
| but again I acknowledge this is a personal choice.
|
| * I guess it depends on your needs here, but base express
| can be great for simple apps, and NestJS is fantastic for
| more complex ones. You're 100% on point with ORMs, though,
| where I've been incredibly dissatisfied generally. As
| mentioned above, I've recently stumbled on Mikro ORM which
| takes a unit of work pattern similar to Hibernate, without
| the painful startup time. You can tell it's not perfect,
| and certainly not as feature rich as Hibernate, but also
| feels safe enough. I imagine if you tried to do everything
| through the ORM it could get painful, but most of my apps
| are structured as multiple modules where each module only
| controls the entities within that module. It keeps the
| reach of the ORM limited and abstracted behind "services"
| (in the modular monolith sense, not remote services).
|
| * Yeah I see both ends of this one. Historically been a JVM
| user and have a ton of appreciation for it, but also like
| TS's approach more than Kotlin in several ways. You're
| right about collections though, ES6 is a joke there.
| _31 wrote:
| Always happy to see more new Swift projects pop up, especially on
| the server side. It's great watching the language evolve and
| continue to add more powerful features.
| dzonga wrote:
| swift is a nice language. however, don't do the mistake of
| developing server side applications on it. tried it, after
| drinking the ibm, vapor kool-aid in 2016ish. the community though
| friendly is weak. still to well known stacks if you're going to
| be doing server side stuff
| rubyn00bie wrote:
| Chalk one up for time wasted not addressing what people really
| need...
|
| I truly love Swift, like god-damn is it my cup of tea, but I
| can't really bring myself to write it anymore. I've written over
| 10,000+ lines , shipped and maintained a few different production
| apps, but anymore I just have no urge to write it.
|
| And the biggest reason why? I think it being open source is a
| joke until Apple, and I mean Apple themselves, implements some
| sort of cross-platform UI framework with it. Like, most of what
| is written in Swift is fucking UI code that's totally useless on
| other platforms.
|
| I think it's pretty laughable I can run Swift on AWS but I can't
| do a simple GUI app on Linux or Windows using the OOB Swift SDK.
| Apple, you're a fucking trillion dollar organization, for fucks
| sake stop being so damn stingy with portability.
|
| When I can write cross-platform GUI apps with Swift, maybe I'll
| give a fuck 'bout running it on a server. Just my two very
| bitter, hurt, and sad two cents...
| jmull wrote:
| A good, modern, general purpose cross-platform GUI application
| framework is a very different proposition than server-side
| Swift. It's also a very, very tall order that would require a
| lot of resources to create and a lot more to maintain... and I
| don't see big strategic benefits to Apple in doing so.
|
| I don't think it's going to happen.
|
| Maybe WASM will lead to browser-side Swift and then you can do
| Electron-style cross platform apps using web technologies. (Not
| that I think Apple would put resources to that either.)
| madeofpalk wrote:
| I just don't think that's where Apple's priorities are for
| swift. They want a modern language for their platform first and
| foremost, and then secondly if they developers can write server
| components for their apps in Swift, then that's good as well.
| cglong wrote:
| I wonder if they're hoping people that choose Swift as their
| first programming language will experience "vendor lock-in"
| and will be disinclined from branching out to other platforms
| that don't support Swift. This would make sense given the
| Swift Playgrounds initiative.
| tasogare wrote:
| Microsoft ignored the same exact point (official multiple UI)
| for C# for years, despite having it at some point (Silverlight
| out of browser). So I can totally understand what you are
| expressing there, yet I think there are even less chance Apple
| act on and provide such framework in the future.
| happybuy wrote:
| This is a great and very useful addition to the Swift ecosystem.
|
| Currently develop a very popular iOS/macOS app in Swift which
| talks to an AWS Lambda backend written in Node.js. This has
| required some model code to have dual Swift and Node versions. If
| the Swift AWS Lambda Runtime was available previously this
| wouldn't be necessary.
|
| I'd say a lot of developers in the Apple eco-system would be in a
| similar situation and this runtime can help to streamline a lot
| of client-server approaches.
| mikece wrote:
| If you have tons of Swift code that needs to run in watchOS, iOS,
| iPadOS AND the cloud, this would kinda make sense... but how
| frequently is that the case? When I was still doing mobile the
| goal was to write as LITTLE client-side code as possible and put
| as much logic/heavy lifting on the API side as possible because
| we can make changes there far quicker than in the native client.
| And almost all of the client-side code was about GET/POSTing to
| the API or interacting with the SDK to draw things on the screen
| -- almost no business logic. That said, I didn't work much on
| apps that were supposed to work without a data connection for
| long periods of time... in that case it's more likely you'll run
| into scenarios where you're writing business logic in the app (in
| Swift/ObjC) but even then the goal was to keep that kind of code
| to a minimum (or less).
| jmull wrote:
| Swift is a nice language in its own right, and, according to
| the post, is a good fit for the lambda environments.
|
| So there doesn't need to be a direct connection to iOS to
| decide to use Swift for serverless function. A developer might
| just decide to use Swift for serverless functions.
|
| (I can see the benefit to sharing certain kinds of code between
| client and server, but a lot of things have to line of for this
| to make sense, so I'm not sure if that's a significant driver.)
| CalmStorm wrote:
| Swift does not allow null pointer, and therefore there is no
| null pointer exception. This is a very nice feature,
| especially compared with other server-side compiled languages
| like Golang and Java. Swift is modern and concise, I hope it
| takes off on server-side.
| akmarinov wrote:
| Well you can always force unwrap and shoot yourself in the
| foot
| phaedryx wrote:
| I can think of a few scenarios off of the top of my head:
|
| App sends an event, Lambda sorts it into queue(s) for
| processing
|
| App wants to know if its data is stale, asks Lambda
|
| I think there is a niche for small, quick processing. Why write
| it in Node or whatever if your devs already know Swift?
| Eric_WVGG wrote:
| Apple's goal for Swift is to be "the new default language for
| computer science." They see it as supplanting Java.
|
| Whether you think that's crazy or not, pure server Swift is a
| thing, personally I love it. https://vapor.codes
___________________________________________________________________
(page generated 2020-05-29 23:00 UTC)