My team has had success training experienced devs in Elixir that were coming from other backgrounds. I would caveat this with the fact that we just have a Phoenix app with hardly any code that leverages OTP.
Considering that the impacted region has a lot of forestry, there are environmental concerns with how they will protect the land in their new state's regulatory system.
I 100% agree about Elixir and its surrounding ecosystem being almost perfect. It's insane how simple the building blocks are and how easy the code is to read and write.
Here are a few pain points I've ran into:
1. Typespecs leave something to be desired compared to other type systems
2. Maps vs structs and easily using one in place of the other
Things that my team would like to see:
1. Components in addition to templates as a first-class citizen in Phoenix. My team loves React because of the component model even though we hardly use an insane amount of interactivity.
Seconding the recommendation to check out Surface! From the docs:
Surface is a server-side rendering component library that allows developers to build rich interactive user-interfaces, writing minimal custom Javascript.
Features:
* An HTML-centric templating language with built-in directives (:for, :if, ...) and syntactic sugar for attributes (inspired by Vue.js).
* Components as modules - they can be stateless, stateful, renderless or compile-time.
* Declarative properties - explicitly declare the inputs (properties and events) of each component.
* Slots - placeholders declared by a component that you can fill up with custom content.
* Contexts - allows a parent component to share data with its children without passing them as properties..
* Compile-time checking of components and their properties.
* Integration with editor/tools for warnings/errors, syntax highlighting, jump-to-definition, auto-completion (soon!) and more.
Hey, just a friendly Elixir user here! Could you explain why you think that maps vs. structs is a pain point? I found this interesting because I personally really like how they are so similar, because you can almost always manipulate a struct like a map, just like you'd expect. It lets you use standard operations for working with structs.
Not GP, but: You can't use trivially use [] dereferencing notation with structs, or, for that matter get_in or put_in, without first making it access protocol compliant (which maybe you shouldn't do? I haven't figured that out for myself yet). A common use case for me is initializing a GenServer with a kwl, which is nice for your code prettiness, but you'd like to also support maps, because that fits with how the internal state of the GenServer looks. Then when you go to refactor your GenServer to use a struct because you prefer a more solid typesystem, you can run into a minor stumbling block and slightly uglier code. Not insurmountable though, and you're writing tests right? Once those tests pass you've got nothing to worry about.
Making the conversion from/to Map and (keyword) list explicit makes sense, as they have very different access patterns: keyword lists really are not suited for random access unless very small.
And in general Erlang and Elixir have very little automatic type conversions, if any.
But maps and structs are interchangeable, I don't get why using one or the other would make your GenServer code any different. A struct is just a map with an additional field called "__struct__".
Phoenix + Ecto has been the best web framework experience I've ever encountered. I have experience with Django, Flask, Express and Rails. I'm a huge fan of Elixir as a language and the BEAM runtime. The libraries have been pretty great too.
I recently started a SwiftUI project and this is a very accurate take based on my experience.
How I spend my time in SwiftUI:
1. Wondering how I can get some conditional logic. Coming from React, this is a major issue that needs to be addressed.
2. Figuring out where and what the error actually is.
3. Restarting Xcode for my view to magically start working again.
The two-way data binding is a blessing and a curse. I like React's method of passing callback functions to keep the state logic separated. This comes up with me when working with sheets.
I see the potential. I like having an all-in-one experience that IDE + framework integration provides but the poor defaults and breaking bugs really make me question the execution.
I just led a migration for my small team from Zeit Now to Render (https://render.com/). It has filled this need pretty well. There are some features that I wish existed but overall the simplicity has been great for our use case. They do not have auto-scaling but it's planned (https://feedback.render.com/features/p/autoscaling).
(Render founder) Glad to hear it, and I hope you've posted your feature requests on https://feedback.render.com. We're investing heavily in growing the team and putting a strong engineering foundation in place so we can keep adding new features quickly and reliably.
Render is more flexible than Heroku: you can host apps that rely on disks (like Elasticsearch and MySQL), private services, cron jobs, and of course free static sites. You also get automatic zero downtime deploys, health checks and small but handy features like HTTP/2 and automatic HTTP->HTTPS redirects.
It's considerably less expensive as your application scales: a webapp that needs 3GB RAM costs $50/month on Render; on Heroku you'll pay $250/month for 2.5GB RAM, and $500/month for the next tier (14GB RAM).
One of the major pain-points I've hit with this concept of a "Monorepo" is tooling support since many things are built on the premise of separate repos for each code base. Pain points: Git+Github issues, CircleCI, etc. How do you handle those problems?
