Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Multiplatform Maps Built As Layers on Rust (with Ian Wagner)
3k Plays3 months ago
Mapping is a hugely complex task to take on. Even if you moved as much of the data-management as you can out to 3rd-party services, you’d still have a tonne of work to do weaving together map tiles, routing information, GPS data, points of interest, search and more. And as if that wasn’t enough, you’d probably want that software to work on a whole range of platforms, so you have to build something that works on iOS, Android and more. It’s little wonder that the space is dominated by a few closed-source projects owned by huge companies with near-limitless resources.
But that doesn’t mean the problem can’t be cracked as an open-source project. This week we look at the open source map library Ferrostar. Joining me to discuss it is the project’s lead developer, Ian Wagner, as we explore the problem space and dive down into Ferrostar’s architecture: A core Rust library serving a suite of custom UI shells written in Kotlin, Swift, WASM and TypeScript.
Along the way there are tips for anyone attempting to build a map, or wanting to interop Rust with other languages.
–
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
Ferrostar on Github: https://github.com/stadiamaps/ferrostar
Ferrostar user guide: https://stadiamaps.github.io/ferrostar/
MapLibre: https://maplibre.org/
Project OSRM: https://project-osrm.org/
Dioxus (Rust UI framework): https://dioxuslabs.com/
Slint: https://slint.dev/
UniFFI (repo): https://github.com/mozilla/uniffi-rs
UniFFI (user guide): https://mozilla.github.io/uniffi-rs/latest/
Beeline (navigation device): https://beeline.co/
Ian on Mastodon: https://fosstodon.org/@ianthetechie
Ian on Twitter: https://x.com/ianthetechie
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Twitter: https://twitter.com/krisajenkins
Recommended
Transcript
The Marvel of Mapping Software
00:00:00
Speaker
I think mapping software is one of the best things we've ever done as a software industry and possibly as an entire species. Before I go too far, I'll qualify that. Obviously the software that took us to the moon, the software that's running in my father-in-law's pacemaker, obviously that's like top tier software.
00:00:21
Speaker
But just below that, maps that tell you where you are and where you're going. That's magic. I want to show one of those to a 15th century navigator. It would blow their minds, obviously. And as well as being magical, it's like really, really useful. Obviously, the stress that's been removed from everyday life. The sense of discovery. I can find a new place in my city and not worry at all about actually being able to find it.
00:00:49
Speaker
They're brilliant. Magic. Magic software. So
Ian Wagner's Open-Source Mapping Project
00:00:52
Speaker
when this week's guest, Ian Wagner, contacted me to talk about an open source mapping library he's been working on, I thought, obviously interesting problem. Obviously valuable software. Let's talk.
00:01:05
Speaker
and then I started to think about how difficult it actually must be to put this together because it's a deep problem right you've got to take mapping information and location tracking route planning and search and database of interesting points along the way. And then you multiply that by the fact that it's a wide problem we don't expect maps to just exist in one place we want them on the web and on ios and android and every place that we might find ourselves lost.
00:01:35
Speaker
So
Challenges in Mapping Solutions Development
00:01:36
Speaker
it's kind of a hard problem squared of engineering. How do you do it? Well, Ian's answer is a Rust core with native shells around it. But that's too brief a summary. For the real answer, we have to get into the engineering. So let's do that. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Ian Wagner.
00:02:11
Speaker
I'm joined today by Ian Wagner. Ian, how are you doing? Fantastic, Chris. How about you? I'm very well, I'm very well. You're coming from an interesting place I don't often get guests from, right?
Tech Scene in South Korea: Ian's Experience
00:02:22
Speaker
Yeah, I'm ah in South Korea. I've lived here for about seven years now. um Yeah, really, um yeah, under the radar place, not a lot of people come here to visit. But yeah, it's a really awesome place to live. My wife's Korean, which is how I ended up here.
00:02:37
Speaker
and i What's it like for technology or does it not matter because of remote working? Well, yeah, I mean, I've been a remote worker for like 15 years now, so. um it's a I mean, there is a tech scene. um There's actually quite a lot of remote workers and it's becoming more of a popular spot for digital nomads. There's a group of um between five and 10, depending on the week, that will show up at a cafe for co-working sessions. So there's ah there's definitely a lot of um location independent tech workers here. And then the Korean companies are also starting to scale up like Coupang, for example. They're hiring like a lot of people doing machine learning, data science, that kind of thing. so
00:03:16
Speaker
There is definitely a tech scene here. it's not It's not quite like the U.S., but um it's ah it's definitely growing. That always depends on where in the U.S. you are. Fair enough, yeah yeah. Fair enough. One thing I've learned, the United States is not really one place, it's lots of places. Yeah, where I grew up in ah in Pennsylvania, then yeah there was not very much tech happening there either.
00:03:40
Speaker
Don't believe. Anyway, we are we're not here to talk about travel, but we are kind of here to talk about travel.
Introducing Ferris Star: A Navigation Tool
00:03:47
Speaker
Ferris Star, right? For navigation. Tell me what Ferris Star is, and particularly what it isn't, because it has an interesting boundary we need to talk about.
00:03:57
Speaker
Talking about light travel and navigation, um you probably use Google Maps or Apple or something like that on your on your phone all the time. obviously When you pull it out, then one of the first things it does is it tries to figure out what your location is, like latitude and longitude.
00:04:12
Speaker
and then you've got a search box, you figure out, um ah maybe you type in an address, maybe you type in the name of a restaurant that you want to go to, and then you select that, and then somewhere or off, somewhere a computer figures out how do we get between these coordinates and those coordinates.
00:04:29
Speaker
um Now, that's a process called routing, and there's a whole bunch of really great open source software that I think we'll probably end up talking about a little bit throughout the podcast. um so that ah That domain is called routing, and then navigation, which is what we're focusing on with FeroStar, is how do you take that routing information and guide the user through the route? so When you start walking down the the street, you get to the end of the block and it says,
00:04:57
Speaker
um turn right and then in 50 meters the destination is on your left. um That whole kind of user experience of a user, usually on a phone but um not limited to phones, could be in dash navigation systems in cars, things like that. So that's the part that we're concerned with with FerroStar. So does does this include or exclude the actual map layer data?
00:05:21
Speaker
it doesn't um It doesn't include the data, but you kind of have to include a rendering package if you want to if you want to offer something that's useful for developers, because what we're trying to do at the end of the day is build something that's useful for developers. so Part of that is being able to display map data, and you can get that from ah from any number of vendors. My company, Stadia Maps, is one of those, but the software that we're using is called Map Libre for the map rendering.
00:05:47
Speaker
is a open source piece of software that works with um with Mapbox, with um a whole bunch of other competitors that are using that standard format. Okay. So the the chip on my phone is telling me latitude and longitude. There's a routing service that's telling me how to get from A to B and presumably step-by-step data for that. yep
Why Does Google Dominate Mapping Software?
00:06:10
Speaker
There's someone giving me map tiles yeah and Ferro star is the bit that stitches that together into an app experience. and Exactly. You nailed it. Right. Right. Okay. That,
00:06:22
Speaker
On the surface, let me deliberately ask a naive question. On the surface, that doesn't seem too hard because like Zoom levels, grid, lazy loading of tiles, that seems okay. Why is it hard? why does Why does it seem like Google have an almost monopoly on it? Ooh, a couple of things to dive into there. um One thing is,
00:06:48
Speaker
The quality of the, it is it is easy on the surface. like um Think about like um if you had like a computer science class, you may have heard of these algorithms like Dijkstra's and A*. The actual like math behind things, the algorithms behind things is not necessarily all that complicated. like That's been known for a really long time. um What is complicated though is building a complete experience that works for what the end user wants.
00:07:17
Speaker
um so like Let's talk about the different challenges that there can be. um One is on the routing side. um How do you get from A to B? is like Yes, you can just look at a graph with some weights or something. but that graph is actually going to be different. um You're actually going to have different sets of edges that you can access if you're a car, if you're a bicycle, if you're a pedestrian, um if you're a golf cart, if you're a city bus. um All of these things have um have different kinds of access restrictions. And so part of it is being able to build an app that ah that recognizes that. Because like in the Google Maps interface, for example, you're only getting like
00:07:59
Speaker
walking, cycling, car, and public transit. And which ones are actually available depends highly on the um the location that you're in. um Having a good quality road network is also really important. um So that's another area where things get really hard. um Having good business information or addresses when you're trying to do that search for the points of interest. That's another thing. And different vendors actually are different vendors, different data sources um are actually better depending on your use case.
00:08:33
Speaker
um So for example, um here is kind of well known in the industry for having extremely good data for trucking, particularly in Europe. um So maybe you want to take that and then combine it with maps from another vendor because you like their base map styling better. And maybe you want to have your own custom user experience on top of that. um So what we're trying to do is give you the building blocks in FeroStar that lets you do that um and have a really nice app experience on.
00:09:04
Speaker
all the major platforms. Okay. So it's pulling different pieces of the puzzle together in a single combined user interface. they we can get in We can get into a few different things from that. One is just the difficulty of managing several different data feeds, right? You've got several different types of people to talk to and several different um sources for each one.
00:09:31
Speaker
How many do you support? what's What's the job of supporting them? Is it like an endless nightmare of integration and integration tests? It certainly could be. um but Fortunately,
00:09:44
Speaker
the The most important parts of the stack are pretty well standardized across the industry. So map tiles I mentioned, um there's kind of two ways you can do map drawing. um One is with raster tiles, which are basically you just like download a PNG and then you say this like mosaic, this grid, and you just stitch everything together. um That's the easy way. That's how things have been done in the past. Nowadays, though,
00:10:10
Speaker
Excuse me, our expectations are a little bit higher. We expect to have this really nice, smooth zooming in. We don't want to see like you know sharp artifacts and pixelation on the fonts as you zoom in, things like that. So ah we've developed defacto tiles. um So there's a there's a there's one major industry standard called Mapbox Vector Tiles that I think is the it's the kind of defacto standard that almost everyone uses. Google has their own proprietary one, I believe. but um most of the industry is kind of standardized around Mapbox vector tiles. So this is conceptually like SVG? but Yeah, yeah' yeah yeah you could you can think of it like um SVG in the fact and the fact that it's a vector data. There's also like more rich information in there like attributes that you can actually go in and query, which is a whole ah other interesting ah rabbit trail, I'm sure as well.
00:10:59
Speaker
um So that's the um that's the quick story on the map tile side of things. so On the routing side of things, um there's also some level of standardization.
00:11:11
Speaker
um There is one of the first open source routing engines called OSRM, which I believe stands for Open Source Routing Machine. Maybe it's OpenStreetMap Routing Machine.
Using Rust for Cross-Platform Mapping Solutions
00:11:20
Speaker
ah ah um Yeah, I have to go look that one up later. OSRM though, they defined a format that is very widely understood. it's ah It's JSON and then they've basically defined a schema that everyone uses and then builds on top of to add additional things for navigation like um ah Play this ah play this thing through your text-to-speech engine when you get to this point um they've developed a standardized markup languages so you can do things like um Like the road names where I live are all in Korean um if you try running that through a
00:11:53
Speaker
um Through an English like Siri voice then it will actually there's all kinds of weird failure modes like talk about the weird edge cases like that's one of them um and this is actually still a bit of an open problem for us to solve um like how do you recognize in the in the text that like okay, this actually needs to be spoken with a Korean voice because the English voice is just gonna skip over it and So they's yeah there's all kinds of interesting edge cases on the um the user experience there. But the their response format is relatively standardized. So that's um that's not too complicated.
00:12:27
Speaker
And then I guess finally, the third thing would be on the search side. um So if you're typing in like a natural string search, like an address, um those are, I think almost every vendor has their own API for that. But it's it's basically like JSON. It doesn't really matter. So it's pretty easy to write an adapter between whatever is coming in. some ah You have some code that's like an adapter, and then it puts out some common model that then can be displayed in a user interface.
00:12:55
Speaker
Okay. Okay. So it's, I mean, it's not that wildly different from many kind of um industrial coding projects where you've got to pull in lots of data sources and spit them out. Yeah. This is not too unfamiliar to me from like working in finance, right? Yeah. Yeah, actually. um Yeah. There's actually a lot of analogies there. Yeah, for sure.
00:13:17
Speaker
The thing that makes it really different is you then um have to support this over different ah cell phones or different mobile phones. what What's the range of coverage you've got and how do you tackle that? yeah so The way that this has historically been tackled is by writing a core library that has all the business logic in C++. plus plus um and Let me define a little bit about what that business logic is. um so This would be things like, ah you can think of the whole navigation processes like a finite state machine. um You receive some kind of inputs like the user's GPS location, their compass heading, speed.
00:13:58
Speaker
um You could also have different sensors in the case of a vehicle. um So like, say you've got like, you know, wheel rotation sensors and things, and then those are trying to do some dead reckoning and figure out like, okay, well, actually the user is here now. um Taking off these days, actually looking at which direction your car's going. Yes, actually this is actually what vehicles do. um This isn't a problem we're tackling specifically, but this is actually what this actually what vehicles will do. And some of them have specialized hardware.
00:14:26
Speaker
I assumed it was all based off of Compass. you would you would ah Yeah, you you can' you can actually get pretty far with that, with um with light compass and ah Compass and Accelerometer and things like that. You can get pretty far with that. um But yeah, it can be a lot higher resolution. um And you have problems like In places like Korea, um once you go under underground, there's always electrical wiring and stuff in these underground parking garages. And your car will actually work like your GPS unit. It e even has has underground maps of the parking garages in many cases. OK. Very thorough.
00:15:02
Speaker
Okay, where where were we? We're talking about the core. yeah The core business logic. Yeah, business logic, finite state machine, you have these these events coming in, you have common algorithms like ah snapping the user's location to a line, figuring out how far away they are from various things, how long is this line segment, these kinds of basic geometry things that you need in order to build a navigation user experience.
00:15:26
Speaker
All this stuff is normally written in like C or C++. And that's because it's portable, obviously. But we're trying to run an open source project that is easy to contribute to. And so we chose Rust for that, because it's still very cross-platform. And yeah, I could talk a lot about the interesting reasons why we chose Rust. It sounded like you had a question there. Oh, yeah, please. Tell them tonight.
00:15:50
Speaker
Is this the first time I've heard someone say that their first reason was for for getting open source contributions? Yes. um i mean like yeah and i i and I think a lot of other people on the podcast in the past have preached the virtues of Rust. like it's It's great maintainable code it's performance and and these are all all really excellent things, really easily testable. But um like trying to get people to contribute to a C++ plus plus project, is ah that's a pretty big ask. And not just for the individuals because most people are not professional C++ plus plus programmers.
00:16:26
Speaker
um But also for the maintainers of the project, if you have a small maintainer team, um it takes a lot more mental effort to review C++ plus plus code. And particularly if ah if you want to have this, like our our our goals for this are pretty lofty. like We want this to be able to be something you can go and run in an embedded environment. um And you have to okay you have to make so many you know guarantees and so many checks about your code. If you're writing that in cs C and C++,
00:16:55
Speaker
it's it's It's quite a ah burden to maintain that kind of thing, and the difficulty of maintainers onboarding contributors and keeping the projects in a correct and safe state is a lot harder. So that's one reason why I chose Rust. Funnily enough, this morning I was looking at some C++ plus plus code for embedded hardware and trying to understand what it does, and yeah, I'm completely sold on not wanting to maintain that.
00:17:23
Speaker
Okay, so Rust, Rust Compileable, I can see that very portable. Are you therefore writing a Rust UI for Android and iOS?
00:17:35
Speaker
yeah I've considered that. um In fact, there's some real if you want to do that, there are some amazing projects you should check out. um I had a couple of them written down. um Crust, I believe, comes to mind, and Dioxus. Those were really fantastic. The Crust one in particular, I watched a talk by one of the the creators of that or something. It was at some some Rust conference and I was just blown away by how far they had got. they built an entire It's like Flutter or something, um you like where you're you're writing a cross-platform framework and like everything you can define in Rust and I'm like, wow, that's like that's amazing. um But that's not what we're trying to do um because we want things to be able to be usable by native developers on whichever platform they're familiar with.
00:18:26
Speaker
I use the developer to be able to pull you in as a library. Yeah. Yeah. Yeah. yeah So that exact the library, that's actually the exact. um Yeah, that's that's the exact um pain point that we hit with with most of these things like.
00:18:40
Speaker
um Like actually for, we were looking at Kotlin multi-platform as another option too. um That's also definitely gaining steam. um But at the time, I think this has actually changed now. So um the no shade on them. um They were very focused around the use case of I'm an app developer. I want to build an app that is cross-platform, not I am a library author. I want to ship a library that works on all these platforms. Yeah, yeah very different set of needs, right?
00:19:07
Speaker
Exactly. yeah And Kotlin is also, by the way, really interesting um because they're also now doing with their new compiler and stuff um like Wasm support is actually quite good there. so their Kotlin is definitely trying to get into this space. but At the time, Rust was definitely the um the the best option for this. And there's some really great um great tooling, like Mozilla is shipping some components of Firefox across platform, including on mobile. And so they did a lot of their work in creating these idiomatic binding generators. So the point is we can write
00:19:44
Speaker
the core code, we can write the data types, like what is a route? What's a geographic coordinate? um What's a spoken instruction? All these like core domain concepts. We can write all these model definitions in Rust. And then on the Swift side, then you get something that feels like this was actually written by a Swift programmer. So for example,
00:20:08
Speaker
um ah i Speed units um you have like ah kilometers and miles per hour. um This is a we would model this as an enum and like any any language that has decent some types. um yeah So ah and and you can do that in Swift. um So there's an enum type in Swift Kotlin. I think it ends up as like a sealed class with different different um implementations or something like that. um yeah But the point is, it ends up being like completely idiomatic on the relevant platform. you can even do like ah You can even do async, which is wild. We're not doing that at the moment, but you an async trait or something like that. You
Customizing Navigation with Ferris Star
00:20:51
Speaker
can have an async function that you call. um Traits are super cool um because you can have a function interface that takes a dynamic trait and then you can implement that in Swift or Kotlin code.
00:21:05
Speaker
Which is like, I just let that sink in for a second. Like that's why I'm like, you can write um code yeah you can write some code in Swift or Kotlin and you can just like pass it in as like a closure or you can create an object that some.
00:21:20
Speaker
Uh, that fulfills this interface. So like in the Kotlin world, you can like implement this as a Lambda that implements the single method interface. Um, like that is super cool. Okay. So, so you just make sure I've got that you're writing a trait in Rust, which defines some behavior. The Kotlin author writes some code that implements that behavior and it gets transparently passed across to Rust code. Exactly. As a developer, it's magic without crashing. Yeah. That's, that's, that's the magic. Yeah. Yeah.
00:21:50
Speaker
Yeah, so this lets you define or it lets you redefine ah core behaviors in whatever language that you're writing in as like a ah mobile developer, and you don't have to wait for us for a PR. or like like There are some cases like, say you've got your own proprietary um routing API, or say you've got your own algorithm and your own data set for figuring out whether the user is on on the routes. These are all just traits now in Rust and we provide default implementations. um In fact, sometimes several implementations that you can pick from one of them. um and Then you can override this behavior in your app without having to like send a support request to like add this new thing to the core. so it's ah It's a pretty powerful system.
00:22:37
Speaker
I'm trying to think how I'd use that in a navigation thing. So I'm writing a navigation for the Developer Voices theme park, which will be coming sometime in 2030. Could I do something like, I want to write a Swift app that plays a certain sound. when you when your When your location gets close to one of my rides, I will play a certain sound that's connected to that. Is that the kind of thing we're talking about?
00:23:05
Speaker
You can absolutely do that, um although you could have done that without our SDK. um what let's Let's make it a little bit interesting, though, and refine that. So um say you want to, um when the user gets close to the um the Tron light cycle ride, do you want to play this like 80s arcade music or something, or you want to have this like, this like, you know, robo voice or whatever announcing,
00:23:33
Speaker
turn left and enter Flynn's arcade. um like you can You can do that because the text-to-speech trait that receives the callback basically whenever a new sound is supposed to be played, you have full controller for that. um so like A more realistic, a less humorous implementation would be ah you don't like the built-in Siri voice on your iPhone. You want to use like Amazon Poly, which has ah has better, um, a natural sounding voice or open AI's newest thing or whatever. Um, so you can swap all that out. Okay. So back to bindings, do you say you're using this tool from Mozilla? What's it called? Yeah, it's called unify. Um, spelled like uni and then FFI as in foreign function interface. Oh, that's clever. Okay. Yeah, it's a clever name. Um, so yeah, they do most of the hard work of, uh, I write this rust traits. Um,
00:24:27
Speaker
there's There's two ways that you can that you can define what that interface looks like. um One is to use this language. It's called UDL. um It stands for ah something description language. ah it's It's a form of interface description language. So if you've ever heard of these other ones like um IDL for the web, but um which Mozilla is also somewhat involved in, um WebAssembly has some similar things going on.
00:24:52
Speaker
um I believe it's called WIT um for WebAssembly interface stuff. um these These kinds of interface description languages are not a new concept. Basically, you you write something in this language that says, like this is the the contract, and then um you have to write some code on your on your Rust side that fulfills it. And then their generator will consume that and then say, I have a Swift generator that consumes the UDL. I have a Kotlin generator that consumes the UDL. And then it spits out something.
00:25:23
Speaker
If that sounds a little bit complicated and I just lost you, um, that's true. Um, so they've been trying some new approaches recently. And, uh, if you're, if you're a hardcore rust programmer, you might be thinking that sounds like it should be automatable. Yeah. It turns out it is. Um, you can automate this kind of, uh, stuff with macros. So that's the way that, um, that things are going to be going forward. I think. So we're, I think it's still like beta or unstable or something, but, uh, where you we've had very few issues with it. So now we can just write a little macro like ah unify export over this type, and then it's um you know it's say it's a model that exports that. um We want to export this sum this function, this you know constructor,
00:26:10
Speaker
um you can just do this all with ah with macros basically. and then ah so okay So that's the rough side of things. so um Then you have the binding generator which I referred to in passing. So what that does is it it goes and looks at your your code in this case or whatever it generates and says, okay, now here's what I need to do to generate some Swift code. um So we've got the Swift code, we've got this Kotlin code. um Okay, cool.
00:26:37
Speaker
Now what? We need to actually be able to call into the Rust code. um That's the part that Unify doesn't handle for you, and you have to figure out yourself. um So you have to figure out all the cross-platform compilation, how to integrate it into your build system, and and all that. So that's kind of the boundary there. That's not fun. I think we might dive into that in a second. but um So one of the things that always interests me in this, and we covered this, we had an episode recently talking about Python and Rust.
00:27:07
Speaker
But yeah um whenever you're compiling between two languages, the thing that gets you is the concepts that exist in one and don't exist in the other. Like what happens when I, when I take a call back that doesn't understand borrow checking, for instance? Ooh. Um, so for borrow checking, Oh, you're throwing a doozy out right away. Okay. So for borrow checking, I think the answer is they don't, they just like, don't let you do that in most cases.
00:27:37
Speaker
do you have to risk it being unsafe or? No, no, no, no, they, no, they, they, they do everything that they can to ensure that it's safe. Um, but that that imposes some limits on the code that you are allowed to write and export over the FFI boundary. okay Um, so for example, they'll, they'll do some automatic bridging of strings. Um, I,
00:28:01
Speaker
would say go read the unified guide on like they have a ah guide in MD book. They have all these internal details documented. um I don't actually remember the particular details of how they do that one. um
00:28:16
Speaker
Numbers, obviously, it doesn't matter. You can just copy stuff back and forth. um the The unify approach, there's so there are some ways that you could do this with just like, you could probably think like, OK, I know the Swift uses UTF-8 strings. So I can just come up with, um it it might just be a pure pointer, or it could be just some kind of like loose like view proxy kind of thing that goes and points at the same memory.
00:28:43
Speaker
um Unify generally tries to keep things safer rather than um going for all the performance and having a risk of something going wrong. In the case of strings, i like I said, i I forget what exactly they do. um For other cases, then I think it would basically just be like ah ah co cloning its or whatever as it goes back and forth. Okay. So do you find ah the experience of that as a programmer, do you find yourself restricted in what you can say in Rust in order to get it over the line?
00:29:17
Speaker
Normally not. um So they've done a pretty good job of ensuring all the common types that you would need are um are like bridgeable for lack of a better term. So things like strings, things like Vekov U8, so like a set of bytes basically, byte array. um So these kinds of things are all already, um like they do the work of bridging that for you. For other things, then It's actually kind of like, uh, this is a bit of a stretch analogy, but it's actually kind of like Saturday, um, where you have traits that you can implement. So say I want to pass a UUID over the FFI boundary. UUID is not a bridge type.
00:29:59
Speaker
um One of the ways that I could do that, though, is say, okay, I'm going to implement this ah this interface, and I'm going to forget what the what the name of the trait is. but but But I can implement this, and I could just say, like okay, like write this string value for the serialization step. And then for the deserialization step, um you just do like the inverse transformation.
00:30:21
Speaker
Yeah, the old computer science trick of you can always turn it into a string and back. Yeah, exactly. Exactly. and You can always turn it into a string. Obviously, that's not the best. That's not the most efficient way to do things. A more efficient way would be to um do like a byte array or something, because it's like it's larger than the size of a standard integer on most platforms. But yeah. OK, OK. So that's the that's the raw talking from Kotlin Swift Rust. But that never quite satisfies because what you, what you often end up with is here you are as a Swift programmer using a Rust based library and everything looks rusty. If that, that's probably the wrong way. But you know, everything feels like it's written by a Rust programmer when you want it to be idiomatically Swift like, do you do anything for that?
00:31:11
Speaker
Yeah, so actually unified does some stuff for that for you automatically. So for example, a a Rust function, the way that you the way they you signal an error is you return a result type.
00:31:24
Speaker
um They've done a lot of work, so not only can you define your ah your models like your structs or your enums, um you can also define error types. And you can use this using these popular crates like um I think Anyhow is the one that they support.
00:31:41
Speaker
yeah any how is the one that they support um So if you're if your error type implements some anyhow, you can you can just you just really quickly, um without too much code on the Rust side, have a function that returns a result and then some error, and then it will go and recreate your, like say, error enum with all of the different variants. like this This function could return an IO error or it could return a um ah parse error um as as error types, for example.
00:32:10
Speaker
um That gets reflected then on the Swift and Kotlin side with ah with error types. and What's an error type? Well, like in Kotlin land, for example, it's going to be an exception. um Kotlin functions don't return results. um They return whatever the success value is, and if something goes wrong, then they throw an exception, and that's up to you as the developer to figure that. out That's not my personal favorite, but that is idiomatic Kotlin, and so that is what gets generated.
00:32:39
Speaker
Yeah, and similar on Swift side, Swift also has a concept of throttle errors. ah So the function we marked just throws and and so on. yeah So are you saying that Unify takes care of all of the idiomaticness for you, or do you still find you end up writing like wrapper libraries, like thin things to make you feel nice? we We still have a wrapper library, so one decision that we made with the with the the core, I call it, of PharoStar is to keep that um pure in the functional sense. so It's pure transformations. You call with some function, ah with some arguments, it is always going to return the same results. and Then the um the imperative, the impure side, that's all in the and the platform layer on on mobile. so your i Your iOS library is going to have to keep track of, okay, a new location came in. This was the previous navigation state. Now the state is this. I'm going to save that.
00:33:37
Speaker
um And we don't want the end users to have to do that. um So we build a, it's pretty minimal. It's all like a couple hundred lines of code, I think, in in both Swift and Kotlin. We call it the FaroStarCore class on both, um both iOS and Android. So there's a Swift and Kotlin class for that. And it handles, you know,
00:33:58
Speaker
it's It's a little bit higher level, so it's like this class is usable for the purposes of a um ah trip, and then you can you can ask it to get routes. you can um It has a delegate, for example, on iOS. That's a very popular pattern in and Objective-C in Switzerland. It's the delegate pattern.
00:34:16
Speaker
and um in Kotlin, then it's a little bit different. Instead of having one kind of delegate, then you have all these other interfaces that you can implement, so and then you can die you can um pass those off to the core class, and then you can get notified when the user goes off the route. You can implement your um your robotic voice to say, go to the the Tron arcade and things like that. You've hit upon my favorite feature.
00:34:43
Speaker
ah navigation apps, which is when I go wrong, you can subtly correct without nagging me. but I don't know how to read maps and I'm an idiot. Yeah. and And it's, and well, actually like this is a really, um, this is a really interesting, ah um, ah yeah we were talking about earlier, like this sounds like pretty simple where all the places that it could go wrong. This is something that.
00:35:05
Speaker
You might think that there's some like holy grail, some right answer for you know how do we how do we handle when the users offer out? When do we even decide when the users offer out? yeah I think there might be like some some correct answer to that, but there isn't. It depends a lot on the context. um If you're building a pedestrian navigation app and your users are in the middle of new york city with all these tall buildings um you might want to have some different thresholds and you're not gonna have the same sensors as the car so the user's location is going to be kind of wild going all over the place drifting and whatever because of the like a urban canyon effect of all these like tall buildings around you can't get a very accurate gps signal
00:35:45
Speaker
Um, the point at which you reroute them is probably going to be different because like a car, when, when you've detected with some certainty that the car is gone the wrong way, like it's turned right. And it was supposed to turn left. Like there's no turning back from that. Like it's, uh, Oh, yep. Sorry. Um, you know, do a U-turn or, uh, go in, you know, loop around the next block kind of thing. Um, but, uh, but with the pedestrian, then maybe like that was just a spurious update and they have, it's actually really moved that way down the road.
00:36:13
Speaker
and And you can be a lot more lenient with the pedestrian case and like let them realize as they're looking at their phone, like oh actually, I was supposed to go this way because I just like wasn't holding it right. Yeah. that That tricky human user interface stuff. This is something we need to get into, actually, the the whole user. Because I looked at the code base. You go to GitHub for an open source project, and it tells you what percentage of the code is this and that. yeah And it's like, you're telling me this this is a Rust core with some relatively thin auto-generated code around it. But the Rust only accounts like 25% of your code, and most of it is Swift or Hotland. So what are you not telling me? What is all this code that's in there? Well, part of it is demo apps. um So we do it. OK. So let's use things a little bit. ah Part of it is. um
00:37:10
Speaker
ah I'll try to throw too much shade, but Kotlin is a little bit verbose of a language, so like that that definitely of that definitely requires some some extra code. um Yeah, um yeah you you can't get around can't get around that.
00:37:25
Speaker
um The other thing is that you mentioned a user interface. um The user interface is not in Rust. um We're not doing a crux or or slint for embedded, I think. I hope I'm pronouncing it correctly, um where they've got the whole like user interface toolkit in Rust. um So we're doing all of the UI and SwiftUI on iOS, Jetpack Compose on Android.
00:37:49
Speaker
and We're giving you a whole library of reusable widgets because one of the problems and one of the reasons why we we started this project is that the existing SDKs are like, here, we've got this like navigation experience that you can just like throw up a modal window or push it on the navigation stack or whatever.
00:38:10
Speaker
and it You take that and you might have a few things that you can customize like I want to hide this thing or I want to you know anchor this to a different position or something like that. But you can't can't really build a bespoke um user interface around that. And that's what a surprising number of people that we've talked to actually want to do. So how do you do that? um You can't do that super well with something like UI kits or with the Android views. You can, it just gets very It becomes unwieldy pretty quick and so most people know it most libraries don't so
00:38:45
Speaker
What we did is with SwiftUI and with Jetpack Compose, um they're very composable. and And so what that means is I can have a view like, let's use the map example. So the core of our navigation experience is a map. So we have a map view, and then um we can kind of chain um different or chain or nest using ah different, um like ah they call them trailing closures in Swift. I forget what they're called in Kotlin.
00:39:15
Speaker
um But yeah you can just like pass some additional code that then build another view and then it builds another view inside there and so on so like our map view is set up um using these view builders and swift that um i can add a ah line on the map that shows where the routes going and i can not.
00:39:33
Speaker
And and like we have our own default implementation of that. But if you don't like that, um you can actually take all of the pieces that we've built, not just the map view, but like the map view, you're probably going to take that as is. um But then you can decide but um how you want to draw the line if you want to draw a line. like there's There's all kinds of decisions you can make there. um You can make a decision on if you want to have like zoom in and out buttons, so a speedometer view, um speed limit signs, and you can take all of the pieces that we've had, you can replace them with our own, you can use them, you can kind of cobble your own thing together, and um you don't have to start from scratch basically. Can you give me an example of what you consider to be a really bespoke experience? Because at the moment all I can think of is my theme park where, yeah, I'd want to add some fancy widget stuff to that.
00:40:25
Speaker
What counts as weird for you or novel? What counts as weird? Okay, so I'm going to go to the absolute most minimal. I think someone actually made an app for this. um Say this actually kind of works for first certain like theme parks or urban environments that are super dense. Maybe actually the most useful thing for you is I just want to see an arrow.
00:40:49
Speaker
telling me where I need to go next and then like ah some kind of direction maybe. um Or maybe the map doesn't even like appear so much until ah until you get to a certain point or something like that. I think this could be an interesting navigation experience for for all kinds of urban things. It could be really interesting for cycling if you want to have kind of a explore focus. Like I just want, like i just like I want to get to this restaurant, I know, but like, I just want to like, you know, I'm just like, I want to like, you know, just chill her out, chill out. And you know, like, I want to go down this other side street. Like it's a new town. Like, say I'm going to Amsterdam or something and I rent a bike for the day. Like I want to see the city, like getting to my destination is important, but it's not like the most important thing. So I could totally see, um, some kind of, uh, local navigation experience. Um, like this being useful, I want to get in the direction of the restaurant, but, um, there's a cool, like looking in like a canal over there. I want to, I'm going to go check that out. This is some cool looking houses. Yeah.
00:41:46
Speaker
Yeah, a friend of mine's brother did um a device like that called Beeline, I think it was. I don't know if it's still going, but it was like, you type in your destination and you just get an arrow. And the idea was that you cycle and get lost, but you'd get ever closer to where you were actually going. and Yeah, I can see that. yeah But that stripped down. Have you got anything that's like richer? Richer? um Well, so I'll i ill um I don't know if anyone's actually doing this yet, but within a year or two, we will definitely have people building apps for like Vision Pro. um So augmented reality kinds of experiences. yeah um Google's already doing it. And actually I think Apple is is too now in in certain areas anyways, with your phone, you can just hold up your phone and it's an augmented reality view. I actually think that this is going to be really useful in the future for um
00:42:42
Speaker
for urban wayfinding. In Seoul, you've got like all these bus stations. Some of them have the same or very subtly different names. so um You have a platform ah with the same name. It's like you know this university ah bus station, and it's the one in the middle of the road, but which direction are you going? like if you're not familiar with the area, like you're there like staring at your phone and being like, okay, like is my compass calibrated right? And like, okay, so like I wanna cross the road here and this is the one that I need to get to. I think AR is actually a pretty good use case for that. Yeah, yeah, I've used it for exactly that. like yeah And there's a lot you could do to customize that if you've got, I mean, I would have thought among the people using this will end up being tourist boards if they can get the budget to do software development, right? well
Ferris Star's Role in Tourism and Local Navigation
00:43:33
Speaker
actually i'm ah'm really glad you mentioned that um so One of the like I talked about, um you know, portability to embedded devices like car infotainment systems. But another thing that we're really excited about is WebAssembly. And the reason for that is mobile developers are really expensive. Like I get it. Not everyone a tourist import doesn't have the budget to hire a iOS developer and an Android developer. Maybe they can manage one react native or Flutter developer.
00:44:06
Speaker
um But more likely it's gonna be a whole lot easier to find someone who just knows like some basic javascript and put together a web page they've got there. um Like they've got a walking to a route planned out around like historic downtown um they've got a outdoor festival going on um these kinds of things and we actually have a couple of customers who are interested in this use case so and.
00:44:27
Speaker
building something where the core, the functional bit is shared, all of the logic, the you know geometry snapping, all those things, all that's shared. And all we have to do is put a web front end around it. um This makes it really easy for people to quickly put out an app that gives you this navigation experience. There are some limitations like the that um Web Geolocation API doesn't give you um background location access. it So you're not gonna be able to like exit out of your browser, lock your phone, whatever, and then go walk around and expect it to tell you, yeah, like you're like miles off now. um It's not gonna be able to do that. So there are definitely some limitations to it. um But I think that navigation is very much underused by but things like ah local tourism boards. And yeah hopefully this will change that.
00:45:16
Speaker
I could see it happening at tech conferences as well. it There are a lot of tech conferences with truly terrible um like oh yeah conference apps. But if they ever wanted to get their act together, being being told how to get to the room that you want to be in next for the next talk would be a miracle. Yes, it would. And this is a place where you don't typically get navigation data inside large expo halls, right? Well, that's an interesting one because Actually, if you pull out your your iPhone or I would assume Android as well in an airport, for example, um you probably will actually get like it's not going to be like really accurate, but, you know, within 50 meters or so of where your location is, um even if you're deep inside the building. um So Apple and Google have actually done a lot of work on indoor positioning. It's not. It's not super accurate yet. It's not accurate to the point to say, like,
00:46:10
Speaker
This is where your, um, your next conference room is, so um, in, the in the, in the default case, um, it is actually possible to get a lot better though. Um, you can actually get within, I think like five meters now is, uh, is the kind of standard with these like, um, beacon approaches. So they'll install beacons throughout the the building with no locations. And, uh, it is possible to do this. Um, that's not something that we're focusing on right now, but it's definitely something possible for the future.
00:46:38
Speaker
the future is slowly coming. yeah So yeah we we need to get into the technical details of WebAssembly. ah Firstly, is is it morally required that every single Rust project now compiles to WebAssembly? It sure seems like it. um When I first got into Rust, which was like 2017 or something, um a guy who is now part of our co-working group was was like evangelizing WebAssembly. And I was like,
00:47:07
Speaker
Web assembly. like I, I, I, I, what? Like i I don't get it. Like, and there was one other guy there who was doing like a game engine or something that was using web assembly for the, the backend logic. But he was talking about like, man, it's so hard. Like with wasm buying Jen, you have to like do serialization across the, like, like we're talking earlier with the FFI stuff, like it's a whole lot worse with web assembly. You have to actually like,
00:47:33
Speaker
because the primitives that you have are so so minimal. um there's ah There's a pretty big cost to all that. And I was like, I don't get this. But I've since come around. And actually, my The thing I'm most excited about WebAssembly is not even on the web. um I think it's the worst name technology. Well, one of the worst name technologies, because it's so much more than that. like it's ah it's like ah It's like a better abstraction than Docker for running ah for running applications in a sandboxed architecture independent manner. like We think of Docker as like, I have this like you know reproducible environment. If I am running
00:48:13
Speaker
this version of Linux and I have like in access to these good disk drivers and blah, blah, blah. like it's ah It's a pretty heavy um it's a pretty heavy um ah thing to to get that level of abstraction, whereas I think WebAssembly does a lot better job.
00:48:30
Speaker
um But yeah, um, it's, it's not morally required to have every crate compiled to web assembly, but it turns out to be a useful property in this case. Cause we're also like, it was also, it's a step on the way because web assembly, you do have, well, you nominally have the standard library, slight aside on that in a second. Um, but it's a, it's a good stepping stone on the path to, uh, to no STD support, which is what you need for um for certain embedded platforms. um Now, an interesting thing that ah you might not know about WebAssembly is if you look on the platform support on the the Rust project, it says that the standard library is available. But there are certain things like, I think it's the time APIs and the randomness APIs. um if you If you try and call those, you'll actually get a panic. um So you have to bring in this, like ah like for the the time stuff, you have to bring in this web time create.
00:49:24
Speaker
um And it's ah basically saying, I can assume, like it's it's you know targeting WebAssembly, but it's like, I can assume that I'm ah running with a JavaScript interface. So I can like use these JavaScript APIs and like ship those in or something. So you have to call the, version it's like API compatible, but you have to use the, you have to import the web time version. So we have all these like weird conditional imports, like for the Wasm 32 unknown and known target, which is the one for,
00:49:51
Speaker
um for Wasm on the web browsers. yeah of course i didn't I didn't realize Wasm was sometimes relying on being able to speak to JavaScript as well as the other way around, right? If you want the if you want the full standard library and you don't want Wazzy, the WebAssembly system interface, um which is also probably going to be renamed to WebAssembly standard interfaces, I think,
00:50:13
Speaker
gets more than just system interfaces. um I'm actually super bullish about that whole initiative because what they're trying to do is actually using this interface description language like I talked about earlier with the the binding generation between Rust and other languages.
00:50:28
Speaker
They're trying to write something like this um for gluing WebAssembly components together. um And the way that they're going to do this and make it efficient is it's going to treat all of your modules together Um, there's there's some boundary that it figures out, but like you're able, if you have like multiple modules that are like linked together, um, in order to like compose and to make some greater hole, like you've got this one module that does this one thing. And then you have this, what feels like this, um, uh, this inefficient boundary that you have to cross. Um, it's able to actually at compile time, um, treat those as one, um, for compilation unit purposes. And like, say like, okay, like you can just like pass directly to here. So it gets more efficient. So there's a lot of cool stuff happening in that space.
00:51:13
Speaker
Okay. Okay. but It's the, it's the experience of, are you having a similar experience then that in that you compile your rust to web assembly and then you've got to build a whole JavaScript, uh, UI toolkit around it? Yeah, that's correct. Um, we do have to build a whole JavaScript UI toolkit around it. Um, fortunately the, the website of, um, of mapping libraries is like that, that even predates mobile by like a decade, I think. um So there's there's a lot of really good libraries out there. um I think Map Libre, there's Leaflet. There's a bunch of libraries out there that make it really easy. So the code for that is pretty minimal. um We actually have an amazing student, um Ting Jie, who is in, he's in school in Canada, and he's on the Google Summer of Code grant to work on the ah the web front end for this. so
00:52:07
Speaker
um Yeah, fingers crossed. them In about a month or so, then we'll have something that's actually um usable for these kinds of like ah ah local tourism boards and stuff. It's actually all up in the repository right now on GitHub. um If you want to go check that out, I need to make it easy to like have a demo hosted on GitHub pages or something so people don't have to download all this crap and build it themselves with Wasm Pack, which is ah that's another rabbit hole. is the The build tooling, isn't ah it's not quite as nice as ah It's not quite as integrated yet. Um, that's mostly because I'm not a front end developer. Um, I'm more of a, more of a mobile and backend developer. Um, so I'd like to get a few things, but the tooling there are a lot nicer, but, uh, yeah, it's all there and documented. It does seem like a lot of your time is going to be spent porting some UI code to this, that, and the third place and dealing with build issues. Is that your life?
Contributing to the Project and Future Expansion
00:53:04
Speaker
Um, part of it. Um, I'm more the, I would call myself the architect of how, um, how I think that this whole thing should work. Um, so I did a lot of the implementation work on iOS, the initial implementation work on Android. I've actually done almost nothing on the, uh, on the website because, uh, we've got this great student who's, uh, who's helping out. Um, so my goal is to actually be like, yeah, the architect, I want to have everything in a structure where all the basics are there and everything is super easy to extend or to change the behavior or whatever. So when someone comes along and says, ah you know, this, this, uh, this thing here is like, this isn't very good. Like, you know, this camera behavior is crap or I don't like the look of this view or I want to add this other new thing, or I want to add another, um, compatibility of some other routing engine. Um, I want to have all of the.
00:54:00
Speaker
pieces in place so that you can go in and do that. And you'll have the support that you need from all the platforms to make that happen with like just a couple hundred lines of code PR maximum. um It should be really easy for you to do this because we've done all the work of having all the scaffolding in place that you can just build on. And honestly, like I think we're We're like 95% of the way there. it's It's pretty close as far as that goes. so the um the The state of the project itself, I would say it's a beta right now. We're on our fourth beta release. There are definitely things that are missing. There are definitely some weird rough edges, like if you um rotate your Android device from portrait to landscape mode. it Like, Android's got this thing where it recreates the activity.
00:54:44
Speaker
Um, and then basically all the states lost and we have to recreate things and we don't do that very well right now. Um, so there's gonna, there's gonna be a lot of things like that, this long tail of things that we can improve. But if we have the core set, that's like my job is to get the the core structure of everything set for all these platforms. So that way, um, people have also a template for, um, what a new platform looks like. Say someone wants to come along and build a Flutter integration. Um, yeah that's something that,
00:55:14
Speaker
you could actually do now looking at how does the web do it? How does Android do it? How does iOS do it? If I have the bits of knowledge to um to know how do I bridge these things to Flutter. So like how do I bridge the Rust core to Flutter? That's one thing. And I've got three implementations I can look at how JavaScript, how Swift and how Kotlin um made their wrapper interface that makes things feel native.
00:55:38
Speaker
um So that's that's one part of things. And then two is knowing how the local UI works. So Flutter has their own reactive UI framework. React Native has their own thing. um And so if a developer comes along that's really passionate about that, um they've got the whole structure to work in and ah and patterns for how it should go. Okay.
00:56:00
Speaker
Are you going to end up from that with like versioning issues? is someone If someone wants to contribute a new UI thing for Swift, are you going to say, well, you have to write there the Android version and the web version as well? Or are you going to say, well, you get different sets of features with every platform? So there will be some different feature sets. um But my goal is to keep it so that unless you're contributing like a 2000 line feature PR for one platform, which
00:56:34
Speaker
Yeah. Then there's other problems. Um, uh, then yeah, our goal is to keep things so that it's reasonably synced, whether that means telling you, yeah, you have to go write this yourself or, um, bring in one of the other like core contributors from the project. Cause there's multiple of us. It's not just me. I'm Sabrina and one of the other people in saying like, Hey, who's got time to, um, to go and like, you know, I'm not a Kotlin developer. So like, okay, I want to like, I'm just going to do the iOS version and then let someone else, uh, someone else do it for Android. So.
00:57:03
Speaker
Yeah, yeah we'll we'll figure that out as we go. That seems like it's going to be tricky because it's very few people can do all three. So you almost contributing feels like would have to become a team effort. Not necessarily a bad thing, but a challenge. Yeah, yeah it's definitely going to be a challenge. It'll be it willll be interesting to see how it works. um I'm so far excited by the um by the interesting contribution. um We'll see how it's ah how it plays out after um being around for another six months.
00:57:31
Speaker
Okay, well, as we watch that journey then, if someone wanted to use this, how would they? And if someone wanted to contribute, would that be welcomed? What kind of tasks are needed at the moment? Yeah. um So if you want to use it, um go to GitHub. We have a full MD book, which has some tutorials on how to get started with iOS and Android. Web is not documented yet, but it will be by the end of the summer.
00:58:02
Speaker
um If you have questions, then we are available in a Slack channel, um or of course you can always open up a GitHub issue. um If you want to contribute, that's very much welcome. We've even gone so far as to flagging certain issues that are like higher priority. um Like this is blocking someone from doing something in production. um We've also got some things that are marked as like good first issues as well as help wanted. So if you're an Android developer, for example, I think there's a couple of tasks that are um like a bit more specific to the internals of Android. You could go and like poke around the help wanted tasks And yeah, of contributions are definitely welcome. um I think we've had seven people contribute so far, um three of them fairly regularly. um So yeah, contribution is definitely welcome. And ah the more that's so the more people we can get using this, like if you're building a mobile navigation experience, like I firmly believe that this project is the future as far as open source navigation solutions go. Everyone ends up solving the exact same problems.
00:59:06
Speaker
like camera issues and stuff like that. ah Everyone ends up solving the exact same issues. I've talked to dozens of people that are that are doing mobile navigation and everyone's like, yeah, actually, I'm really excited about this. and And half a dozen of them are already integrating them in their apps. So, yeah, more people integrating, the better. Well, I can promise you that one day I'm going to get absolutely sick of conference apps and think about rewriting writing a new one that actually solves the real problems people attending have.
00:59:35
Speaker
And if I hit that point. We should collaborate on that. Absolutely. But for now, Ian, thank you very much taking me through it. Yeah. Thanks for having me on, Chris. It was a lot of fun. Pleasure.
00:59:49
Speaker
Thank you, Ian. I'll now have to go to my Developer Voices big map of the world and put a pin in South Korea for the first time. I wasn't expecting that one. While I'm doing that, if you want to find your way to Ferris Star's source repo, the link will be just due south of here, down in the show notes, as are links to all the other things we discussed as always.
01:00:11
Speaker
And as you're navigating down to the show notes, should you pass the like button, the share button, the subscribe button, please give them a click. And if you find you want to do more than just click, if you really want to support, there's a link to our Patreon account and you can sign up and get backstage news and support future episodes. And if you've already done that, thank you very much.
01:00:35
Speaker
On the topic of future episodes, if you're catching this in the week it goes out, there will be no future episode next week. It's the time of year for me to go on holiday vacation, holiday-cation. I'll be back in a fortnight. So until then, enjoy your summer. I've been your host, Chris Jenkins. This has been Developer Voices with Ian Wagner. Thanks for listening.