dohguy

Thanks for posting this - I'm the author of the piece in case anyone has any questions :)

I just came from another thread where another hacker was sharing how they are getting their kids into programming by teaching them how to make games (ie. starting with Scratch then moving upwards) so I wanted to share that a friend of mine used Playdate's Pulp editor to help my daughter learn game design and he said that he had a great experience. So all in all, big praise to the Panic team!

"It was the first time I felt like I could write up a large prompt, walk away from my laptop, and come back to a lot of work having been done. I've been super happy with the experience so far." - this yet-to-be-defined "happiness" metric will be important moving forward. Apart from Opencode & Leap.new (so far) I still haven't found something where I feel as happy.

I don't know if others share this sentiment but with all these tools/agents coming out, the main personal "metric" I look at when using them is happiness, rather than other more traditional metrics that I look at when evaluating tools.

Love what Algora has been doing lately. Keep it up! Hopefully I'll manage to squeeze in some time and claim a bounty!

Hey HN, since our pivot earlier this year we have been working with the alpha users of our product shuttle (YC S20) on creating the best backend development experience possible. Interacting with hundreds of developers, we have become convinced that the time has come to rethink the virtualization layer that we are all so used to - containers. Don’t get us wrong, containers have improved development in a lot of ways, but over time they have also created a lot of problems too.

For the way most people use them in deployments of web apps, containers are too heavy. The heavier your containers are, the more difficult everything else becomes. They take longer to build, they need more resources to run, they are more expensive to store, etc. This has significant repercussions for the developers that have to deal with containers, IOW most backend developers.

Our view is that by restricting the scope of virtualization to something more specific to web app backends, we can build a tool that is much better for the job than containers. With WASM and WASI becoming stable, this is more possible than ever.

We’re very excited to share our ideas with you and would love to get your thoughts on this!

For now, we offer the persist feature. We allow you to store and load structs that can be serializable with serde.

Redis is a highly sought feature which we'll be aiming to implement in the near future! :)

Hey socialismisok!

I totally get your point regarding pricing.

Our current pricing model is currently in progress and we are shaping our billing around the needs of our users while we are in alpha. This is subject to change in the near future depending on how shuttle evolves over the next couple of weeks/months.

And thank you for the feedback re: AWS approach being documented, this is definitely something that we'll cover in the near future.

Glad you like it! :) Lmk if you have any other questions.

Hey surrTurr,

shuttle is on AWS under the hood although we make the process much easier for people (not having to deal with the console and other its and bits). There is (almost) no runtime penalty in using shuttle, vs deploying this yourself.

Other than that, we've got GH actions you can use, you get GitOps for free, you don't have to write Containerfiles and we have a centralised build system which will reduce build time by hitting the cache!

Lmk if you have any other questions :)

shuttle has released support for Serenity (a Rust library for the Discord API) a while back and now we have a tutorial ready for anyone willing to give it a go: https://www.shuttle.rs/blog/2022/09/14/serentity-discord-bot (creating a simple Discord bot, extending it to a weather forecast bot and deploying it with shuttle, for free).

To give you some context on shuttle; it is a Rust-native cloud development platform (open-source) that allows you to deploy your Rust app (or Discord bot, in this case) by adding a single annotation to your main file. Once you do that, you can run `cargo shuttle deploy` and your app/bot is all set!

No worries!

A lot of Discord bot creators were sad with the recent news of Heroku scrapping the free tiers so if anyone is curious about Rust; and is a Discord bot creator; this is the perfect place and time to be! :)

Meet shuttle, an open source, Rust-native platform for deploying apps with zero infra hassle. Built by a distributed YC-backed team. In order to deploy your app, all it takes is one annotation on your main function and you're good to go!

At this point, we support most of the major Rust web frameworks such as; Axum, Rocket, Tide, Poem & Tower.

And we’ve recently added support for Serenity, a Rust library for the Discord API — so you can even build & deploy Discord bots, for free.

Our repository has a couple of examples per framework/library enabling you to get started in under 5 minutes so feel free to pick one and give it a go (https://github.com/shuttle-hq/shuttle/tree/main/examples)!

We are in alpha so constructive criticism and feedback are extra welcome!

shuttle has released support for Serenity (a Rust library for the Discord API) a while back and now we have a tutorial ready for anyone willing to give it a go: https://www.shuttle.rs/blog/2022/09/14/serentity-discord-bot (creating a simple Discord bot, extending it to a weather forecast bot and deploying it with shuttle, for free).

To give you some context on shuttle; it is a Rust-native cloud development platform (open-source) that allows you to deploy your Rust app (or Discord bot, in this case) by adding a single annotation to your main file. Once you do that, you can run `cargo shuttle deploy` and your app/bot is all set!