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?

Wow! fantastic!

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?

Hi Steve,

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.

You mean a select few programmers do. And even if you've struck gold and all of your programmers are from the 90's so that they know what it means to manage memory manually, the landscape - the code - always changes and so will the trade off. The deal is that you want to deliver software quickly and make sure it performs adequately, but no one needs perfectly, in regular business.

Jetbrains keeps delivering knock outs. I love you guys.

An all encompassing answer would be - the abstractions. Why would you use an operating system if really you have your CPU documented and know all of the instruction sets?

http://www.rabbitmq.com/consumer-prefetch.html

You are hand-waving many properties of purpose-built queue systems.

Context definitely matters - thanks for the background info. I understood what you're trying to do, incidentally I did the same (all these details sound familiar to me). At the time, Storm helped me batch, break batches and validate discrete units, re-batch, aggregate, repeat that process how many times I wanted, and finally, batch the stream with a strategy I wanted (number of users, messages, or balance number of connections) and deliver to Google.

Then I would just say, XMPP is new and fancy, but consider the old fashioned stateless HTTP interface. When I was implementing my own service, I was worried Google is not going to handle the load. Since we were partners with Google for a good while I was able to climb the ladder of people to get an answer, and plow through their closed-door policy for questions such as "Will you guys handle this load? (5M msg/min)". I wrote a huge email explaining every edge case and what I'm doing. The answer was "We will handle it.". No detail, no context, no buts. I wasn't confident at all. But in the end, they did handle it :)

Hate to be a party pooper, but I'd like to give people here a more generic mental tool to solve this problem.

Ignoring Elixir and Erlang - when you discover you have a backpressure problem, that is - any kind of throttling - connections or req/sec, you need to immediately tell yourself "I need a queue", and more importantly "I need a queue that has a prefetch capabilities". Don't try to build this. Use something that's already solid.

I've solved this problems 3 years ago, having 5M msg/minute pushed _reliably_ without loss of messages, and each of these messages were checked against a couple rules for assertion per user (to not bombard users with messages, when is the best time to push to a a user, etc.), so this adds complexity. Later approved messages were bundled into groups of a 1000, and passed on to GCM HTTP (today, Firebase/FCM).

I've used Java and Storm and RabbitMQ to build a scalable, dynamic, streaming cluster of workers.

You can also do this with Kafka but it'll be less transactional.

After tackling this problem a couple times, I'm completely convinced Discord's solution is suboptimal. Sorry guys, I love what you do, and this article is a good nudge for Elixir.

On the second time I've solved this, I've used XMPP. I knew there were risks, because essentially I'm moving from a stateless protocol to a stateful protocol. Eventually, it wasn't worth the effort and I kept using the old system.

If by framework you mean web framework, I've used Dropwizard. It's a lean and mean modern-java option, and it's not a Kotlin native thing (you do have these). You can use any Kotlin or traditional Java framework out there transparently (that's a good value of Kotlin).

For ORM, Dropwizard and its ecosystem got you covered.

Also dropping out to Java when ever you want can be done in the same project (which I encouraged) seamlessly both in terms of how Java and Kotlin interoperate, and in terms of Intellij, which is first-class in both languages because Kotlin is Jetbrains' baby, and, because Java has been best supported by Intellij for ages (can't really find that kind of thing anywhere else).

While this is a good overview of why _they_ chose Vue over React, I wouldn't risk deriving that you should do the same too.

To balance the scale a bit, this is what they gave up, in favor of "shit that just works" (because this is the tone I'm getting from the article):

1. They decided they want off the enormous driving force for developer experience that is Facebook, and more importantly the Facebook codebase that shapes decisions in React, see [1] and [2].

2. They opted out of major innovation that directly stem from (1), see [3].

3. Parting with Redux, they also decided to part with a community that thinks functionally. This is a big deal not because of writing "pure functional code", but because these group of people can reason about the implications of bad citizenship on the browser - which really, is something the Javascript community really needs.

4. Moving away from functional-esque (for lack of a better term), they also move away from predictable testing. Forget purity and sideeffects. A good litmus test - think about how easy it is to test any given framework at scale, and if a framework is "built with testing in mind" (read: angular) how many hacks would be involved. When you have good foundations for testing, you can do this [6] and be sure everything can be covered [7] .

The only thing I see as a down side with React is the bundle size. The physical size. However I'm not worried one bit because of (1) and (2).

For Redux, I take the liberty to use MobX for small-medium projects (which probably is the overwhelming majority of projects), and Redux for large projects, or projects that I want great testing story in (in many ways these correlate, but some times they don't).

Redux is "boilerplatey" because it is highly granular. This is why the ecosystem around it exploded. But because of (3) the ecosystem around it has a sharp focus around the patterns and practices it applies, which makes choosing the "wrong" library not such a big deal; in a sense its ecosystem is predictable, because it is simple.

JSX or templates, I don't think this deserve a major part of the discussion. Both ideas exists for a long while, and even their predecessors exist for more than a few decades [4] and [5]. I don't think anyone is tilting the scales any where in a major way. I personally am convinced JSX is a new thing because you have first-class IDE support across the board (which you don't have for a given data-properties backed templating language unless it becomes ginormous like Angular). JSX is also simple to hack and you can opt-out or implement your own dumb-templating solution-to-JSX.

Having said that, I see Vue coupled with PHP quite a bit, like, it's an informal standard stack, so it may make sense if you're coming from PHP (but then again so did Facebook, right?). Maybe someone can explain that (is it the Laravel backing?).

[1] https://facebook.github.io/react/contributing/design-princip...

[2] https://facebook.github.io/react/contributing/implementation...

[3] http://isfiberreadyyet.com/

[4] http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...

[5] https://en.wikipedia.org/wiki/XSLT

[6] https://facebook.github.io/jest/

[7] https://medium.com/@jondot/how-to-snapshot-test-everything-i...

Last I've heard, Twitter was "stuck" with their own version of Scala (was it off 2.10?). Typesafe becoming Lightbend (i.e. not Scala focused anymore) for doing business, Odersky moving all of his focus to Dotty, and core Scala contributors leaving. That's my intuition of asking.