If you're like me and moved off from Ruby to Rust as your go-to-everything, try Loco which tries to be a faithful Rails on Rust (loco.rs). It has the magical scaffold, the smooth experience, and the features you'd expect from Rails including authentication built in (like Devise).
We definitely try our best to match the Rails experience. Being that the experience is not something you can just have as a side effect.
We build stuff into Loco that Rails has, try it out, then decide if it's "Railsy" enough in the experience. If it's not, we delete it and try again.
I'm a Rails superfan personally, however as life turned out to me, I like Rust much more than I like Ruby. So the decision was to go "loco" and implement Rails for Rust.
We're looking for more feedback and people to try out Loco, please feel free to do so :-)
Great description of the problem. I enjoyed reading it, it’s almost like prose, great writing.
The solution I’m afraid is only one: solve smaller problems. There is no way a single person can solve a team’s problem as a side project. A small problem does not mean small codebase. It means small as in: focused, simple pain, simple solution, low amount of open questions.
Yes there is value to all of the other strategies mentioned. But if you want the root cause and the solution for this hydra effect it is the one I mentioned.
If you were born anywhere in the 80s, you might have spent the 90s and early 00s building side projects that you actually finished and felt no remorse over. That’s because scope was naturally small, problems were more focused, and there were multiple order of magnitude less options to choose from (in any domain: programming languages, libraries, interfaces, user flows, business workflows — everything was less)
Thanks!
We much prefer to have had Rails' activerecord, but activerecord has hundreds of person-years (maybe thousands?). So what we found was the best for the current lifespan of Rust and its ORM ecosystem
We're looking at Yew and Dioxus but kind of deciding to not decide yet. Frontend carries a lot of alternatives and generally brings in heavy discussions
Author here.
Thanks! I think Rails is still great these days. If someone can afford doing Ruby, they should definitely stick to Rails.
However if you're into Rust, this is the best I could do that is as similar to Rails but can preserve some of Rust's strictness
What I hate about this document is part of a bigger problem I see with the Python community.
It's written like a hate letter with a passive aggressive tone of finger pointing towards users of Python as the source of the never-ending Python 2-3 split. It says, between the lines: "YOU are part of the problem, stop using Python 2. We don't care about YOU anymore. Stop using Python 2".
I can think of ten other different ways to be more constructive and, generally, nice.
Whats the pythonic way to do dependencies? pip? pipenv? virtualenv? pyproject?
And how about Python 2 and 3?
</Sarcasm>
But seriously, I think there's no one way to do things anymore especially if it holds up productivity and effectiveness. Let the pattern matching begin.
That's it guys. Open source is done. Time to call it something else like Free Software and wait another 10 years until corporates will find a way to invade and monetize it.
PS: I've pushed my first "open source software" to freshmeat, sourceforge, so I'm allowed to be bitter about this.
Please don't. Not for beginners and not for veteran C++ programmers that want a refresher. I've been polyglot for the last 20 years, and as I've expanded my skillset through the years, I've let C++ go 15 years ago. With C++14 popping up, I gave it a try and liked the feeling - so I've decided to first go through the agonizing process of refreshing my memory (agonizing because it hurts to see how much you forget, being once considered "an expert"), and then figure out what's the delta towards C++14 and learn it. Obviously I went straight to the "Effective X" series thinking it should be a no-bullshit intro for an experienced developer.
Acknowledging Scott Meyers is a great author, I'd say something morbid happened with this book. It feels that Scott simply bashes the language more than it introduces it - while he's obviously very knowledgeable and in the details he spots out glitches, pitfalls, death traps, and WTFs and keeps throwing these waves of "here be dragons" at you, that half way through I just quit reading it and quit attempting refreshing my C++ knowledge after my 15 year break up from it.
You should get Stroustrups' "A Tour of C++" - it is a softer, more cheerful and proud book that'll motivate you (and god knows you need motivation with C++).
While everything he says is true, and I don't want to say "it's better not to know these things", since then half a year passed and I gave modern C++ another try _without_ this morbidness to follow my attempt. I've been happy following "soft" intros into modern C++, without the bummer parts. Truth be told I haven't bumped into what Scott has kept highlighting - yet.
So I would say Effective Modern C++ is for very experienced C++ developers with fresh memory of how the internals work.
20 years journeyman here. If I could write my experience I would write what you did word by word about my feelings with Go and Rust. And I've tried many times - you nailed it.
As an aside, I keep seeing people don't "get" this, and it is painfully unclear to me - why?. Perhaps the pool of people with 15-20 years that are still doing programming is very small, so they make very tiny noise.
However when the ruby community moved to Puma which is based on both processes and threads it was needed less. Not that this is rocket science (it's still far behind the JVM and .NET), I assume a hybrid process/thread model is something that hadn't reached a critical mass in the Python/Django/Flask/Bottle community?
I'm not being sarcastic at all, and after reading my post again I can't see how it can be read that way. My apologies if my english isn't that good.
I'm familiar with piston, and by "making it build on a Pi" - my mistake, I meant make it cross-compile for a Pi.
The rest of your examples are quite "it can be done" and not it "should be done".
The only thing I can say is - why not organize a game competition around piston? I'm sure Mozilla has the funds. This is what I mean by make it fun and make a game framework. I'm sure that other than piston you could find other Rust game frameworks but i'm sure you can't find one that's as accepted as PyGame or LOVE, and then, Cocos2d-x C++ port is being pitched "for performance", and why can't that be Rust?
We've met at Rails conf, in Tel Aviv many years ago. You seemed nice, so I'm motivated to try to give you my 2c.
I believe Rust can be more than safety but right now it isn't as you are imagining it.
I've started off in the demoscene in the early 90's, and so I've had my share of assembly, C, and C++ as a kid. I've built demos, games, generative 3D art with 8-64kb executables, without access to Internet or any form of proper knowledge, and it's funny how scared I am of attempting this again today when I'm much older, and much, much more experienced. I think one of the scary factors are the time-to-value ratio: I'm used to several orders of magnitude more productivity, and have much less time.
I think the most important take away from my background story that you can adopt is - make Rust playful. Fun is a a base element for curiosity, it what drives us where we're the most receptive - when we're kids - to learn, to experience, and to understand what will in be our toolbelt for the next dozen years.
Make rust playful. Make a game framework. Make it build on a mobile device. Make it build on a Pi (without docker, and the entire diarrhea of toolchain you have to use). Make it build for the Arduino. Cross compile it to Javascript (for fun!).
Often I try my hands at C and C++ again. When I do that, I'm not disappointed. I see a comforting place where I've spent my childhood at (and with C++ - some of my professional life). I'm happy with how C++ evolved and how CMake works. I'm not happy because productivity didn't change for the better that much. It still requires around the same amount of time to build things in C and C++ as it did years ago.
Where I do see a change is with Go. It gives me the same comfort, with an insane productivity factor. It also had fun baked in from the start - it can run on mobile, it can run games, and it can compile to what ever I want without a fuss.
I hope my thoughts will make a real change. I really do think this is the missing part with the Rust story.