No typing, no party.
...but I will include it under almost-low-code section
Elixir for Humans Who Know Python
131–140 of 198 posts
Re: Elixir for Humans Who Know Python
#132I've been using Elixir with Phoenix and Liveview at my job for the past three months as part of a small team building a non-trivial web app ( https://duffel.com/links ). I'm mostly a front-end developer and was brought in to handle the UX side. Prior to this project I've spent the last 5+ years in the React world. I found a lot of what the author says to be true. I'm used to the nightmare that is managing front-end d…
> Whenever I jumped into the JS world it often felt like I was fighting against Phoenix
I've had the same experience and this is something I've tried to tackle recently. I've started working on LiveSvelte which allows you to plug in Svelte components directly into your LiveView, while still being able to push events to the server with a `pushEvent` function on the client. I've only started working on it this week but I think it's a promising idea. It's not React though but you could develop a similar package with React, I just much prefer Svelte :)
Re: Elixir for Humans Who Know Python
#133Earlier quoted context omitted.
I work for an org that does a lot of Elixir (on other teams though, I’m actually a Django developer!). I’ve heard from those team leads that they’ve had trouble hiring people with FP / Elixir experience, which is not that surprising to me. Guess it’s a matter of right place right time.
More orgs should hire experienced engineers and train them on the job.
This, a company to find skilled workers in a niche technology is expecting too much.
Re: Elixir for Humans Who Know Python
#134Earlier quoted context omitted.
Ack on migrations, tks! --- For completeness, you can do the same in Ecto: from t in MyTable, where: t.key >= 12, select: ["field1", "field2", "field3"] However, that will still allocate a "MyTable" struct in Ecto. And if that struct is large (say 50 fields), slots for it are allocated (but none of the actual data on the fields). I am not familiar with Python Object Model enough but, if your Python example still allo…
Please notice that nothing stops you from defining a non managed (ie Django migrations won't mess with it) model pointing to the same table and having declared only three of the fields of the original model.
That is more elegant than using a proxy model
Re: Elixir for Humans Who Know Python
#135> The pipe operator, |>, passes the output of a function to the first argument of the next function. So, instead of writing something like: foo(bar(baz(new_function(other_function(my_input))))) You have the option to write: my_input |> other_function() |> new_function() |> baz() |> bar() |> foo() The readability benefit is clear - you don't have to read the code "backwards" to understand what it really does. —- ( end…
If you need temporal variables to give context you have other problems with the naming of the function that you are calling in the first place.
We have used temporal names between function calls not because it was more readable but because chain of methods was not an option as you have said.
Re: Elixir for Humans Who Know Python
#136Earlier quoted context omitted.
More orgs should hire experienced engineers and train them on the job.
This, a company to find skilled workers in a niche technology is expecting too much.
Practically insignificant numbers of company will do it. They are racing to bottom to shirk their own future developer pool.
Re: Elixir for Humans Who Know Python
#137I haven’t gotten through the whole article yet, and haven’t encountered Elixir before, but I really like the popes ideas. I am going to dig into that a little more. Are there other languages that have similar constructs (outside of shells!)?
Ocaml, F#, probably others.
Re: Elixir for Humans Who Know Python
#138Earlier quoted context omitted.
> I use Phoenix only on projects where its real-time capabilities will be the protagonist Yep, that feels sound advice (and motivation). I would add more broadly "federation capability" (in the style of the fediverse / activitypub but also wherever that decentralization path might take us in the near future) as an important dimension to look into. Remains to be seen if the "telecoms/erlang" pedigree of elixir is a cr…
It is only sound advice if you already know Python/Django really well and don't mind context-switching your language. If you know Elixir/Phoenix well, you can easily crank out simple sites that don't use any real-time stuff as well as any other framework, and you get the added benefit of blazing fast (pre-compiled) templates and a highly robust database connection pool. Personally I prefer to keep as much as possible…
sticking within a single capable ecosystem is optimal here-and-now but your mileage might vary as we go forward. its always hard to forecast but even if you discount alot of the ML/AI hype, its quite likely that 2-3 years from now expectations will be for much "smarter" services.
whether delivering such upgrade can be achieved with microservices and API's or whether a platform can deliver functioning "monoliths" that compete also in such a new landscape is not clear (not to me anyway)
Re: Elixir for Humans Who Know Python
#139Earlier quoted context omitted.
Please notice that nothing stops you from defining a non managed (ie Django migrations won't mess with it) model pointing to the same table and having declared only three of the fields of the original model.
That is more elegant than using a proxy model
The Django docs also mention that
https://docs.djangoproject.com/en/4.1/topics/db/models/#diff...
> If you are mirroring an existing model or database table and don’t want all the original database table columns, use Meta.managed=False.
Re: Elixir for Humans Who Know Python
#140Earlier quoted context omitted.
Django’s approach is to run all the migrations, from the migration files, if the database gets wiped clean. In other words, if you’re developing on your local machine, you can just drop the DB and start new (or if using SQLite, just delete a file), and after running migrations, you never have to worry about whether all the necessary files are in sync with the database. As Neo might say:“there is no spoon…” seriously,…
Thanks! FWIW, structure.sql is not needed in Ecto either. You must do that when: 1. You want to start discarding migrations (because you have too many) 2. You had an existing database Are those never a "trigger" on Django side? I appreciate the opportunity to learn!
Generally speaking, it's inadvisable to 'discard' migrations with django. If the migration set is getting too large, the general practice is to 'squash' migrations, which is a django-supported function for merging the migrations down to a single app. You can do the less blessed, but more simple function of nuking the migrations, updating the migrations table, and remaking your migrations... but you have to coordinate that in every environment.
For an existing database, you can easily create django models for each table, etc. There's a --fake option to update the migration table to make it think you've applied these migrations, but not actually apply them. This convinces django you've brought the database in sync. May your deity or deities help you if you did not actually bring it in sync. I've used this quite a bit in some java ee->python migrations I've done in the past.