231–240 of 249 posts
Earlier quoted context omitted.
Here's an example of using it with 2 millions users: https://www.youtube.com/watch?v=c6JcVwbOGXc
I'm assuming the parent meant how would this specific configuration of elixir + phoenix + liveview scale.
I've been writing code for close to 10 years now and I see this and feel like what a beginner would feel trying to understand assembly code. Or someone hearing a similar but new language. Looks to me hours of work and learning got abstracted as under the hood "magic". It's like saying: Oh, so I've been weight training for the last 17 years and I should tell you Olympic silver is not too hard, see? Am I right in my th…
There's no magic. It's functionality that's made possible by the BEAM. It's just one of those things that came out of realizing how powerful the runtime was for handling certain types of problems. When you combine a couple of those bits together, you end up with this. The only modern web problem that Elixir isn't ideally suited for is heavy number crunching. Otherwise it gives this amazing balance of efficiency, scal…
I would caveat that in a couple of ways.
First, suppose you have a web app where some requests involve heavy number crunching and others don't. In web frameworks where 1 request ties up 1 OS thread, a burst of heavy requests could gobble up all your available connections. Phoenix would use one cheap BEAM process per request, and the BEAM's preemptive scheduler would ensure that other requests are answered in a timely way and that all the heavy ones continue to make steady progress. So although the heavy requests might be completed more slowly than in another language, the overall system would remain more responsive.
Second, if you have need for heavy computation or data structures that work better with mutability, it's possible to (eg) use Rustler (https://github.com/rusterlium/rustler) to implement that part in Rust. See https://github.com/rusterlium/rustler for a story about doing this.
Earlier quoted context omitted.
> I just re-wrote the entire crappy mess Wordpress core in Elixir and enjoyed the process. That sounds useful. Do you plan to make a product out of that?
Yup, launching soon. Probably will open source it too.
Earlier quoted context omitted.
I'd really like to read about your finding wrt hot code loading. Is there anything you can point me to?
I'm afraid not, it's not been a fruitful area of research so we've not written anything down about the limitations.
I wrote a little app recently to test out live-view. It was my first time really working with it, though I've been writing elixir for years. https://gif.energy Didn't really have any issues. There were maybe one or two gotchas but they were explained clearly by the docs (appending vs updating elements) and I was able to get it sorted easily. That whole app took a couple days, but more than half the time was wasted on…
> It doesn't make sense for certain types of apps, but it really adds a ton of value and saves a lot of time when the use case is right What are some of these use cases?
However, 1) you can add custom JS using LiveView's hooks, which might be enough for very simple offline behavior and 2) many SPAs don't work offline either.
If offline support is a major part of your app's design, LiveView isn't a good fit. But you could still use Phoenix Channels (the building block underneath LiveView) to provide fast push updates to your client. See the channels docs for an idea of how they work - https://hexdocs.pm/phoenix/channels.html
When I see a Phoenix post, I upvote. It's so great in terms of almost everything - simple, productive, powerful, and fast. If you're a web developer, go try it out if you haven't. I might be too greedy, but if there could be a solid JavaSript support Elixir/Phoenix just like ClojureScript that would be perfect. Phoenix and Liveview are great, but I really hope it can extend its reach to React Native and Electron so t…
Earlier quoted context omitted.
The other side of that coin is the huge amount of unmaintained risk in the Ruby community. When you delegate business logic to someone else's efforts you taking on the risk that the library will be maintained and patched for the lifespan of your application. As someone else already pointed out, many of the solutions in Elixir are significantly more simple to just "roll your own" rather than have to worry about pullin…
That's the same risk you have with any open source project. Elixir and Phoenix have similar risks. I think there's a lot to be said for getting default/easy functionality for free so you can focus on building your unique amazing things vs working on plumbing.
Yes and no. The larger the number of dependencies you have, and the larger number of maintainers that are behind them, the more chances you have of one of them containing malicious code.
I think you're pretty safe from Phoenix or Rails or NodeJS getting owned because so many people work on them. But one of the thousand small packages you use may belong to someone careless or malicious.
When I see a Phoenix post, I upvote. It's so great in terms of almost everything - simple, productive, powerful, and fast. If you're a web developer, go try it out if you haven't. I might be too greedy, but if there could be a solid JavaSript support Elixir/Phoenix just like ClojureScript that would be perfect. Phoenix and Liveview are great, but I really hope it can extend its reach to React Native and Electron so t…
Lumen may be the answer to this in the future: https://www.youtube.com/watch?v=uMgTIlgYB-U&list=PLqj39LCvnO...
Implementing runtime for Elixir in JavaScript is quite challenging IMO. Kudos for Dockyard trying to tackle this.
Earlier quoted context omitted.
For me static typing is essential not when I am writing a new application from scratch, but when I am coming into huge old legacy code projects. For example, I am currently working on a messy and old Swift / Objective C application and having first class IDE support for things like calling hierarchies is pretty amazing to unwind spaghetti code. Also, it's a good feeling to be able to delete a big chunk of code and be…
I definitely get the point about static typing. I've seen the same need in legacy codebases myself. :-) That said, I'm head-over-heels for Elixir. As for autocomplete and such, there's a pretty good project for vscode called something like "Elixir LSP (fork)". Be sure to use the fork version, it's a continuation of the old stale original extension. In more general terms, the `elixir-lsp` project is pretty solid (and…
https://elixirforum.com/t/introducing-elixirls-the-elixir-la... The fork will probably be deprecated soon
Earlier quoted context omitted.
> Are many of the other languages you've used strongly typed? That's the thing that gives me pause - I feel like I rely on the compiler a lot in languages where it can do a lot for me, and that I'd be really frustrated managing a large project without it. As someone who has been writing Elixir professionally for 4-ish years, and who is otherwise about as big of a proponent of static types as is possible, this is simu…
"hasn't been slowing me down" --> would it slow a new developer who approaches the code base? or 30-100 people who work on the codebase?
That being said, with the tools I described, you still have type annotations and automated type checking, so the documentation benefits of static types are still present.