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

Phoenix 1.0

phoenixframework.org

Post reply on HN
Print view View original

181–190 of 228 posts

Re: Phoenix 1.0

#181

Post by prapam2 »

ChuckMcM wrote: post #160
davelnewton wrote: post #146

Earlier quoted context omitted.

Describe a "new problem". I only rarely encounter truly unique problems. One thing it does do is allow scalability in a pretty straight-forward, integrated way.

I like the scaling aspect of it very much. There are lots of "new" problems with respect to changing conditions in our day to day lives. Here are a few - Identity management across Internet and non-Internet properties - Configuration, control, auditing, and monitoring of billions of Beacon level devices - Zero knowledge proofs as a technique for anonymous and no repudiated purchases online - "home" level cloud servic…

These seems like architecture level problems rather then framework level.

Re: Phoenix 1.0

#182

Post by davelnewton »

niklasni1 wrote: post #152
davelnewton wrote: post #142

Earlier quoted context omitted.

I've heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.

Having worked with Scala a lot recently, I've found that the ability to turn logic issues into type issues is an incredible gain for my productivity. OCaml programmer Yaron Minsky summed it up nicely with the advice that you should "make illegal states unrepresentable". He gives a good example of modelling a network connection in [0]. Another example is instead of shuffling a bunch of bare UUID objects around (or str…

I wouldn't classify those as "type problems" but rather "using types to solve problems". I have no issue with the claim that great type systems make some... ahem... types of problems go away, although it's often trading one type of complexity for another. My issue is with the claim that "long term development is intrinsically better with static typing".

Re: Phoenix 1.0

#183

Post by davelnewton »

cgag wrote: post #178
davelnewton wrote: post #142

Earlier quoted context omitted.

I've heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.

If you haven't used a good type system (which has at least algebraic data types and pattern matching), it's hard to realize how many of those bugs might actually be type issues.

I'm not claiming that good type systems aren't useful, I'm claiming that the statement "Go is better for long-term development because it's statically typed" is more like FUD than actionable information.

I also agree that good type systems can reduce some forms of complexity (while often introducing another, but that's a different discussion).

Re: Phoenix 1.0

#184

Post by davelnewton »

strmpnk wrote: post #156
davelnewton wrote: post #141

Earlier quoted context omitted.

Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here. Elixir's functionality comes from BEAM and the language, not Erlang.

Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.

I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.

Re: Phoenix 1.0

#186

Post by angersock »

MrBra wrote: post #167
rubiquity wrote: post #132

Earlier quoted context omitted.

I know you're being downvoted but I 100% agree with you. I don't want 100,000 Hex packages. I want a few thousand packages that solve problems really well and people rally around and collaborate on them. NPM and RubyGems are casualties of people seeking open source fame and I hope we can avoid that in Elixir.

This is totally nonsense. Any among those 100000 could become the most used library in their specific field at some point in time, and the fact that you can choose to contribute to whichever you like more, or create your own is the beauty of OSS. If you fear this will weaken devs ability to focus their strength on just one common solution, and be inefficient, then you really don't know how OSS works. What you want to…

Counter-argument: the entire Javascript ecosystem.

Re: Phoenix 1.0

#187

Post by pmontra »

prapam2 wrote: post #180
bphogan wrote: post #177

Earlier quoted context omitted.

I did. I love Rails. Love it. Love Ruby. I've been writing code for over 25 years this year, and I've been doing Ruby for 10. And I hit a big brick wall with a very websocket-heavy app I'm building. I switched to Elixir and Phoenix last year and got the core of my app working. It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confi…

But you woudn't need gems to for recovery emails right?

The Devise gem does that for free. I remember me coding it in my first Rails application so many years ago and I'm not keen to go back to it: it feels like wasted time. Phoenix didn't have it one year ago and it's sad to learn that it doesn't have it yet. Somebody will write it sooner or later because it's almost core functionality of a registration and authentication system.

Re: Phoenix 1.0

#188

Post by fghfghgfhfg »

davelnewton wrote: post #182
niklasni1 wrote: post #152

Earlier quoted context omitted.

Having worked with Scala a lot recently, I've found that the ability to turn logic issues into type issues is an incredible gain for my productivity. OCaml programmer Yaron Minsky summed it up nicely with the advice that you should "make illegal states unrepresentable". He gives a good example of modelling a network connection in [0]. Another example is instead of shuffling a bunch of bare UUID objects around (or str…

I wouldn't classify those as "type problems" but rather "using types to solve problems". I have no issue with the claim that great type systems make some... ahem... types of problems go away, although it's often trading one type of complexity for another. My issue is with the claim that "long term development is intrinsically better with static typing".

The type system, at least more powerful ones, encode a lot of intention and more importantly, enforce it.

It might add some additional complexity in the first writing of the code, but in return you eliminate whole classes of problems forever. It's not just the initial writing that benefits (at some cost, admittedly), but all future changes won't have those problems either. In the case the types themselves need to change to account for expanded functionality or whatever, you again pay some cost in complexity, but in return every place the new type would cause problems you get a nice error.

The other thing to keep in mind is that whether or not these type are codified in the language they're there conceptually. Just because you have to write them down doesn't necessarily add complexity but is more like forced documentation that can be used to eliminate who classes of problems. It's difficult to see how this wouldn't intrinsically be better than so-called dynamic typing.

Re: Phoenix 1.0

#189

Post by danneu »

rubiquity wrote: post #132
angersock wrote: post #106

Earlier quoted context omitted.

It's great having new people, but hopefully we'll avoid the clusterfuck of gems and node modules that are the hallmark of the perpetually-immature web development community.

I know you're being downvoted but I 100% agree with you. I don't want 100,000 Hex packages. I want a few thousand packages that solve problems really well and people rally around and collaborate on them. NPM and RubyGems are casualties of people seeking open source fame and I hope we can avoid that in Elixir.

    > NPM and RubyGems are casualties of people seeking
    > open source fame and I hope we can avoid that in Elixir.
No, they're casualties of people actually using the platform, the platform's low publishing barrier, and the ecosystem's preference for focused libraries over monolithic bouncy castles.

Rallying around one library sounds cool until you see that the top three competing solutions in another ecosystem each have more contributors and activity. Then you realize you're not in the elite ecosystem, just the smaller one that has one library like my tiny Texas hometown.

Re: Phoenix 1.0

#190

Post by MCRed »

lpsz wrote: post #117
aaron-lebo wrote: post #104

Earlier quoted context omitted.

Elixir, in my experience, is a much more productive and powerful language. If you are a one-man-show I'd pick Elixir any day. Here I am pimping my own stuff but I wrote a related article on this: http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-...

Thanks, I actually read! "The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps." I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go…

And elixir/erlang are great for writing custom servers handling custom protocols.... but you're better off just dropping in Cowboy and working at a higher level.

Go is really compelling in producing a single-binary application... but for web apps, I think Elixir wins because it's working at a much higher level, and thus you're more productive.

Post reply on HN