alexozun.com
Staff iOS Engineer | https://swiftology.io
Based in 🇬🇧 Born in 🇺🇦
All opinions are my own
156 posts
859 followers
859 following
Regular Contributor
Active Commenter
comment in response to
post
This is the second time I’ve seen @alexozun.com’s talk on making invalid state impossible and it’s a really cool approach to improved software safety!
comment in response to
post
How smooth is your learning curve?
comment in response to
post
Hey 👋 enjoy ☺️
comment in response to
post
Next up: @alexozun.com on how to make invalid states impossible in your app.
comment in response to
post
Same with dictionaries.
[Key: Value] or [Key : Value]
comment in response to
post
Thanks! I'll share the recording when it's published on YouTube
comment in response to
post
Thank you Peter! And thanks again for borrowing your clicker (I'd already added it to my Bday wish list 😀)
comment in response to
post
I think I managed to successfully trick the audience into thinking we were simply describing effects with enums, until finally revealing that we’d actually learned something that *supposedly* requires a PhD in Computer Science to understand (spoiler: it really doesn’t!).
comment in response to
post
Haha, thank you Oliver 🙌 see you next week in Turin!
comment in response to
post
I am, of course, just bastardising the
en.m.wikipedia.org/wiki/Fundame...
comment in response to
post
@dustyn thank you, I'm pretty sure they will be! And I'll make sure to repost them on social media and my blog
comment in response to
post
Heading into 2025 with 3 brand-new talks is kinda crazy, but I'm feeling good about this decision.
I'm excited to share these talks with the community later this year!
If you'll be at any of these conferences, drop me a message.
comment in response to
post
I primarily draw info from Scala community that has a wealth of info on effect systems. Swift and Scala are closely positioned in this field, both being capable FP langs with expressive type systems, and both being impure, requiring good effect systems and disciplines to control side effects.
comment in response to
post
My article is almost finished and it goes into great detail on various effect systems in Swift, including monadic effects and effect descriptors. I go from first principles, how continuation-passing style gives rise to unidirectional architectures, and how we could possible go back to direct style.
comment in response to
post
There's precious little info on effect systems in Swift community 😔 the largest resource on monadic effects is @pointfree.co and TCA that makes great use of them. Our own architecture at Amex uses effect descriptors, but it's not OSS. The Elm Architecture is the closest resource I know on that.
comment in response to
post
Hey Francisco 👋 I'm really glad you liked it and thank you for your feedback 🙌
comment in response to
post
I've been using giscus.app for swiftology.io and I think it's a perfect solution for a tech blog since you can expect most of your readers to have GitHub accounts.
comment in response to
post
Ah, that's interesting. Yeah, I don't use medium at all, so didn't notice this trend.
I might give this title another thought, but I'm really bad at coming up with good titles 😅
comment in response to
post
Seriously? I didn't know that, can you elaborate? I was mostly echoing various WWDC talks with a similar title formula.
comment in response to
post
I'm committed to maintaining a high quality bar for my public talks, which means I have dozens of evening hours in Keynote ahead.
Once the conferences make their official announcements, I'll make another post with all places and dates.
comment in response to
post
Thank you 🙏
comment in response to
post
That's why I love Amex (a totally unbiased opinion 😛) for its legendary customer support, and why I generally avoid app-based neo banks that work until they don't, and then leave you in a limbo.
comment in response to
post
But if I'm having issues, like a payment not coming through when I'm travelling abroad, I want to speak to a person on a phone until my issue is resolved in real time.
comment in response to
post
"...I also think WWDC should be a worldwide event. We should be able to have a fantastic WWDC in London."
💯 it's literally in the name! I've never been to an in-person WWDC event, partially because it's just so freaking far away that I feel excluded.
comment in response to
post
13 hours in the air+3-hour delay due to brake replacement. Totally worth it.
comment in response to
post
comment in response to
post
Yes, it's an essential tool for me. And not only for that, but also to create functional interfaces and draft data transformation pipelines. I always start with function/closure bodies as fatalErrors inside and fill them in one at a time. This might help:
matt.diephouse.com/2017/05/type...
comment in response to
post
I always recommend replacing function/closure bodies with fatalError() to preserve the original type information.
comment in response to
post
Correct. get() is a function on Result type that either returns an unwrapped value or throws an error. Essentially, a way to convert between Result and throwing.
comment in response to
post
I think your assertions can be improved slightly:
1. For success just do: _ = try response.validate().get()
If validation throws, the error will be reported by the test func itself since it's throwing.
2. For failure, use let error = #expect(throws: MyError.self) { try response.validate.get() } API
comment in response to
post
Totally, I never had a need for variance in generic types, this popped up pretty randomly when I was researching Kotlin. I think we just don't have idiomatic Swift coding patterns that require variance.
comment in response to
post
As you can see on the screenshot, I have a unit test where I step through the whole program top-to-bottom and validate every action and a corresponding output.
This is still just a giant hack, but it works in principle. I think I'm onto something here...I'll share more details later.
comment in response to
post
Update: a Swift compiler engineer confirmed that it's a compiler magic for a select number of stdlib types: queer.party/@beccadax/11...