Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phoenix 1.7 is View-less

germanvelasco.com

Post reply on HN
Print view View original

211–220 of 224 posts

Re: Phoenix 1.7 is View-less

#211

Post by Fire-Dragon-DoL »

toast0 wrote: post #209
Fire-Dragon-DoL wrote: post #207

Earlier quoted context omitted.

Turns out it was specific to the application I worked on, sorry for the misinformation. It is configurable: https://www.erlang.org/eeps/eep-0042

EEP 42 is not implemented in mainline OTP. If it were, the proposal would likely link to the implementation, and the EEP index in EEP 0 would show what version it was first included in: https://www.erlang.org/eeps/eep-0000 If your application is using something like this, you're running a modified beam (which is fine; my professional experience is on a modified beam where we added a process_info option to drop all me…

It's been a long time, so i could be wrong, but I remember we did face the problem at some point.

Either way, not having a limit makes it even easier to use, which I really appreciate

Re: Phoenix 1.7 is View-less

#212

Post by fud101 »

josevalim wrote: post #169
fud101 wrote: post #161

Earlier quoted context omitted.

it takes like 6 lines of code to have a working flask endpoint to deploy a quick and dirty API. About a billion files for phoenix. I hate that too.

Phoenix by definition assumes your projects will take longer than an afternoon. :) If you want a quick and dirty API, using Plug directly may be an option: https://gist.github.com/josevalim/fbfc669aa6087c5b79402b399d...

It comes down to whether you want to maintain a bunch of auto generated files which will never be automatically updated. I would rather maintain only the lines of code I write not ones that were generated by some tool and then immediately became legacy.

Re: Phoenix 1.7 is View-less

#213

Post by throwawaymaths »

ctvo wrote: post #183
throwawaymaths wrote: post #106

Earlier quoted context omitted.

The abstractions you need to critically know are map and reduce. It's not functional like Haskell, the limit at which you need to "think about it being functional" is that a value inside a variable can't change from underneath you when you pass it to a function. It pretty quickly changes from "I have think about values not chamging" to "I don't have to worry about values changing"

The abstractions I’m talking about are the Erlang VMs and the primitives like actors that are provided by the OTP. I have cold sweats thinking about needing to debug a non-obvious performance issue and diving into that layer.

Ok. Well there are a lot of other options for performance and no matter what system you're in (python, ruby, rust, jvm, c++) those kind of performance debugging is going to be a slog, and GenServers are relatively easy to work with and the VM gives you a lot of tools to figure it out. Most people at scale seem to be doing okay with elixir.

I will say the one thing that I do see coming up over and over again is OOM errors, but I personally feel that's because there are a few gotchas that juniors don't always know about

Re: Phoenix 1.7 is View-less

#214

Post by 59nadir »

sodapopcan wrote: post #33
enraged_camel wrote: post #25

Earlier quoted context omitted.

Actually, I think the next big unlock in user adoption is static typing. Lack of it is frequently cited as the number one reason that makes people hesitate in switching to Elixir. I know it is an active research project right now, and I hope it bears fruit.

Based on the number of attempts to add static typing to Erlang, I don't see this ever happening. I know the author of Gleam is going full-time working on it, but I really know much about it or how it gets around the problems with statically typing message-passing. I'm perfectly happy working in dynamic languages and find Elixir's type hinting to be more than adequate.

You've been able to write PureScript compiled to Erlang for years. PureScript is a well tested language at this point, and the Erlang compilation works very well. Statically typed message passing is a non-issue in practice and it has been a bad reason for not having it the whole time.

I've been using Elixir since 2015 and can confidently say there is no use case I would choose Elixir for over PureScript for the BEAM. In practice my projects are Elixir + PureScript because we can have them interoperate, but there are zero technical reasons to choose Elixir over PureScript for BEAM work.

Edit:

`dialyzer` and similar tools are unusable for almost all sizes of projects in part because they're badly made, they're too lax and have zero useful abstraction properties. Making a spec generic, for example, is an exercise in futility, whereas an actual type system has no issues with expressing that very basic property.

Edit 2:

As an upside you also have PureScript for your frontend, so you can just write everything in the same language regardless of how much frontend work you expect to be doing. PureScript has great bindings and a great story around React (it actually fits better since it's a purely functional language, so things like "You can only do effects in `useEffect` actually are enforced and make sense) and also has its own frontend framework in Halogen which is very nice.

Re: Phoenix 1.7 is View-less

#215

Post by 59nadir »

tiffanyh wrote: post #29
enraged_camel wrote: post #25

Earlier quoted context omitted.

Actually, I think the next big unlock in user adoption is static typing. Lack of it is frequently cited as the number one reason that makes people hesitate in switching to Elixir. I know it is an active research project right now, and I hope it bears fruit.

Has anyone figured out how to do static typing in Erlang yet? FB a few years ago announced they were going to work on it for WhatsApp but then it was indefinitely delayed. There’s also been a few other attempt, but I don’t believe anyone has succeeded. I know Gleam exists but haven’t dug into it. Anyone more in the know care to share?

You've been able to write PureScript that compiles to Erlang and has perfect interop for years, via `purerl`[0]. Using it with Elixir is as simple as adding `purerlex` as a compiler and having your PureScript code automatically compile when `mix` compiles things, and off you go.

In terms of the typing itself, it's exactly what you get in all of PureScript, strict static typing with no `any` or the like. Using `Pinto`, the de facto OTP layer in PureScript your processes are typed, i.e. their `info` messages & state are typed, which means that they are all much more like strongly typed state machines than anything else.

You can see an example of a basic `gen_server` here:

https://pastebin.com/UTEfz7Wg

The differences aren't very big in terms of what you'd expect to be doing. One small thing to note is that the `GenServer.call` expects a closure to be passed instead of having the split between `gen_server:call` & `handle_call`, removing the need for synchronizing two places for your messages being sent and handled.

0 - https://github.com/purerl/purerl

Edit:

As an upside you also have PureScript for your frontend, so you can just write everything in the same language regardless of how much frontend work you expect to be doing. PureScript has great bindings and a great story around React (it actually fits better since it's a purely functional language, so things like "You can only do effects in `useEffect`" actually are enforced and make sense) and also has its own frontend framework in Halogen which is very nice.

Re: Phoenix 1.7 is View-less

#216

Post by wstuartcl »

NhanH wrote: post #180
josevalim wrote: post #168

Earlier quoted context omitted.

The integration is still there and it is mentioned in our assets guide: https://hexdocs.pm/phoenix/asset_management.html#third-party... Regarding import maps, I am still slightly skeptical. First they don’t solve all needs of npm (for example, what if you need to precompile your FE code?). Second, I have feeling that every import map management tool will eventually become a package manager through slowly creep in of…

Is the plan to keep esbuild (and npm integration) for the long term, or would that be deprecated in a few years?

Snorted a little at this -- how can anyone forecast JS ecosystem 5 years out. =)

Re: Phoenix 1.7 is View-less

#217

Post by wstuartcl »

blueblahvlah wrote: post #136
blueblahvlah wrote: post #128

View-less meaning Phoenix.View module is refactored/replaced. The amount of boilerplate code is still a challenge in Phoenix. Worked on a large project using live views. Pros: - can achieve interactivity without using client side js frameworks - less developers / man power needed compared to client side js frameworks - evolving in right direction - community / forums Cons: - still evolving and releases are breaking (…

In my original post: - there was leex, then heex, now components taking centre stage. - most of the books, tutorials, videos, articles are stale due to frequent changes / evolution Last two points should have been one. Got split while composing the post. My mistake. - there was leex, then heex, now components taking centre stage. most of the books, tutorials, videos, articles are stale due to frequent changes / evolu…

regarding frequent changes, in my experience keeping 5 or 6 Phoenix/Liveview apps up to date the pain I have seen with changes is far less than I have experienced with Rails, Django and even front end updates required to keep react and vue inline. All of that when Liveview is not even a 1.0 yet...

I do get that books and other rotting materials obviously fall behind quickly but have you seen hard uplifts to codebases to keep them up to date?

Re: Phoenix 1.7 is View-less

#218

Post by kevinplusone »

Was excited to hear views are being dropped. Been creating Web applications for over 20 years and have seen very little benefit of using views. Always saw them as an extra layer to think about, especially when trying to find where a function/method is defined when maintaining code. I think the MVC/MVVC ideas as applied to Web development were a step forward in getting people to organize code in general, but a step backward in keeping coherent, colocated, and maintainable code as projects grow. I've found that reusable encapsulated components for structure and well documented utility classes for CSS styles have always been the most helpful tools for creating maintainable Web applications, which seems to be the direction Phoenix and LiveView are going.

Re: Phoenix 1.7 is View-less

#219

Post by hinkley »

sodapopcan wrote: post #33
enraged_camel wrote: post #25

Earlier quoted context omitted.

Actually, I think the next big unlock in user adoption is static typing. Lack of it is frequently cited as the number one reason that makes people hesitate in switching to Elixir. I know it is an active research project right now, and I hope it bears fruit.

Based on the number of attempts to add static typing to Erlang, I don't see this ever happening. I know the author of Gleam is going full-time working on it, but I really know much about it or how it gets around the problems with statically typing message-passing. I'm perfectly happy working in dynamic languages and find Elixir's type hinting to be more than adequate.

I'd like to see someone tackle a PhD thesis (or ten) on applying formalism to the concept of migrations. I suspect there's a missing aspect of type/group/category theory that's at least as big and important as variance is.

I think it might already mostly exist, it just isn't organized into a discipline.

Re: Phoenix 1.7 is View-less

#220

Post by 0x457 »

benatkin wrote: post #35
anamexis wrote: post #28

Earlier quoted context omitted.

What is your point?

Just to point out that "ZERO react/JS nonsense" is based on looking down on mainstream languages even after they've improved and even though the platforms use them.

I mean... It's hard to find anyone who prefers Java to Kotlin for Android development. I know people who still have Java One backpack, and they would rather write Kotlin over Java any day.

JavaScript...I didn't mind how quirky it is when it was SSR + a little jQuery for interactivity. nodejs, asset pipelines like webpack, React make me want to barf. They haven't improved at all.

LiveView looks very interesting and I wish Phoenix/Elixir was an option for me.

Post reply on HN