Just picked up Programming Elixir and Programming Phoenix . Once I’m done with those I’ll certainly subscribe to https://www.learnelixir.tv/.
My holidays are now booked! 
2 Likes
http://elixirsips.com/ is quite similar but has far more apparent content.
Another good resource is https://elixirstatus.com/ which seems to be the Elixir equivalent of crater.io. I think you’ll notice a few Meteor community names there.
Of all the transpiled languages I like DART the most. Shame though that nobody likes Google and it went nowhere.
3 Likes
The thing with Typescript is this is not a transpiled language but a superset of JS.
We could call it the future of javascript.
I guess/hope that TS types will be introduced in vanilla JS in ES8.
3 Likes
Good call on removing that
1 Like
What are you talking about? I read @sonicviz’s post and didn’t see anything wrong with it.
If you have time to burn and like to learn, it’s fine I guess to chuck good tech for something new.
If you have business problems to solve, and the tech you’re using can solve them to your liking, then chunking the tech for something else just because it’s new is just… IMO unreasonable, irrational, and illogical.
Now that’s not to say one shouldn’t evaluate new tech from time to time when it makes sense – for example if the current tech you’re on can’t do what you want it to do – but chunking what you have and starting over on a project just for the newness is as I said above.
But it all just depends on your state of mind, where you’re at in your life, and the time you have to burn I suppose – to each his own.
Cheers!
2 Likes
sed -i -e ‘s/newness/performance/g’ fify.txt
2 Likes
I almost left it, but then read a later post by ryan where he did make a point about time sink and time constraints so I decided he didn’t need me to make the point;-)
But tech stack jumping (or the jumping on the javascript crazy train as commitstrip eloquently puts it) is a problem, especially in the JS world.
I have an upcoming article on the Ziptask blog on this topic (ie: evaluating a framework).
It’s about Meteor, but I do give a tip of the hat to Phoenix.
I like to think I’m tech agnostic now days. It’s just time is the issue.
and hammers, nails, and constraints!
But really people, evangelizing about platforms is soooooooo 2014.
I agree with that 100%. I’ve never once advocated for dumping a tech stack (or the software your business is built on) just because there are newer alternatives. @nickmaddren asked why someone would look for an alternative to Meteor and in response I listed a number of reasons why I believe someone would look for an alternative. In addition, I made a pretty lengthy list further up the thread. Phoenix as a Meteor alternative
@sonicviz selected just one of the things that I’ve said in this thread and then lectured me as if it was the only thing I’ve said. Here is the quote he singled out:
Here is the quote from his deleted post:
"I found this thread interesting as I’m currently working with Meteor but keeping my eye on alternatives, but have to say that is the worst reason to ever use to switch to another technology platform.
It’s completely illogical and has no basis in a platform evaluation when people want solid actionable decision criteria based in facts. There’s more criteria to evaluating a tech solution than “I’m bored” or “it’s so cool” or “I just don’t like how they do [insert here]” Yes, you did add more but you led with this one."
Note the part where he says, “Yes, you did add more but you led with this one.” This is what I said at the top of the post he is criticizing.
He quite literally pulled one thing I said out of this entire thread just to troll me. His critique was neither fair nor with merit.
5 Likes
No, not to troll you.
Because if you were seriously promoting a technology solution that would be the last reason you use, if at all.
You’re not making yourself look too good.
3 Likes
Not at all, I stand by that. Maybe you should think about it a bit more?
Oh the irony. Perhaps had you followed your own advice you would not currently be in such a “precarious situation” ?
Back on topic: I’m halfway through Programming Elixir and love it!
1 Like
I’m not sure that’s a fair comment.
The way MDG informs the community of technical direction (or lack of it in the past) is a risk factor you can pick up reading the forums. The fact they made a community blog post on the directional change that sparked a brush fire of response is actually a good sign that they are aware. Hopefully they will listen to the people most vocal about the business stability of using Meteor as a tech choice being vital and put more effort into supporting this via a smooth transition process.
It’s also possible to tick all the evaluation boxes and still get burnt by a tech platform/company.
History of the web is littered with those kind of stories. And apps for that matter.
At some point you have to decide whether the benefits outweigh the risks for your current use case and start developing. That includes other factors like time, resources, skills etc as well.
I may be wrong but Phoenix seems to me to be at the same stage Meteor was in 2013, more or less, and has it’s own risk factors. It’s not immune and you would be making a mistake to think so.
Getting back to the point I was trying to make with ryan (in my typically direct Australian manner;-) this recent post nicely sums up the core issue to me, when trying to pitch a new tech:
"React has become very popular among developers and there are lots of resources that speak to its technical merits. However, migrating to (or choosing) a new framework ultimately comes down to selling it to everybody at the table — including non-technical people — and few engineering managers or PMs would agree to a re-write just because it’s the shiniest new thing. Worse still, many organizations have been burned by the high churn in JavaScript tooling, which sadly moves projects backwards as a part of moving the web forward. This post is not an attempt to teach you something new about React. It is an attempt at the Executive Summary; a starting point for your pitch to try to sell not just developers but everybody on the wonders of React."
https://blog.formidable.com/using-react-is-a-business-decision-not-a-technology-choice-63c4641c5f7#.xvzym8xjc
3 Likes
Mate, I don’t want to get down in the dirt with you, so I’ll take that with a smile. 
Listen, if you read what I wrote then it becomes clear your comment actually takes such a narrow view of what I said it becomes a distortion.
The thing is I’m not going to chunk what I have now for something new (React) just because it’s new mate, I’m going to slowly migrate over to React because if I don’t, I’ll be in a real quandary at some point not too far off for all the reasons I mention in that comment you linked to.
Have a good weekend mate,
Cheers!
@sonicviz, the posts that I’ve read from you have been balanced and well thought out so far mate. Your last post, where you go into React, I think would be welcomed in the ‘Next steps on Blaze and the view layer’ thread too.
The “Phoenix tutorial” that is declining in popularity is the software for flashing Nokia phones called Phoenix. (See the related keywords below the main chart.) I don’t think that the Elixir framework is represented on that page.
(Sorry, I didn’t see the other replies when I posted this. Here’s another (imperfect) query though.)
3 Likes
I’m not as far along as you business wise as I’ve only done an MVP with Meteor, but I understand the position MDG has put you in and others in.
MDG needs to put business stability first over features.
I’m still 50/50 on whether big React push actually a solid technical decision driving it (why not Angular or as people point out keep their own) or Investors are pushing it in that direction hoping to move it closer to being an acquisition target.
re: Phoenix
I have some other potential projects on the boil so I’m willing to investigate Meteor alternatives.
I understand why people get excited about new technology and platforms but I wish the evangelism would take a backseat to objective tech and business eval criteria.
1 Like
Meteor is making a sound technical decision by future proofing the tech stack, allowing you to use whatever front-end you feel like. It’s not exactly code to interface, but it’s thankfully moving in that direction.
http://www.angular-meteor.com/
This includes angular, which will likely end up having better integration than react in the long run. MDG hired a single React dev, who doesn’t appear to really do much. Meteor claims to be working directly with the Angular team through Ugio, who appears to be doing quite a bit.
You seem to think there are not objective criteria at play and it’s all about shiny objects. Nothing could be farther from the truth.
For some folks being able to scale beyond 100 concurrent users is a business requirement. For some folks having an ACID compliant database is a business requirement.
Phoenix solves both of those meteor limitations.
Many of the folks discussing Phoenix in this thread have running meteor production applications and wish to solve those issues. They are in fact objective business and technology requirements.
1 Like
Not at all, but you don’t have to read to far into the thread to see elements of both. Which is what I was referring to.
Scaling and DB are two great examples.
However…
Pulling numbers out of thin air doesn’t help your argument, especially after what you just wrote above.
It makes you look like you’re suffering from Maslow’s Instrument law.
Where’s your evidence Meteor peaks at 100 current users? Because you’re implying Meteor is not the correct tech solution for > 100 concurrent users. I don’t think I misinterpreted that, seeing as you explicitly say “Phoenix solves both of those meteor limitations.”
Ditto for ACID db. MongoDB may be the official db but there seem to be people using it with PostgreSQL, for example.
Concurrent issues are debated quite well here: How Many Simultaneous Users Does the Biggest Current Meteor App Support? - #13 by serkandurusoy
Also:
“This meant around 200 concurrent users on the site for a whole day, with peaks around 250. And I have to say the app held up just fine, with no noticeable slowdowns or issues.” +
“A large Meteor app like Telescope will comfortably scale up to at least 200-300 concurrent users, which is more traffic than being #1 on Product Hunt will get you (in other words, more than 99% of websites out there will ever receive at once).”
http://www.telescopeapp.org/blog/screenings-launch-meteor-scaling-case-study/
Kadira has also done some heavy meteor scaling way beyond these levels afaik.
I get it that Phoenix/Elixir has been engineered for high concurrency.
Not surprising considering where it came from.
There’s plenty of use cases where using Meteor isn’t the best solution.
I’m sure the same also goes for Phoenix.
I fully agree with you on objective business and technology requirements.
2 Likes