[HN Gopher] Dynamic Forms with LiveView Streams
___________________________________________________________________
Dynamic Forms with LiveView Streams
Author : unripe_syntax
Score : 120 points
Date : 2023-05-30 06:52 UTC (16 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| vyrotek wrote:
| Is LiveView like ASP.NET Blazor Server?
|
| It seems to look very similar but I didn't see whether LiveView
| has the "sticky" websocket server requirement like Blazor. With
| Blazor all of the user's state is in memory on one specific app
| server. And if a connection is lost the app is completely
| unresponsive.
|
| It's a great dev experience but I've seen comments about scaling
| and interaction latency concerns. Seems like it'd be great for
| intranet corp apps.
|
| Is anyone running either tech as a public facing service?
| benwilson-512 wrote:
| Hey vryotek, short version: stickiness is not necessary or
| important. It does use a websocket.
|
| To elaborate a bit, while each LiveView client is indeed
| associated with a long lived process in the LiveView server,
| the Phoenix framework provides hooks and other lifecycle
| management tools to minimize the impact of disconnects from eg
| blue green server deploys. Most interestingly for example with
| forms, the "automatic form recovery" does a process where when
| the reconnect happens it delays re-rendering until the client
| side has had a chance to send the current form state back to
| the server and allow it to synchronize.
| deofoo wrote:
| After you work with Phoenix/LiveView is soo hard to come back to
| anything else. I love the fact it's very opinionated and most
| times there's a right way to do things.
|
| LiveView is game changer, same user experience (even better) with
| 10x better developer experience. No much dual state management
| and things just work.
| sodapopcan wrote:
| While I agree wholeheartedly, I do want to point out that while
| it has opinions in its high quality documentation, it is in no
| way opinionated in the same way that something like Rails is.
| You can use Phoenix in the same way you'd use Sinatra or Flask
| or the like [0], there are just no generators for it. I just
| wanted to bring this up in case anyone would be put off to try
| it who is afraid opinionated frameworks. However, if you prefer
| the opinionated option and want to be given clear guidelines on
| how to solve many common problems, Phoenix does indeed have you
| covered :)
|
| [0]
| https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a9...
| [deleted]
| quickthrower2 wrote:
| I keep seeing almost this exact comment from different people
| when phoenix is mentioned. It is quite a learning curve I might
| try again one day.
|
| What makes this better than say a traditional ruby/rails or
| django app with maybe some htmx to save doing the JS side of
| things?
| fredrikholm wrote:
| BEAM (ErlangVM).
|
| This video explains it better than I can:
| https://www.youtube.com/watch?v=JvBT4XBdoUE
| yurishimo wrote:
| I knew which video this was before I clicked on it. It's a
| brilliant demo of the power of the BEAM and how it can be
| leveraged for web applications.
| ch4s3 wrote:
| You get a concurrent request processing spread across all of
| your cpu/vcpu cores out of the box. The fallback controller
| pattern for error handling is incredible for boilerplate
| error handling. Worst case latency is very stable. The query
| builder/data mapper, Ecto, is IMO far better than ActiveRecor
| being more explicit and prevents N+1s out of the box. Eex is
| built on compile time linked lists rather than run time
| string interpolation like the options in Rails and Django.
| ativzzz wrote:
| My opinions on this as a rails dev
|
| > You get a concurrent request processing spread across all
| of your cpu/vcpu cores out of the box
|
| That's neat, but this doesn't matter until you reach
| serious scale, as scaling a rails app horizontally by
| throwing more server instances works for a long time
|
| > The fallback controller pattern for error handling is
| incredible for boilerplate error handling
|
| Sounds just like controller inheritance in rails
|
| > Worst case latency is very stable
|
| So is rails, worst case latency is generally caused by slow
| SQL requests or having to render complex documents (which
| can be offloaded to the background easily)
|
| > The query builder/data mapper, Ecto, is IMO far better
| than ActiveRecor being more explicit and prevents N+1s out
| of the box
|
| I don't have a problem with ActiveRecord, and while N+1s
| are easy to create, there are a ton of tools to help
| prevent these in rails. Can be a hinderance for junior devs
| or devs without rails experience though
|
| Once things get complex, you're gonna be writing SQL
| directly anyway
|
| > Eex is built on compile time linked lists
|
| Cool but sounds irrelevant for 99.9% of cases, string
| interpolation isn't what causes rails apps to be slow
| josevalim wrote:
| I'd say those points deserve a deeper look. Take
| concurrency for example. It is not only about scaling, it
| can actually affect every step from development to
| production:
|
| 1. Development is faster if your compiler (or code
| loader), tasks, and everything else is using all cores by
| default.
|
| 2. You get concurrent testing out-of-the-box that can
| multiplex on both CPU and IO resources (important given
| how frequently folks complain about slow suites).
|
| 3. The ability to leverage concurrency in production
| often means less operational complexity. For example, you
| say you can offload complex documents rendering to a
| background tool. In Elixir this isn't necessarily a
| concern because there are no worries about "blocking the
| main thread". If you compare Phoenix Channels with Action
| Cable, in Action Cable you must avoid blocking the
| channel, so incoming messages are pushed to background
| workers which then pick it up and broadcast. This adds
| indirection and operational complexity. In Phoenix you
| just do the work from the channel. Even if you have a
| small app, it is fewer pieces and less to keep in your
| head.
|
| At the end of the day, you may still think the bullet
| points from the previous reply are not sufficient, but I
| think they are worth digging a bit deeper (although I'm
| obviously biased). :)
| ativzzz wrote:
| 1. makes sense, our app is limited locally because docker
| on mac is not fast
|
| 2. Our test suite is pretty good! It's limited by the
| longest test runs (basically selenium tests that are slow
| because browser interactions are slow), circleCI allows
| pretty easy parallel testing
|
| 3. I think the same reason we offload long-running rails
| processes still applies . The only thing a long running
| rails request blocks is further requests to that
| particular thread handling the long request. Usually some
| other request will end up getting queued to that thread
| which is the issue. So it's a load balancing issue, as
| well as a UX issue (you don't want an HTTP request to
| take 3 mins loading a long report). Unless Elixir can
| indefinitely spin up new threads, this is still a load
| balancing issue, determining which server incoming
| requests are routed to
|
| We don't use action cable so I can't comment there
| josevalim wrote:
| 2. You should be running multiple Selenium instances (or
| equivalent) in parallel even on your machine (unless you
| run out of memory or CPUs).
|
| 3. Exactly. This is not a problem in Elixir. If it takes
| 3 minutes to render a request, all other incoming
| requests will progress and multiplex accordingly across
| multiple CPUs and IO threads. This also has a direct
| impact on the latency point brought up earlier.
| fredrikholm wrote:
| Amen.
|
| I'm always amazed by how malleable the BEAM and the patterns
| built on it can be. I don't think anyone predicted Erlang to
| (IMO) reign supreme in frontend development. I say this having
| written tens of thousands of lines of React and Svelte in
| production, on top of all the hobby projects over the years.
| sph wrote:
| In hindsight it makes sense. Networked servers need
| resilience to failure, to keep running, and to make
| concurrency as painless as possible, especially as CPU cores
| count increases.
|
| Off the top of my head there's not many languages that can
| easily handle a million processes on consumer hardware, while
| the developer only has to think in single threaded mode
| because deadlocks and data races are literally impossible.
|
| If you're building a server of any kind, the BEAM is the
| bee's knees. You can always resort to using a sidecar process
| or a Rust NIF for the high performance hot path.
| ativzzz wrote:
| > while the developer only has to think in single threaded
| mode because deadlocks and data races are literally
| impossible
|
| Does Elixir somehow automatically solve the case where a
| row in a database is loaded into memory simultaneously
| across multiple requests and a value is incremented? (can
| be easily solved with row locking, but still needs to be
| done explicitly at the application level)
| sph wrote:
| Usually one would use Redis for this problem, and you
| have a Redis-like system (but based on pattern matching)
| native to OTP, ets.
|
| If you need a global, cluster wide counter, spawn a
| process with name {:global, :whatever} and let it be the
| source of truth for this value.
|
| Depending on the problem, there are multiple approaches
| you can take. And a single Postgres instance is able to
| deal with massive concurrency, there might not be any
| need for premature optimization when SQL transaction
| could do.
| fredrikholm wrote:
| > million processes ... think in single threaded mode
|
| This is a big component of the secret sauce. Writing top
| down, happy path code as if you're just exploring an idea
| and then decide to scale it to _distributed nodes_ without
| changing the implementation is just absurdly practical and
| blows every other VM out of the park.
| Dowwie wrote:
| What have you built with Phoenix?
| dugmartin wrote:
| The new LiveView streams are a good start - they are missing
| reordering though which is needed for lists but is not a normal
| property of a stream.
|
| I've been working on a personal project which is very list heavy.
| I started it in pure LiveView using streams but ended up
| switching to a React SPA hosted in a non-updating LiveView div.
| Along with missing the reordering (which is needed a lot in the
| app) the amount of state I needed to hold on the server to
| wouldn't scale.
| di4na wrote:
| If you have remarked, you can reorder in this version :)
| hobo_mark wrote:
| Is this to be understood as the equivalent of HTMX + Jinja, but
| for Elixir?
| marcofiset wrote:
| LiveView goes far beyond what htmx offers. Or at least makes it
| much more fully integrated across the whole stack.
|
| htmx is a frontend library first and foremost, that dictates
| some patterns you may want to implement on the backend.
| LiveView is a backend-first framework, with excellent support
| for interactive frontend stuff.
| [deleted]
| ThatMedicIsASpy wrote:
| I sometimes just like to look at code and ignore the rest since
| it's not something I have experience with. But damn this is some
| next level ugly mess of code in my eyes.
| slig wrote:
| Agreed. Somehow we are back to PHP's level of fuglyness.
| Alifatisk wrote:
| What are you used to?
| marcofiset wrote:
| You being unfamiliar with a programming language doesn't make
| it an ugly mess.
| garyrob wrote:
| When I've seen LiveView mentioned in the past, the one major
| problem seems to be its reliance on sockets, which causes
| problems in certain environments and also can cause too much
| latency on slow internet connections.
|
| An example of the kind of problems is at [1]. It's not hard to
| find other such discussions.
|
| The other thing I wonder about is cross-platform. If you're using
| something like React or Flutter there are various solutions. But
| I haven't run across anything substantial that's oriented towards
| Phoenix LiveView.
|
| [1] https://elixirforum.com/t/live-view-fallback-with-no-
| websock....
| tomtheelder wrote:
| The fallback to polling is generally a good solution. I think
| the sorts of problems that dev ran into are very much the
| exception, not the rule, given the kind of absurd environment
| they were working in. Also worth calling out that LiveView was
| _very_ new when that post was made.
|
| The latency issue is a real one. Long polling can also help
| there, but realistically if a substantial portion of your user
| base is on poor connections you're going to be much better off
| with a traditional server rendered web application than
| something like LiveView or a SPA.
|
| I'm not sure what you mean about cross-platform. LiveView is
| for building web apps, so there's only really one platform to
| speak of: the browser.
| garyrob wrote:
| Thanks, that's helpful.
|
| > I'm not sure what you mean about cross-platform. LiveView
| is for building web apps, so there's only really one platform
| to speak of: the browser.
|
| Similarly, React is for web apps but React Native has emerged
| such that your knowledge and some code can carry over, and
| now there's even React Native for Web so that you can write
| React Native and run it on the web in a way that at least
| tries to maximize code portability. It sounds like there
| hasn't been an emergence of equivalent tools with LiveView...
| but that's fine. As you say, LiveView is for the web and if
| that's the one thing you're targeting, especially for an
| internal app so internet connectivity is reliable, it's
| fantastic and possibly the best solution that exists now.
| There's certainly nothing wrong with making a great tool to
| full a particular (major) need!!
| clessg wrote:
| > It sounds like there hasn't been an emergence of
| equivalent tools with LiveView
|
| Soon(tm)! https://native.live/ and
| https://github.com/liveview-native/live_view_native
| garyrob wrote:
| Thanks for that info!
| pmarreck wrote:
| The use of template code in a view model- Is there a way to push
| that out into its own template? Is there a reason why things are
| done this way?
| sodapopcan wrote:
| It's done this way to collocate related (business) concerns.
| The views are in their own functions and don't contain any
| logic and, yes, they can be pushed into separate template files
| if that's what you prefer. This has been a thing since React
| came out and its merits have been debated to death already.
| madeofpalk wrote:
| "Seperation of concerns, not technology" is the line often
| brought up in React circles.
| sodapopcan wrote:
| Ha, yes, I've been saying this since long before React (I
| don't actually use React). We were never doing "separation
| of concerns" even in the 2000s/2010s, simply separation of
| languages.
| pmarreck wrote:
| I noticed this in React and it's also a reason why I didn't
| like React. Fortunately or unfortunately, I've never had
| occasion to use React in prod. lol. Can you point me at any
| of the debates you mentioned so I can catch up?
|
| In Rails this would have been a "partial" with some
| underscored filename
| sodapopcan wrote:
| I assume searching for "JSX sucks" would do it. I certainly
| haven't bookmarked any debates from the past 10 years, lol.
| Incidentally JSX is the only thing I like about React. I
| find components are much more flexible and cohesive than
| partials (Rails was my thing for years and I still have a
| soft spot for it). But to each their own and I no longer
| enjoy debating it!
| Alifatisk wrote:
| Everytime LiveView or Phoenix pops up here in HN, people always
| mentions how much they enjoy the framework. It feels to me like
| it's something I am missing out on?
|
| I am Ruby/Rails developer myself and StimulusReflex seem to be
| the equivalent but idk, is my feeling true?
| sph wrote:
| No it is not equivalent.
|
| My dream stack that I am using for my business is Phoenix, Live
| View and Stimulus.js with Tailwind.
|
| I have built projects on Laravel, Django, RoR, React and a long
| tail of in house frameworks, and nothing feels as good as this
| stack for web apps. Ruby on Rails is quite underrated, but the
| BEAM is a spaceship that fits neatly in the list of _unknown
| unknowns_ for 99% of software engineers: they do not know what
| the BEAM can do for them. Its process and mailbox model feels
| futuristic in its expressiveness and simplicity.
|
| It's easier than you think to get used to Elixir's functional
| language model. For me it was super easy, while with stuff like
| Haskell or Prolog I felt like I had to rewrite my brain from
| scratch.
|
| To end my proselitism, I am adamant that the first Live View
| demo by McCord and Valim will have the same staying power if
| not popularity as DHH's first demo of Ruby on Rails which
| spawned the modern MVC framework architecture of the past 15
| years.
|
| The Live View model is in my eyes the next generation of
| interactive web architecture, the true successor to MVC.
| pbowyer wrote:
| > My dream stack that I am using for my business is Phoenix,
| Live View and Stimulus.js with Tailwind.
|
| I am curious, why both LiveView and Stimulus.js? Why and how
| are you combining the two together?
| sph wrote:
| For very small interactions, there is no need for a round
| trip and state held on the server.
|
| Imagine a disappearing burger menu, or a tooltip widget, or
| a "click here to copy to clipboard" link. For those
| sprinkles of interactivity, you need JS and Stimulus is
| ideal for that use case.
|
| I just have my Live View process render
| <input type="text" data-controller="copy-on-click"
| value="..." />
|
| which is easy to understand and plays great with Live
| View's model.
|
| Don't forget that JS was born for this goal: small snippets
| of interactive behaviour; it was never meant to be the
| entire system.
| brainbag wrote:
| I've seen alpinejs mentioned alongside LiveView, what
| benefits do you see to Stimulus over alpine?
| sph wrote:
| I've never used alpine, so I'm not the one to ask. I've
| just given it a cursory look a couple years ago.
|
| I do not like how it's trying to fit logic in custom HTML
| attributes. Doesn't look great to me, and would pollute
| my Liveview templates with a matryoshka doll of nested
| logic: There's a top-level Elixir module, which contains
| a HEEX string that creates HTML, which itself contains
| Alpine.js logic as an attribute.
|
| Feels cleaner to me to just create a new .js file that
| exports a controller, and just instantiate it from
| LiveView (which still pollutes the HTML, but much less
| than Alpine does)
|
| That said, there is no good or bad answer. Alpine or
| Stimulus are certainly better than instantiating Vue or
| React. HTMX could fit very nicely as well. Use what
| you're comfortable with.
| clessg wrote:
| Oh wow that's brilliant, I hadn't ever considered
| combining LiveView and Stimulus.js. If you don't mind me
| asking, what is the benefit over using `phx-hook`?
| Portability/interop with RoR, or?
|
| Either way, I'm shipping it to production immediately!
| sph wrote:
| phx-hook is a nice convenience that works only with Live
| View.
|
| It seems to me a better investment of my time to learn a
| solution that's just as lightweight, but I can use
| everywhere (i.e. in other projects, or in static non-
| Liveview pages)
| clessg wrote:
| Makes a lot of sense, thank you! I'm not much into Rails
| these days, but that's one thing I really appreciate
| about RoR's "frontend" efforts - their work tends to be
| quite reusable across ecosystems, e.g. Stimulus, Turbo,
| and apparently even Hotwire itself [0]. Heck, that even
| seems to apply to a lot of their non-frontend stuff, such
| as MRSK [1].
|
| [0] https://www.akshaykhot.com/using-hotwire-without-
| rails/
|
| [1] https://mrsk.dev/
| sph wrote:
| Yeah RoR with those libraries are also moving towards the
| "as little JS as possible" approach as well.
|
| Client-side logic makes sense in a vacuum, but then your
| crappy React app is in fact a distributed system, with
| all the complexity that entails. The radical idea of
| Liveview and similar efforts is that it's better just to
| return to basics and keep the logic on the server. It
| would be lunacy to try and build a distributed system
| with Javascript, yet that's the direction the SPA world
| is/was taking us.
| alostpuppy wrote:
| Do you have a link to that demo?
| sph wrote:
| The Live View demo or the Rails one? :-)
|
| Rails, it was this one 17 years ago:
| https://www.youtube.com/watch?v=Gzj723LkRJY
|
| Live View, I'm not sure which is the first demo. There's
| "Build a real-time Twitter clone in 15 minutes with
| LiveView and Phoenix 1.5"
| (https://www.youtube.com/watch?v=MZvmYaFkNJI)
| ihatejs wrote:
| I haven't read the entire article but my biggest complaint is the
| lack of tutorials to deal with the new way of defining forms and
| tables using the new function components in Phoenix 1.7. Yes, the
| official documents do explain how function components (in
| general) work and are defined but what I really wanted was a
| superficial guide to use specific components without delving into
| the internals. I did bite the bullet and read the documentation
| and looked at the source code but I feel I didn't really need to
| do it. Just tell me the new tags I could use, what the attributes
| mean but I don't need to know how the sausage is made.
| mrdoops wrote:
| Liveview v1.0 is the next step with this release out; 1.0 will
| be the main target for tutorials, documentation, examples and
| libraries to build on.
|
| Easiest way to get component usage examples ATM is to generate
| a phx project, and run a mix phx.gen.auth and phx.gen.live
| command.
| melx wrote:
| I read somewhere that it's good to learn new prog language every
| some time but there's not enough time in one's life (especially
| after having kid(s)). So I used Elixir (Phoenix/Ecto) on a new
| project some 18months ago and every project I start now is using
| that tech stack!
|
| The best thing for someone like me (back-end dev) is no need to
| write JavaScript, care about zillions of build systems, having
| the Node/npm drama yet I can create nice and "progressive" web
| apps. In fact one of the projects I'm building is a powerful
| online forms builder.
| rjh29 wrote:
| Phoenix/LiveView must be _really_ good if people are learning not
| one but two niche languages (Elixir and Erlang) just to use it.
|
| I wonder if the framework is particularly tied to Elixir or if it
| could be done in a more popular language so more people will take
| it up.
|
| edit: and yes I know WhatsApp was/is written in Erlang, just to
| save you commenting.
| deofoo wrote:
| First, it is _really_ good. Second, you only need to learn
| Elixir, no need for any Erlang knowledge.
| yurishimo wrote:
| This is true, but I would add an asterisk. While not knowing
| Erlang is not a hard requirement, eventually, you will
| greatly benefit from being able to read and write some basic
| Erlang.
|
| That said, learning Elixir first will at least get you in the
| right mindset, and then Erlang becomes an easy lesson in
| syntax.
| pmarreck wrote:
| When you learn Elixir, you basically also learn Erlang
| semantics, with only the syntactic details to work out later.
| Plus you get a few extra perks, like macros.
| victorbjorklund wrote:
| You really don't need to learn Erlang. Would it help to
| understand some of the deeper stuff in some libraries or the
| beam itself? Sure, but then you could argue you need to learn
| Javascript and C to use Node because a lot of low-level stuff
| in node is C. Will it help to become a better Node dev?
| Probably doesn't hurt but you def don't need to learn C to work
| with Node.
| sph wrote:
| > I wonder if the framework is particularly tied to Elixir or
| if it could be done in a more popular language so more people
| will take it up.
|
| All programming languages are Turing-complete thus compatible.
| So you shan't need much more than Brainfuck.
|
| But if you consider all the benefits the language and the
| platform it sits on (the BEAM) provides, no, you cannot do Live
| View as easily and comfortably than you can do on Elixir.
| Because its model is strongly tied to lightweight processes,
| message passing, mailboxes and pattern matching.
|
| You can implement Live View in assembly or Python or Rust, but
| it's not going to be very quite as ergonomic and productive.
|
| Also, you don't need to know Erlang to be productive in Elixir,
| but knowing the Erlang _ecosystem_ (i.e. OTP) is going to pay
| dividends, since it 's very powerful and at your fingertips
| from the Ruby-like comfort of Elixir.
| clessg wrote:
| > You can implement Live View in assembly
|
| I would love to see this.
| bryanrasmussen wrote:
| >All programming languages are Turing-complete thus
| compatible. So you shan't need much more than Brainfuck.
|
| XSL-T 1.0 is Turing complete but you can't really write a C
| compiler in it - despite what some people may have been heard
| to claim at various XML conferences in 2000 - because what
| matters in most things is what rights and accesses the
| language offers you and XSL-T 1.0 does not give you the
| possibility of loading in non-XML files.
| sph wrote:
| Fine, you shan't need more than an assembler for your CPU
| architecture.
| krnsi wrote:
| Here you go - a list of LiveView workalikes:
| https://github.com/liveviews/liveviews
| rapnie wrote:
| The list is seeking a maintainer.
| https://github.com/liveviews/liveviews/issues/23
| sodapopcan wrote:
| > I wonder if the framework is particularly tied to Elixir or
| if it could be done in a more popular language so more people
| will take it up.
|
| As others have pointed out there already are lots (missing at
| present are LiveWire and there is even a LiveView.js that uses
| the same JS that Phoenix LiveView uses... it's a very
| unfortunate name).
|
| Having said that, most of these implementations aren't "live"
| in the same way you get with the Erlang virtual machine where
| each user has a dedicated process. It's at least possible in
| Go, but most of these other implementations resort to AJAX and
| the like.
| iudqnolq wrote:
| > learning not one but two niche languages
|
| You need to learn Elixir. Learning Erlang isn't going to be
| particularly helpful.
|
| > I wonder if the framework is particularly tied to Elixir or
| if it could be done in a more popular language so more people
| will take it up.
|
| Blazor (C#) and StimulusReflex (Ruby) are the ones that
| immediately pop into my head.
| arrowsmith wrote:
| You don't need to know Erlang to use Phoenix or LiveView.
| lycos wrote:
| I love working with Elixir and hope to be able to find a new gig
| where I can continue doing that. That's the hardest part
| unfortunately still.
|
| But more ontopic, has anyone here already used these LiveView
| Streams in production? Based on this example it feels like I'm
| having to manage a lot more myself with the only real advantage
| being less memory usage, right?
|
| I'm just wondering where/when it makes sense to play with this
| instead of, for example, temporary_assigns with phx-
| update="append". Are there more advantages than the memory usage
| reduction?
| di4na wrote:
| I refactored my profiling library to use them. They reduce the
| amount of stuff to manage. Instead of keeping a whole list of
| stuff organise, you just pass stuff to the stream and
| everything just works with good diff.
| commitpizza wrote:
| I have tried Liveview and I have looked at alternatives and I
| have to say that even if I don't use Phoenix or Elixir on daily
| basis, Liveview is easily the best out there.
|
| The developer experience is great and Phoenix is just a great
| framework. The speed in which one can create stuff is mind
| blowing which is going to be the biggest pull factor into the
| language imo. My main issue is that Elixir is great for a lot of
| hard problems but for the easy, common problems it is lacking a
| lot in libraries and so on. It also has a high learning curve.
|
| Although it is probably just going to get better in time the
| learning curve will probably not.
| fredrikholm wrote:
| IME a lot of the learning curve is functional programming,
| shortly followed by OTP. If you've ever worked with a
| functional language picking up on the OTP abstractions (eg.
| GenServer) is a small hill to climb in order to become
| effective on a day-to-day basis.
|
| That said, with every new language comes idioms, tools and
| libraries that one has to learn, but this is true for all
| languages.
| commitpizza wrote:
| True and honestly, as an experienced developer it wasn't that
| huge of a step to start coding in Elixir. It's just that I
| (at least) is still thinking in an object-oriented way even
| when I'm working in Elixir because that is what I am used to.
|
| I think the hardest part is to let go of some of the old
| practices and embrace functional programming as much as you
| can.
|
| I would like to work with elixir professionally but have yet
| to find an employer that uses it in production :)
| yurishimo wrote:
| Many Elixir companies will hire and train you if you have
| previous experience. If you're really interested, it's
| worth reaching out!
| ch4s3 wrote:
| Yeah, 100%. I'd say half or more of the Elixir devs I've
| hired had no Elixir experience before. I've found most
| people pick up the basics easily, and the language is
| super approachable.
| robbs wrote:
| What libraries are missing? So far, I've only missed having a
| library for interacting with Google Sheets. I got around that
| with a Lambda running Python. Everything else either had an
| Elixir library or there was no library in any language.
___________________________________________________________________
(page generated 2023-05-30 23:02 UTC)