learn-phoenix - GitLite

KO | EN

gitlite — search

#hacktoberfest #ai #golang #machine-learning #docker #macos #nodejs #windows #awesome #kubernetes #awesome-list #vue #security #openai

learn-phoenix

(★ 663)

🔥 Phoenix is the web framework without compromise on speed, reliability or maintainability! Don't settle for less. 🚀

파일 탐색기

최종 버전 다운로드 (.zip)

- - video_player_control.js
  - video_player_join.js
- - .gitignore
  - coveralls.json
  - mix.exs
  - mix.lock
  - mkdir
  - README.md
- basic-test.exs
- README.md
- api-server.md
- caching.md
- deploy_umbrella_app_to_azure.md
- ecto-multi.md
- forgot-password.md
- heroku-deployment.md
- nginx-proxy-multiple-apps.md
- nginx.config
- production-deployment.md
- sending-emails.md
- simple-server.md
- tutorial.md
.gitignore
CONTRIBUTING.md
README.md

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/dwyl/learn-phoenix

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd learn-phoenix

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. Node.js

쉬움 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
Node.js npm 명령어를 쓰려면 Node.js가 설치되어 있어야 합니다. LTS(장기지원) 버전을 추천합니다.

cd examples/channels/rumbl

이 프로젝트의 관련 파일이 하위 폴더 안에 있어서, 먼저 그 폴더로 이동합니다.

npm install

package.json에 명시된 라이브러리들을 내려받아 설치합니다.

npm start

개발/실행 서버를 켭니다.

✅ 명령어 실행 후 터미널에 나타나는 주소(보통 http://localhost:3000 형태)를 브라우저에서 열어보세요.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

<div align="center">

<img alt="Learn Phoenix intro image"
src="https://github.com/user-attachments/assets/88381bd7-1663-46d2-b27f-2a01ae412896" />

Learn how to use the **`Phoenix` Framework** to
**_enjoy_ building _real-time_ web/mobile apps** <br />
that are **_fast_** for "_end-users_", **_reliable_**,
**_scalable_**, **_maintainable_** _and_ _easily_ **_extensible_**!

![GitHub Workflow Status](https://img.shields.io/github/actions/workflow/status/dwyl/phoenix-chat-example/ci.yml?label=build&style=flat-square&branch=main)
[![codecov.io](https://img.shields.io/codecov/c/github/dwyl/phoenix-chat-example/main.svg?style=flat-square)](https://codecov.io/github/dwyl/phoenix-chat-example?branch=main)
[![contributions welcome](https://img.shields.io/badge/contributions-welcome-brightgreen.svg?style=flat-square)](https://github.com/dwyl/learn-phoenix/issues)
[![HitCount](https://hits.dwyl.com/dwyl/learn-phoenix.svg)](https://github.com/dwyl/learn-phoenix)
</div>

## _Why_? 🤷‍♀️

As web/mobile app developers we _need_ to _leverage_
the work that other (_really smart_) people have done <br />
instead of constantly building things "_from scratch_" all the time;
that is _why_ we use _frameworks_ to build our apps!

> See: "**Top 10 Reasons Why Phoenix**" (_further down this page!_)

There are _many_ frameworks to choose from
(_a **few** popular ones are mentioned **below**
in the **Questions** section_).
But if we go by what is "_popular_" we'd
still be **riding horses** (_and carts_) everywhere
and **no _progress_** would be made. <br />

<!--
Phoenix is like having a
[***jetpack***](https://youtu.be/H0ftAwlAB9o) (_with **unlimited free environmentally-friendly fuel**_!!); <br />
it gets you (_your app_) to where you need to be ***so much faster***! <br />

_Seriously_, once you _deploy_ your first Phoenix app
_**you will feel** like you're **freakin' Iron** ~~Man~~ **Person**!_
![iron-man-flying](https://cloud.githubusercontent.com/assets/194400/22628358/9ca42c58-ebca-11e6-8729-bc0103284312.jpg)
You won't want to "_walk_" anywhere (_use a lesser means of web development_)
_ever again_!
-->

> **Note**: **all** the reasons "**_Why_**"
for **`Elixir`** _also apply_ to **`Phoenix`**! <br />
check them out:
[dwyl/**learn-elixir**#**key-advantages**](https://github.com/dwyl/learn-elixir#key-advantages-) <br />

## _What_? 💭

A web application framework **_without compromise_**! <br />

### Developer Joy 😍

The biggest "_constraint_" in any technology project is _people_.
An "Entrepreneur"/"Founder" or "Product Owner" can have all the _good ideas_
in the world, if they are _unable_ to convert idea into _reality_,
it's _meaningless_.

<!-- commenting this out because I think it's too "hyperbolic" ...
### Metaphor

You can spend ages (_and **mountains** of **money**_)
"***performance tuning***" an
["_old banger_"](https://en.wikipedia.org/wiki/Decrepit_car)
_trying_ to make it **go _faster_**<sup>1</sup> ...
![car-mod-fail](https://cloud.githubusercontent.com/assets/194400/22628288/41afc3d0-ebc9-11e6-98f3-67a1bc3a1411.png "Click image to enlarge for full glory!")

***Or***... _get_ the [**_best_ car**](http://www.cnbc.com/2015/08/27/teslas-p85d-is-the-best-car-consumer-reports-has-ever-tested.html) built for speed, safety and environmental friendliness and ***stop wasting time*** on the past!

![model-s-photo](https://cloud.githubusercontent.com/assets/194400/22628333/e8a107ee-ebc9-11e6-9140-6be11cdddd87.jpg "Tesla Model S") <br />
<small>_**Note**: with Phoenix,
you're getting a [Tesla Model S P100D](https://www.tesla.com/en_GB/blog/new-tesla-model-s-now-quickest-production-car-world) for the "price" of a Ford Fiesta!
A **logical** choice, **right**_?
</small>

Just like there is an _entire industry_ involved in "_tuning_" distinctly
"_average_" cars (_that weren't made for high performance!_)
there's a similar one for "_optimizing_" slow web applications.
Organizations end up spending _way_ more time and money
(_"engineering" consultants and server resources_!)
trying to make their "_old tech_" scale or serve more (_concurrent_) users,
than they would simply making smarter tech choices
(_and avoiding ["sunk cost bias"](http://www.lifehack.org/articles/communication/how-the-sunk-cost-fallacy-makes-you-act-stupid.html)_).

<sup>1: car mod fails:
[ridelust.com/30-custom-cars-from-around-the-world](http://www.ridelust.com/30-custom-cars-from-around-the-world)
and [bobatoo.co.uk/blog/the-10-worst-car-modifications-ever](http://www.bobatoo.co.uk/blog/the-10-worst-car-modifications-ever)
</sup>
-->

### (Should I _Care_ About) Benchmarks? 📊

_Obviously_, you should run your _own_ benchmarks on your own hardware/cloud
and make _informed_ decisions based on the _requirements_ of your app/product,
but ... when we _read_ the stats for how many **_concurrent users_**
a Phoenix App can handle (_with live WebSocket connections_)
we were _blown_ away!
It means we can build our real-time app(s) with 90% fewer resources.

### Performance Highlights ✨

+ **_considerably lower latency_**
  and request response time than _anything_ else!
  (_thanks to Erlang's lightweight processes and ultra-efficient network/message handling_)
+ **_4x_** more requests-per-second than the
equivalent `Node.js` (_`Express.js`_) App.
+ **_9x_** more throughput than a `Python` based app. (_blocking really sucks!_)
+ **_10x - 100x_** more requests handled than `Ruby-on-Rails`
(_depending on the type of app!_)
+ _Similar_ performance to **Go** on a _single server_,
but a **_much_ simpler multi-server concurrency model**,
so **_horizontal scaling_** across multiple data centers
("availability zones") is _much easier_!
(_Erlang manages the resources
  for multiple servers/processors as a single app "fleet"
  and delegates requests/processing to them across clusters/zones_!)

All of this means that you spend _considerably_ less money
on Hardware/Cloud infrastructure so your app/company
can gain a **_competitive advantage_** on **cost**.

>If you are in the _fortunate_ position to be _considering_ using
something _way better_ for your _next_ project,
look no further than Phoenix! <br />
> Read more:
> [phoenixframework.org](http://www.phoenixframework.org)

Where there is a specific high-performance function needed
the BEAM VM also makes it easy
to integrate `Elixir` with lower-level code.
There are libs that make this easy, 
such as `Rustler` (for `Rust`) and `Zigler` (for Zig).

## _Who_? 👩🏻‍💻

_Many_ people/teams/companies are _already_
using Erlang/Elixir and Phoenix and seeing phenomenal results! <br />
Including: `Adobe`, `BBC`, `Spotify`, `Pinterest`, `Discord` (Gamer Chat App),
`Groupon` (Fave), `Lonely Planet`, `Brightcove`, `Slack` ... <br />
See:
[/elixir-companies](https://github.com/doomspork/elixir-companies)

### Who _Should_ Learn Phoenix? 🥋

+ People who want an _easy_ way of
building an app with all the modern conveniences of "generators",
built-in Database interface ("ORM") and **_Firstclass WebSockets_**
for "real-time" while getting **_legendary_ reliability**.
+ Teams who need the developer productivity or `Ruby-on-Rails` or `Django`,
but want less "magic" (_i.e. want to **understand** how everything works!_).
+ Companies who want to **spend 90% less** on both developer
and infrastructure costs
so you can serve more people with fewer resources.

### Who Should _NOT_ Learn Phoenix? 🚫

+ Anyone who needs to use the "_most popular_" framework or language
(_for whatever reason_).
+ Companies who already have lots of legacy `Java` / `PHP` / etc.
and cannot invest the time to learn/use something new.
+ Developers who want "_job security_" bug-fixing unreliable code.

## _How_? 👩🏻‍💻

### Assumptions / Pre-Requisites?

The only recommended learning _before_ diving into `Phoenix`
is learning `Elixir`.

### `Elixir` 💧

You _cannot_ build a `Phoenix` App without knowing `Elixir`. <br />
If you are new to `Elixir`, "star" (_bookmark_) `this` repo
(_so you can return to it tomorrow_)<br />
and then go to:
[dwyl/**learn-elixir**](https://github.com/dwyl/learn-elixir)
learn `Elixir` until you feel like you _understand_ the **syntax**,
then come back and learn `Phoenix`!

_Specifically_ you should focus on learning the `Elixir` "Basics":
+ types of data
+ atoms
+ pattern matching
+ maps
+ function definitions
+ modules

### Installation ⬇️

If you've already learned some `Elixir`, then
the first step to getting started with `Phoenix` is installation!

The `Phoenix` documentation is amazing, so we recommend following the
[official phoenix installation instructions](https://hexdocs.pm/phoenix/installation.html)

You'll also need to install `PostgreSQL`,
there is a tutorial of how to do so
linked in the `Phoenix` installation guide linked above, but you can also check
out our
[`learn-postgresql`](https://github.com/dwyl/learn-postgresql)
repo
for instructions, and raise an issue if you have any trouble!

While a _basic_ understanding of `JavaScript` _can_ be useful at times,
you don't _need_ it to use `Phoenix`.

### _Next_? ⏩

_Familiarize_ yourself with the "Up and Running" (_official_) guide:
https://hexdocs.pm/phoenix/up_and_running.html#content
![up-and-running](https://user-images.githubusercontent.com/194400/47036724-fca6c700-d174-11e8-9cd8-26f0ef0147e8.png "Phoenix Up and Running Beginner Guide")

### _Practical_ Examples? 💡

Once you have phoenix installed
and followed the _official_ "up and running" guide, <br />
come back and try these **_beginner-friendly_ examples**:

+ **Counter** (_realtime shared counter using Phoenix LiveView_):
[https://github.com/dwyl/**phoenix-liveview-counter-tutorial**](https://github.com/dwyl/phoenix-liveview-counter-tutorial)
+ **Todo List** (_step-by-step tutorial showing how to build a fully functional TodoMVC clone_):
[https://github.com/dwyl/**phoenix-todo-list-tutorial**](https://github.com/dwyl/phoenix-todo-list-tutorial)
+ **Chat** (_realtime UI/UX using WebSockets_):
[https://github.com/dwyl/**phoenix-chat-example**](https://github.com/dwyl/phoenix-chat-example)
+ **Encryption** (_security_):
[https://github.com/dwyl/**phoenix-ecto-encryption-example**](https://github.com/dwyl/phoenix-ecto-encryption-example)
+ **Append-only Log** (_how to store your App's data_):
[https://github.com/dwyl/**phoenix-ecto-append-only-log-example**](https://github.com/dwyl/phoenix-ecto-append-only-log-example)

### Book? 📘

When we started learning `Pheonix` in **2015**,
there was only one book written by
[@chrismccord](https://github.com/chrismccord) creator of `Phoenix`:
[**Programming Phoenix**](https://pragprog.com/book/phoenix14/programming-phoenix-1-4) <br />
Sadly, Chris has been too busy building `Phoenix`
and the book hasn't been updated recently,
so it's quite out-of-date.

Luckily in the intervening years,
_several_ great books have been published on the topic:
[pragprog.com/search/?q=phoenix](https://pragprog.com/search/?q=phoenix)

<img src="https://github.com/user-attachments/assets/649d674e-9a9e-4e30-9a59-922a8c932ca9" />

Any of these books is a good starting point.

Our comprehensive _free_ tutorials are also a great starting point.

### Video Intros 📺

<!--
[![Jose Valim - Phoenix a web framework for the new web](https://cloud.githubusercontent.com/assets/194400/22608108/e34aefbc-ea52-11e6-8694-9ac13c36db47.png)](https://youtu.be/MD3P7Qan3pw "Click to watch!") <br />
https://youtu.be/MD3P7Qan3pw

[![ElixirConf 2016 - Keynote by José Valim](https://cloud.githubusercontent.com/assets/194400/22608199/743b69d4-ea53-11e6-8153-e6655fc64453.png)](https://youtu.be/srtMWzyqdp8 "Click to watch!") <br />
https://youtu.be/srtMWzyqdp8
-->

**Code to the Moon** ([@MoonKraken](https://github.com/MoonKraken))
has a _superb_ (recent) intro to `Phoenix`
from the perspective of a `Rust` engineer with many decades of experience:
"The **Most Admired Web Framework**":
[youtu.be/RNMwz5n1M80](https://youtu.be/RNMwz5n1M80)

There are _many_ more superb `Elixir` and `Phenix` videos on `YouTube`
search is your friend:
[youtube.com/results?search_query=phoenix+1.8](https://www.youtube.com/results?search_query=phoenix+1.8)

> **Note**: remember to include the **latest _version_**
> of `Phoenix` in your query
> to get the latest results.

<!--

## Resources

+ Elixir vs Ruby Showdown - Phoenix vs Rails: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails
+ Benchmark: https://github.com/mroth/phoenix-showdown

-->

# _Our Top 10_ Reasons _Why_ Phoenix 🔝

> "_**Phoenix** provides the **productivity** of Ruby-on-Rails <br />
with the **concurrency** and **fault-tolerance** of **Erlang**_."

0. Beyond all the (_fantastic_) technical benefits,
  what attracts _us_ to `Phoenix` is the **_Great Community_**
  of people around the world who are _excited_ about making `Phoenix`
  an _amazing_ tool for building web apps! <br />
  Having
  [_welcomming_ people](https://github.com/phoenixframework/phoenix/issues/1624)
  who will:

+ help you when you get stuck, patiently explaining things
   + answer questions (_both
    ["**noob**"](https://elixirforum.com/t/defimpl-phoenix-param-to-override-to-param-causes-functionclauseerror-no-function-clause-matching-in-phoenix-param-rumbl-video-to-param-1/3987)
    and "**advanced**"_) and
   + **_openly discuss_** (_your_) _**ideas** for **improvements**_.

1. Phoenix uses the **`Elixir`** programming language which means your
app is compiled and run on the **`Erlang` Virtual Machine** "BEAM". <br />
`Erlang` is a battle-tested highly fault-tolerant VM used by
_many_ telecommunications companies

2. **WebSockets** ("_channels_") are a **first-class citizen** of framework
which means building apps with "real-time" communication and interaction
is _much_ easier than virtually _any_ other framework/platform!
(_no third-party `magic` module needed! **everything you need** is
  already there ready for you to serve **millions** of people!!_) <br />
see: 
[phoenixframework.org/docs/channels](http://www.phoenixframework.org/docs/channels)

3. **Easy _asyncrhonisity_** because all programming
in Phoenix (_Elixir_) is **_Functional_**!
This means it's _really_ simple to abstract useful functionality
like request authentication, logging and processing into "_piplines_"
that are easily ***human-readable***! (_no third-party `async` module required! no "promises", "generators" or "observables" to managed!!_)

4. **_Security & Resilience Mindset_** is the `default`.
**Encryption** (SSL) is **_easy_** in Phoenix/Elixir and
both **_mitigation_** of **SQL injection**,
**_Cross-site Scripting_** (**XSS**)
and **_CSRF protection_** are **built-in** (_enabled by `default`_) so
it's virtually impossible for a "_novice_" programmer
to introduce this type of security bug.

5. **_Concise Code_** cannot be _understated_! We can write _way fewer_
lines than in the _equivalent_ Node.js/Java/Rails/Go app, this means
developers are more _productive_ and there is **_less code to maintain_**!

6. **_Testability_** due to functional programming of all controllers!
7. **Easy Deployment**:
  [fly.io/docs/elixir/getting-started/](https://fly.io/docs/elixir/getting-started/)
8. **_Zero-downtime Deployment_** is **_free_**! (_again because of `Erlang`_).
   `Erlang` manages transitioning "_live/active_" users
   from the old to new version of your app
   without them even _noticing_ that it was upgraded/updated!!
9.  **_Built-in Monitoring / Management_** of your app
  through **`Erlang` supervisors**
mean that you know _exactly_ how your app is performing,
what parts have crashed/restarted and why!
This is a feature we _pay_ (_a lot_) for in
other frameworks and here it's **_free_**!!

Can _you_ think of _another_ reason
_why_ using Phoenix is **_awesome_**?! <br />
**_Please Share your thoughts_** in this thread:
[dwyl/learn-phoenix-framework#13](https://github.com/dwyl/learn-phoenix-framework/issues/13)

<br /><br /><br />

# _Questions_?

### Do I _need_ to learn `Elixir` _before_ trying/using `Phoenix`?

**_Yes_**. See: https://github.com/dwyl/learn-elixir

### Do I Need to _know_ `Erlang` to use `Elixir` & `Phoenix`...?

**_No_**. You can start learning/using `Elixir` _today_ and
call `Erlang` functions when required, <br />
but you **_don't need_** to know `Erlang`
`before` you can use `Phoenix`!

### But `Phoenix` is _not_ "_Mainstream_" ... Should I/we _use_ it...?

There are _many_ web application frameworks
you/we can choose from:
[wikipedia.org/wiki/Comparison_of_web_frameworks](https://en.wikipedia.org/wiki/Comparison_of_web_frameworks) <br />
So _why_ would _anyone_ select a framework written in a programming language
that is not _mainstream_...?

### Why are we not using `Node.js` _anymore_...?

This is _missinformation_.
We _are_ still using `Hapi.js`
for a _number_ of projects where it is _appropriate_. <br />
This includes _several_ client projects
and internal dwyl apps/tools.

We _decided_ to use `Phoenix`
for our **_new_ projects** for these simple reasons:

+ `Elixir` is a _nicer_ language than `JavaScript`.
+ `JS` _can_ be functional, whereas `Elixir` **_is_** (_always_) Functional!
The _distinction_ makes all the difference! <br />
With "functional" programming,
the programs are a **_lot_** easier to think about
while you are writing/maintaining them!
+ `Elixir` uses the `Erlang` VM which is _way_ more efficient/powerful than "V8"
+ The `Erlang` VM scales _much easier_
to multi-core multi-server multi-data-center
than `Node.js` <br />
(_or pretty much anything else for that matter!!_)

> _For our new projects we **need multi-data-center fault-tolerance**! <br />
we get that "**for free**" by using **Erlang -> Elixir -> Phoenix**_!!

In our _opinion_ Hapi.js is still "_the best_" `Node.js` framework and
we will `continue` to use and _recommend_ it <br />
to people that need _simple_ apps that scale and are easy to maintain. <br />
see:
[dwyl/**learn-hapi**](https://github.com/dwyl/learn-hapi)

Also we still use JavaScript for all our AWS Lambda Micro-Services,
that is not going to change. <br />
They are simple, efficient and
scale really well!  <br />
see: https://github.com/dwyl/learn-aws-lambda

### What's "Wrong" with using `Rails` or `Django`?

The _original_ "_productive_" web frameworks
were "Ruby-on-Rails" and "Django" (_python_) back in 2005! <br />
(We _used_ both of these for periods in our "_journey_" and
can speak on the _advantages_ of each of them!) <br />

> There is "_nothing wrong_" with using `Rails` or `Django`. <br />
> We think there are still plenty of use-cases for both frameworks. <br />
> We just _know_ that it's (_a lot_) _easier_ to build "real-time" <br />
> with Phoenix because "Channels" (_WebSockets_) are baked in, <br />
> and the Elixir/Erlang concurrency is a whole different ballgame! <br />
> Erlang (and thus Phoenix) can handle
**_millions_** of _concurrent users_ on a single server,<br />
> whereas a Rails/Django server can only handle a few thousand (_at best_!) <br />
> if your app is only serving a few thousand people at once, then you're fine!!

We **_love_** the fact that `Erlang`
uses "_lighweight long-lived_" processes,<br />
which means we can connect _millions_ of devices ...
For IoT `Erlang` is (_unquestionably_) the Answer! <br />
For simpler web apps where you only expect a few users per day,
`Rails`/`Django` are still viable.

But **why _compromise_** if you **don't _have_ to**? <br />
Why _settle_ for _good_ when you can _easily_ have/use the **_best_**?

### But `GitHub` Still Uses `Rails` ... Surely `GitHub` is "_Scalable_"?

**_Yes_**, GitHub is still using Rails for their Web App/Site. <br />
But ask _any_ of the _core_ team at GitHub if
(_given the chance to start over_)
they would _chose_ `Rails`<br />
to build `GitHub` _today_,
and see how many of them say "_yes, of course_"
(_with a straight face..._)!

Also, `GitHub` does a _lot_ of things to scale `Rails` in the background. <br />
And _many_ of their _newer_ (_client-side_)
features are written in `JavaScript`!
see: [/github](https://github.com/github)

> Bottom line is:
> _anything_ can be _made_ to scale using
> [**DevOps**](https://github.com/dwyl/learn-devops), <br />
> but **`Phoenix`** is _made_ to **scale** by `default`
> because `Erlang` was _invented_ solve scale!

### Why _NOT_ Use Go? 🤷🏻‍♀️

> "_There are two kinds of programming languages -
> those that nobody uses and those that everybody's bitching about_"
> ~ Bjarne Stroustrup
(_creator of_ [`C++`](https://www.youtube.com/watch?v=JBjjnqG0BP8))

`Go` is _very_ popular.
Largely due to the fact that `Google` "_sponsors_" it. <br />
It was meant to simplify (_replace_) `C++` and `Java` inside `Google` ... <br />
and for the most part, it has succeeded!

We _really_ like `Go`.
See:
[dwyl/**learn-go**](https://github.com/dwyl/learn-go)
`Go` was our "number two" choice when deciding
what programming language <br />
(_after `Elixir`_) in our "post `JS` stack"...
The **_decision_** to _use_ `Elixir`
instead of _anything_ `else` was **_easy_**:
+ `Elixir` is functional (_much simpler to read/write/maintain/extend_)
+ `Elixir` functions compose in a really elegant way
  as "plugs"/"**_pipelines_**"
+ Data is immutable which makes application state predictable (_no guessing_!)
+ Types are dynamic and inferred (_no need to manually declare them_)
but there are rules which simplify things and the compiler checks them
giving an appropriate warning.
+ `Erlang` makes distributed apps **_much easier_** and our _plan_ is to build
IoT systems that will mean connecting _many_ (_millions_) devices
with persistent connections, `Erlang` was **_made_ for this**!
+ `Phoenix` includes _many_ useful things out-of-the box including _several_
security features most people won't even think of.

Further Reading:

+ Why `Go` is Not Good:
  http://yager.io/programming/go.html
+ `Go` Web Frameworks:
  https://medium.com/code-zen/why-i-don-t-use-go-web-frameworks-1087e1facfa4
+ Why Everyone Hates `Go`:
  https://npf.io/2014/10/why-everyone-hates-go/
  (_click-bait title, some valid points..._)
+ Discussion:
  https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_compare_to_elixir
<br />

(`#HelpWanted` expanding this answer...)

<!--
### Why _NOT_ Use Scala + `Play` Framework _instead_...?

If you are already used to writing Java or deploying to the JVM,
the Play Framework is a _superb_ choice: https://www.playframework.com <br />
Scala is a _good_ programming language and everyone should learn it!
https://www.scala-lang.org/what-is-scala.html <br />

> We have used Play a few times (_before we adopted Node.js_)
and _really_ liked it! <br />
But Scala is a "kitchen sink" (_multi-paradigm_)
programming language that allows people to use "_all of Java_" ... <br />
We think Scala's "Java Interoperability" means it's "too easy" to allow
***complexity*** into your codebase. Specifically ["OOP Mutation"](http://docs.scala-lang.org/overviews/collections/overview.html) ...

So why _aren't_ we (DWYL) using "Play" for _new_ projects any more?
Firstly, we transitioned to Hapi.js (_Node.js_) a _few_ years ago
because it was more "***lightweight***" and allowed us to write _tiny_ programs
that used only a few Megs of RAM
(_where our Play apps were very resource-hungry..!
  have you ever tried running a Scala app
  on a "basic" laptop like a Chromebook...?_)

Summary of "reasons" for Phoenix instead of Play:
+ We maintain that Play/Scala still has plenty of valid use-cases.
+ Elixir is _way_ simpler than Scala. <br />
+ The Erlang VM is _way_ better at ***concurrency*** than the JVM.
+ We ***love*** the fact that all data is immutable in Elixir.
+ We ***love*** how few resources it takes to run a Phoenix app
(_e.g on a Raspberry Pi!!_)

> _We just think that for **our** project(s) ***Erlang's Concurrency model***
**works better** and **Functional code** transforming **Immutable data**
is **easier** to test and maintain_.

If you have _evidence_ that "_Scala is Simpler_"
we would _love_ to hear from you! <br />
Tell us: https://github.com/dwyl/learn-phoenix-web-development/issues

### Why not use Haskell?

If you like ***Functional Programming*** (**FP**) so much, why not use Haskell?
-->

### _Please_ ask more questions: [/issues](https://github.com/dwyl/learn-phoenix-framework/issues)