[nickjj]

I think it would be hard for Elixir to replace Python or Go for general purpose CLI tools.

Part of what makes Python nice is it's available everywhere. If you have a zero dependency CLI tool, using Python is nice because you can just run the script straight up. The standard library also has good support for argument parsing. I've written a bunch of little tools to help my daily workflow on the command line. I always reach for Python or Bash depending on what I'm doing. I haven't really seen a compelling reason to switch.

[romanoderoma]

> using Python is nice because you can just run the script straight up.

except when it doesn't work

which happens more often than not

Elixir is not probably best suited for CLI tools, given the BEAM has slow startup times, but people wrote scripts in Ruby, so it might be acceptable for someone

Elixir scripts can be distributed as releases which include the compiled modules bytecode and the VM to run them or as escripts, which are binary executable that can be run on any system with Erlang installed

[deltron3030]

New Elixir thread -> nickjj pointing out the superiority of Python or Ruby. Lol!

[nickjj]

> New Elixir thread -> nickjj pointing out the superiority of Python or Ruby. Lol!

Not really. He asked a question about using Elixir as a general purpose programming language so I gave my honest advice and opinion on using it as a scripting language based on prior experience.

Instead of cherry picking my replies out of context, why not go through my entire comment history in all Elixir and Phoenix HN threads? I'll guarantee you'll find tons of positive comments.

Here's a couple to get you started after spending 60 seconds searching:

- https://news.ycombinator.com/item?id=20267184

- https://news.ycombinator.com/item?id=20357572

- https://news.ycombinator.com/item?id=17616692

- https://news.ycombinator.com/item?id=18838449

The first two have over 100 up votes combined for reference.

I'm not looking to argue on the internet, but I do find it strange that so many folks in the Elixir community cannot take any constructive criticism of the language in any way. You realize we're all on the same team right? To build kick ass applications that we enjoy building while users enjoy using it.

[dnautics]

Just gonna say, I'm pretty upfront about when not to use elixir, and I have found your attitude to be very pessimistic across several platforms.

[deltron3030]

You just stick out as somebody who's always complaining, mostly on the official forums.

[nickjj]

I see it more like asking questions, offering suggestions and potentially trying to improve the language and eco-system by offering feedback and sometimes even pointing out things that hang me up.

For example, the other day someone asked if Phoenix could ever support similar features of Rails such as having something similar to Rails Application Templates. I thought it was a great idea and it was something I wanted too, so I gave as much feedback as I could around why it might be useful to have.

In the end, it looks like most people don't want such generators, or having an ability to build a community around templates like Rails, Laravel and Python. That's based on only a few people commenting to say it's not a good idea and pretty no one else replying saying they wanted it.

You might see that as complaining but I see that as trying to fight for a really useful feature that will help grow the community and make it easier for folks to build applications in the end.

If I didn't care I would have left the Elixir community long ago. I have way better things to do than troll forums. The project I was gung-ho about developing in Phoenix is no longer using Phoenix because after all of those forum posts and struggling endlessly with Elixir I came to the conclusion it isn't the right technology for me to build web apps in. I continue to sometimes post because I hope one day things will change and I'll try to pick it back up again when the community and eco-system is more mature (from a library selection POV, not personal maturity).

[triplejjj]

The issue is that there is a gap and if you won’t learn the language nor use it, the gap won’t ever be closed.

For example, you said elsewhere a solution was complicated because it used io lists and a binary constructor but both concepts are explained in Elixir’s official getting started guide. So sometimes it feels you are saying things are complex while you don’t seem to be actively learning the language and some will definitely find that frustrating.

It would be the same if I went to Rust forums, a language I haven’t yet studied in any depth but read a lot about, and constantly said the ownership mechanism is complicated.

Apologies if this comes up as rude. You do seem to be a person open to feedback, so I thought I would drop my $.02.

[nickjj]

Thanks.

It's not so much an unwillingness to learn.

It's not being able to write what I think is intuitive code and let's be real now. Programming is all about using tools that make you happy and productive. That's why there's so many different viable choices.

For me, personally (opinion of course), I don't want to have to worry about using binary constructors or io lists instead of strings every time I want to work with a string. I just want to use strings. Fortunately other languages can work with strings efficiently so I don't need to concern myself about such optimizations. I can just focus on the business problem at hand.

When stuff like this happens all the time, yeah, it gets frustrating and eventually you decide a tool isn't right for you. I think I gave it a fair shake too. I wrote a pretty big app twice in Phoenix, once with and once without Live View. I even delayed shipping my product for over a year waiting for Live View to get more fleshed out. And even then it felt like I was pioneering things because I kept running into severe bugs (which I reported).

The lack of libraries is kind of the straw the breaks the camel's back. I can maybe get beyond some of the language issues if it lets me be super productive but I found myself having to implement so many libraries myself because there's no official libraries available for Stripe, AWS, etc.. It just lead to feeling like I was spending more time writing libraries than developing my own app.

In time I hope the Elixir compiler could be smart enough to make optimizations for you behind the scenes and maybe there will be more libraries in the future too. In time Live View will get more fleshed out and polished as well, which is always welcome.

[deltron3030]

>You might see that as complaining but I see that as trying to fight for a really useful feature that will help grow the community and make it easier for folks to build applications in the end.

The change in mindset you're demanding from the devs is impossible to accomplish through comments I think. You'd need to develop personal real world relationships with the devs to be able to have such an impact, or create pathways for people with this mindset into the community.

It's the mindset of DHH or Taylor Ottwell what makes their product oriented frameworks more product oriented. Core devs and core parts of the community having this mindset is necessary as a fruitful foundation for more product oriented feature requests I think.

[nickjj]

> It's the mindset of DHH or Taylor Ottwell what makes their product oriented frameworks more product oriented.

Yeah I totally 100% agree with this. I think it's very much so why Rails and Laravel won't be going anywhere anytime soon. As it turns out most people who are into web development are trying to build products and services.

But I will say that every time I've talked to Jose or Chris (I don't know them personally, I just mean in chat), they always say the best way to offer suggestions or feedback about the language or framework is to post on the forums. It's just unfortunate the community is so against feature requests or open to talking about things.

It just feels like the forums have the same regulars shooting down ideas from anyone new, or feature request threads get little to no replies.