jondot

its like someone-shut-down-the-power 500s

LinkedIn is down

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).

Disclaimer: I'm one of the authors of Loco.

Loco author here.

Thanks for the shoutouts!

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.

Brilliant!

Thanks Jose!

I was hoping to catch you here or on IRC :)

Anyone else worried about the long-term outlook on Elixir for adopting it now in bigger companies? (leaving OTP out, of course)

* Bus factor of 1?

* No visibility of improvement process (i.e. PEP)?

* Long term support?

How would you resolve this? do consultancies that build projects for clients in Elixir are aware of that? or notify the client of that?

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.

This is called out of band GC. We've been doing it for years in Ruby with Unicorn https://blog.newrelic.com/2013/05/28/unicorn-rawk-kick-gc-ou...

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?