Hacker News Reader

Comment by echelon | Hacker News Reader

My startup is betting big on Bevy, Dioxus, and WASM. (The thing we're building requires this.)

It's a bleeding-edge weird world, and there's definitely a lot of risk, sharp corners, etc. But it's also incredibly exciting and a breath of fresh air.

One of my big worries is picking the "wrong" tech and the community electing something else, leaving us in an evolutionary pit. We already see this in other areas. We chose Actix Web, and now Axum appears to be in the lead. That's not as big of a concern as the frontend stack changing, though.

Anybody else headed down this path?

View on HN

You shouldn't worry too much about not picking the library/framework that ends up being the most popular: as long as the project fits your needs and doesn't die, you're good. For instance, Actix remains a solid choice, and given it survived having two changes in leadership, it has actually proved pretty robust. Conversely, even the most popular framework could disappear if the maintener gives up and nobody can/want to take over.

So the best thing you can do is making sure the maintainer doesn't burns out and give up.

As a company that includes giving them dedicated help for triaging bugs or reviewing PRs (it doesn't need to be a full time job, but assign one member of your team a fraction of their work time to this task) or sponsoring them if you have some money to spare but only if they are looking for sponsorship to have more time working on the project (but not otherwise, because that's a recipe to make them burn out).

I've been down the path of picking the defeated tech myself, I would give this simple tip:

If the project is likely to hit production and be supported for the many years to come, architect the code base to separate concerns. Most logic isn't part of the bindings to any framework.

That way potential migration isn't off the table. And it gives a certain peace of mind.

This small pet project isn't a demonstration of that, but building a web application that serves data can quite simply abstract things like routing and parsing, keeping all the core business logic independent.

Just don't have any Actix, bevy, dioxus imports except where they belong.

Add abstraction layers where needed, it's sometimes inevitable given how frameworks can spread their tantacles.

Wasm isn't going anyway, so on that front given first class wasm support by Rust itself, no worry to have.

"hexagonal architecture" (aka ports and adapters) offers some nice practical ideas on how to achieve this.

I find it works well with rust. Rust traits are well suited for a ports and adapters setup. And in the rust ecosystem, "frameworks" are most often designed to get out of the way. To be pulled into a project as library, rather than to enforce itself all throughout the codebase (like Rails, Django, Laravel etc tend to do)

Unless your startup model revolves around releasing tooling in this space, why would you focus so much on tech this early on instead of just shipping stuff fast? I've seen founders nerding out on the tooling and picking exotic languages like D for things that could be done in PHP or Rails in 1/5th of the time and I can understand that for hobby projects, but I'd never bet my company on that.

See above: the thing we're building require this

It's not like you can easily replace Rust with something like PHP or rails in most context, the alternative would be C++ and there's definitely some productivity and stability benefit in using Rust, which can dramatically speed your execution (especially if you don't have a rock star C++ team in the first place).

It's an often repeated idea that somehow Rails or PHP allow to ship faster than rust (or go, or java?)

For one, it's simply not true in many cases: I know Rails (and Sinatra) very well and axum or actix slightly less so, but the time from idea to running server is hardly different in both. In this phase, that's measured in hours or days anyway.

Secondly, the primary thing that speeds up "getting your startup to production" is using known tech. Stuff you are extremely familiar with, is boring, and well supported on hosting and deployment. If you write rust day in day out, getting rbenv,bundler, the right gems,ide support, CI, linting, and whatnot set up will slow you down a lot when you are new to Ruby and Rails. Same for any language. I'm slow in PHP or Python because I keep hitting speed bumps that require experience, detailed knowledge of the stack, or best practices to figure out.

I now understand the borrow- and typechecker, in rust. The thing most people say is slowing them down. It was slowing me down, when I was new to it. The same way my inexperience with pipenv, or phpstan or webpack is slowing me down on python, PHP or JavaScript.

And lastly, the strictness of rust, as with Java and C# (and TS) is also very quickly turned around into a time saver. Refactoring, understanding and maintenance is just so much easier and faster with static typing and checkers. And, I've found, especially in the first phase of rushing, pivoting, adapting and rapid change, a crucial timesaver. Which is after days, already.

I was referring to the benefits using a well established framework/platform gives you as opposed to implementing new features. The boring parts of web are long solved in boring frameworks, but not new ones, where you mess around trying to come up with a good project structure, form handling, auth, background workers and all that. Performance critical paths can be written in performant languages, no need to do the CRUD part with fancy tech imho.

I know.

And I was referring to the benefits of using a framework or platform that you know well. Which is rather different, but will often overlap.

The boring parts may be solved in boring frameworks, but if you don't know to find them, don't know their ins- and outs, don't know how to leverage it (or avoid parts) and so on, it just slows down. Learning a language is so much more than learning a new syntax - that's the trivial part.

It's about learning where to find up-to-date information, what libs are good today, which ones no longer preferred but still highly popular for legacy reasons. Which boring stuff saves time and which will come and byte you. What "sharp knives" or "footguns" there are lying around. And what might speed you up today, but cripple you tomorrow.

We're using Dioxus on the backend with Axum for https://github.com/bionic-gpt/bionic-gpt

Very pleased with the result. It's great having the compiler help out with UI work.

Shoot - I tried to select a Rust backend web framework purely on popularity and totally missed this Axum.

I’m having a good experience with Warp, but as a new Rust user I feel like I’m investing a lot on learning Warp’s system of traits. Perhaps I’ll get better at internalizing such things but for now, it seems likely that the switching costs, even if only cognitively, might be a bit steep.

I'm building a game with Bevy targeting WASM currently :)

Good luck with your project!

Can I ask why not fyrox?

bevy: 1M downloads, tons of example games, plugins and tutorials. large community of helpful people. school book example of well-run FOSS project.

fyrox: 12K downloads, first time I hear about it today.

I did a decent amount of research before settling on bevy two years ago, and I did not even encounter fyrox back then.

Since then I learned bevy and am happy working with it.

Following the bevy project's updates I gained a great deal of respect of the project lead and the long term goals of the project.

Also, since I'm mid project there's no good reason to switch frameworks now.

So why would I use fyrox?

Good point, community wins. Was just asking.

I dismissed fyrox, I was initially interested in their real time scene renderer, but it terribly lags in my environment. I still think it has a nice architecture.

Scene editor is one of the major lacking parts of bevy right now, but it's in the planning stage.

You can follow the issue at https://github.com/bevyengine/bevy/issues/85 if you are interested.

Interesting, thank you.

I got to know the developer of Fyrox, MrDimas, and commissioned him to implement blend shapes (morph targets) in the engine, as they had been missing. He's an amazing engineer and got it done quickly.

I then took the same task to Bevy. There are so many more people in the community. One of them stepped up right away and I commissioned him to implement similarly missing blend shapes. Same excellent engineering and delivery, but there were thirty times more people asking and involved in the process.

Bevy has community. Fyrox is a one man show.

Fyrox was ahead of Bevy a little bit, but Bevy has taken the time to develop community and has made much more important and sound architectural choices for becoming a much bigger project and engine.

If I had to recommend either, it'd 100% be Bevy. No hate or dunking on MrDimas, either, because he's an amazing engineer and has built something incredible. But Bevy absolutely appears to be the future, and their community is not going away.

Reply on news.ycombinator.com