Hi, welcome to this comparison of data Space and shuttlers. They are both platforms for development and deployment of cloud applications, and they both support rust. You can also see the content of these slides on GitHub pages, or you can clone it from GitHub or you can download the pdfs. If you clone it and you follow a few steps in the source of ReaDMe, you can also view them offline and at your pace. Standard disclaimers apply. The main ones are that this is not those complete introduction to either platform. You do not need any deep knowledge of rust for this, and surprise, these platforms are new and they are work in progress, so there are good things coming, and if this gets outdated, please let me know. Some of the features and limits are not draft specific, but they do affect how the applications are deployed and for what purpose. Hence I'm including them here. You can also look at the source code of my four applications, two for each platform I used three rust framework web frameworks for them. They're trivial applications and useful. One for each platform show the system information like directory listing quotas or the available space on the mounted drives, and one on shuttlers shows those headers as data used to document that. Neither of the platforms shows IP addresses coming from the client. On data space you can see transient web dev server. It's a tiny one that it uses its data space's file limit of up to 500 or so megabytes and I will be sharing my bookmarks and highlights for Firefox on data Space shuttlers and rust, so feel free to use them. Even though it's a transient file share, it will be synchronized from my Firefox, so if data restarts it for any reason, it will get synchronized there soon. And I've documented steps on how you can read and synchronize those bookmarks into your Firefox. Spoiler alert. I love them both. Before we get into the qualities and limits of each platform, let's have a quick look at the source code and some configuration. Data space uses Space file, which is YaML file with simple entries. It's very well documented, and if all you need is default, or if you don't need any private routing or special features, it's very easy. However, rust support is quite new at data space, and occasionally rust applications don't work if you build them with standard target that uses Glipc. Because of that, I suggest that in the interim you use the mucil target, which is a lightweight, Linux statically compelled target that doesn't use glipsy at all it has its own implementation of STD library and that works very well on data space. You use whatever crates you want or you need in your application and there are no specific crates from data needed other than the unofficial data space SDK. The configuration gets done in your application where you need to read the port environment variable and use that as the web port of your application. Or actually it's not the application, it's the micro, which you can have up to five of them in the same application. We'll get to that soon. In shuttlers there is no mandatory configuration file other than that there is a file called Shuttle Toml, but all it does for now is that you can specify the application name in it, but it's optional and you can specify that in the CLI as you deploy the application. Anyway, configuration is done or those integration with Shuttle is done through custom crates provided by Shuttle and you can see them here. For example, this is a cargo tunnel for a web app that uses XM and shuttlers provides two XM crates, shuttlers exum and shuttle runtime. Then let's look how it is used and here you see an attribute procedural macro shuttle runtime main, which you apply to the function that serves your application and in this instance the result type is custom to shuttlers XM that is very well documented with examples or tutorials and it works well out of the box. However, since we are looking at the source code, you may want to remember that if you are using advanced features of those frameworks supported by Shuttle, it does get complicated because you may use features like retrieving or handling and setting non default headers, or your own MIME types, or anything that is non default is not trivial with shuttlers. You may find tutorials on the web on how to implement it with exum or the other frameworks for sure. But if you then want to connect it with Shuttle, you may need to do more exploration and you may want to be combining and experimenting, but that's part of our passion. Here's an example of cargo tumble for Actix web deployed on shuttle and again you have two special crates, shuttlers web and shuttle runtime, and here's how it is used. In the source code you apply a procedural attribute, macro shuttle runtime main and the async function actics web returns custom type shuttlers web both platforms share these features. They are deployed on the Linux machines, but you can locally develop on Linux, Mac OS and Windows. We don't have SU or sudo access and we cannot customize at docker level. Neither of them provides access to the client ip address. So you cannot do IP dependent logic rate limiting or geo IP handling. With data space you can, and actually most likely with shuttlers. Two, you can use special headers, for example, from Cloudflare DNS, and both platforms are active on discord. The community is helpful. Here are data space features. The applications can be private, accessible to you, the developer only, or public. That's one of the main differences between data and shuttlers, as shuttlers doesn't have private applications on data. You can access those private applications if you authenticate in the browser and most likely with C URL or other tools too. On data, you can also publish test versions, deploy test versions that are not published, and they stay private until you publish them. Data doesn't have access to your password for authentication that goes through AWS. The other big feature is mesh design. Your application can be a mesh of up to five computes, each with its own limits and file system. They can communicate between themselves, even though some of them or most of them can be private and not directly accessible from outside. You can also have routing public routing that specify which compute which micro to use for which URL patterns. That way you can integrate with third party applications. And those don't have to be in rust because data space also supports several other languages. That's the other feature. It's a mesh of languages or frameworks. The disadvantage is that rust support is quite new and it's still work in progress. Rust applications don't get special handling, which gives you some freedom. For example, you can choose your rust version or any framework, or you can use nightly rust if you like. Rust bindings for data API are only unofficial at the moment, but the HTTP rESt API itself is well documented. You don't need any special rest crates or macros for your code from Detaspace. It doesn't favor SQL rdbms like postgres, SQL, or MySQL, unless you have a pool manager, and data space doesn't provide any of such databases. Yes, you probably want mutual target at the moment, and big limitation may be that it doesn't support background or long tasks. Discord boards implementation of discord boards and websockets data space provides storage, both NoSQL, called database and object or file storage, called data store. They are their proprietary APIs, well documented but not available outside of their platform. You can use them locally, though of course, and they may not be so fully proprietary because data is pretty open source. Data isolation is very good, and you can clone someone's application have it with your data isolated and your instance is completely independent. Even if the original instance owner publishes new versions, your application is not affected unless you choose to receive the new versions. Data supports cron like schedule actions with granularity down to 1 minute, and it promotes personal or private instances. For example, the subdomains are anonymized with a random postfix, and forking instances is very easy. You don't need developer skills for that. There is the marketplace where you can share your applications and when you can see what others are sharing and then you can experiment with them. And there's a plan to offer paid applications that would generate revenue for the developer. Let's look at shuttlers. Shuttlers specializes in rust and it's top class edit. The tutorials are well written. It also documents how to connect the middleware, some security and cryptography features too. The applications deployed on shuttlers are suitable for background on or long tasks. It provides much richer storage as there are four SQL options, postgres, MySQL and MariaDB as dedicated instances. And postgres also has a shared server from Shuttle or Turzar which is a distributed Sqlite fork that is not hosted by Shuttle. Hopefully it will be so one day or there would be an option for that, but for now you would need to get free or commercial hosting from Turuso and it also has a dedicated crate from Shuttle. It offers now SQL MongoDB shared by Shuttle or proprietary key value database called shuttlers persist. The data is well isolated. A small disadvantage or limitation of shuttlers is that because they provide their specialized crates, those are pinned at some versions and they require specific versions or potentially a limited range of versions of dependent crates. Those MySQL and other SQL crates or MongoDB crate and the same with Turzo. It's pinned to fixed version and the rest itself is pinned to fixed, but a fairly recent version too. Shuttle does have much longer build times because they provide attribute macros and those use Serdi for syntax passing and handling, which is complex. It can take long to build and it can involve from around 300 or even up to 600 dependencies in your project. But if you're building it locally then any successive builds are incremental by default, so then it is much faster. It doesn't have TMP folder only dev SHM for memory sharing or temporary file system. So if you have an application that uses temporary file system you may want to choose one or you may want to customize it to you. If it depends on TMP, it doesn't promote targeting or sharing clones of applications if you'd like to share your application so that others get their own instance of it on shuttlers you need to do so on GitHub or some other source sharing service and they will need to go through the steps to deploy it, which is not rocket science, but they need some more skill developer skills than with forking an application. On data space. There is a limitation of, I believe, up to five applications per user for free, but these limits are not enforced yet. And if you contribute to shuttlers, or if you create useful applications that help people, shuttlers may reward you as a hero and their hosting and services will be free for you for life. For commercial purposes you can or they are planning that you can use your own AWS account. Here are some quantitative and other differences so these don't come out of design and hence they are more likely to be more flexible than the qualitative differences earlier. The biggest ones are memory limits, which are not very clear, but on data space you can have 250 megabytes per each micro per execution, and on shuttlers you can have usually up to 6gb per container. There is no timer to limitation on shuttlers or it's not specified, and on data space it's 20 seconds. And there are differences between the temporary file system size, but those will hardly make a difference for mainstream applications. If your application is parallelized more than a usual async web application, you may want to look more at the limits on processes or threads. On shuttlers it's only four threads per project, on data space it's 1024 per micro and if you need to handle more than five to five megabytes HTTP payload, then at the moment you need shuttlers. Those storage limit on shuttlers is 10gb on free tire, but it's not enforced yet and it's not specified on data space, and they both use AWS with at least data space. Also planning for using GCP or other clouds choosing between them there are some minor criteria or trivial ones if you need a temporary file system on TMP, or the quantitative differences if those matter to you, and if they are not likely to be changed by the platform, then you may choose one or the other, but you may still ask around because they are work in progress. If you need your applications to be private with single user only, then at the moment you probably want a data space, but then you still need to want to consider the storage. You may want this option if you are open to using their database or data store. If you need more than two authenticated users, then you can use either one because none of them supports it out of the box. If you need to mesh various components into an application, or if any part of the application is not in rust, then you want data space. You could potentially implement a mesh of rust components in shuttlers with some routing or proxy, and that could be feasible if those components use the same web framework for Rust, but especially with shuttlers special crates. It could get complicated very soon, very early. If you want first class support for rust then shuttlers are leading and also they offer background or long tasks and discord bots. And at the moment if you'd like cron like schedule actions, then you go with the taskbase. Stability and ergonomics is better with shuttlers because of their attribute macros and their support for Rust as their only programming language. But if you don't want any special crates or macros, then you may want to go with data space as well as if you need to use a custom version, a special version or a special channel of rust with those storage. If you do not want to use a third party SQL or NonSQl, and if you do not want to adapt or to use database or data store, then you want shuttlers. Otherwise you get perfect storage with data. Those commercial plan for large deployments going over the storage quotas is not mentioned by data space yet, and it's only planned by shuttle. The free sharing of applications on the platform's website itself exists only in data as well as the commercial models well, which don't exist yet, but they are planning paid marketplace thank you for listening. I hope you will look at both data space and shuttle rs and enjoy them. Develop good applications, share them either on the platform itself or on those git. Love rust. Take care.