3 ms·

I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor)

I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality.

laut 12y ago
Javascript has functional features too. A lot of Elixir developers come from platforms such as Python, Ruby, node.js
- alco 12y ago
  JavaScript has functions. The list pretty much ends there. There are some libraries that provide "functional features" like functions over collections, persistent data structures, promises. The language itself and the environment it's running in (DOM or Node) do not have a lot going for them in terms of functional programming essentials.
anonyfox 12y ago
plus, you can use (or mix&match) other languages that compile to JS if you want. Coffeescript is the most popular choice (I code in literate coffeescript by myself), but stuff like livescript adds some more functional features as well.
copsarebastards 12y ago
1. "Realm-time" isn't baked in. It certainly comes easier to write real-time programs (for some definitions of real-time) than in some other environments, but real time programming doesn't come for free in any environment. You're overreaching with this claim. 2. Tons of programmers know JavaScript well enough to avoid it. A language originally thrown together "to make the monkey dance" is generally a poor choice. 3. Sane templating engines are a dime a dozen. I could probably find 5 in Python alone. 4. Same later realization that it's really good at a few things at the expense of others, I'd bet. 5. Okay I'll cede one point. > Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality. That says more about you than about the quality of tools involved. I'd rather have quality of mindshare than quantity.
lectrick 12y ago
> but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. 1) Once upon a time, almost no one used object oriented languages except for Smalltalk weirdos. 2) Ruby, javascript and a host of other languages have "functional" features. Does your language have a "lambda" feature, where you can define nameless functions and pass them around as arguments to other functions? Then you are already working with functional language paradigms. There's nothing really "magically hard" about it, you're overselling how hard it is. This is not rocket science. Most existing programmers can handle it. The hardest thing I had to wrap my mind around when switching my work to Elixir was letting go of mutable state. And attributes and methods on objects. And guess what... It seems that it's a good idea, generally! If you see enough bugs that are only there because something modified an attribute in some unpredictable way which impacted upstream code... You will realize mutable state is bad. If you still aren't convinced that mutable state is evil, watch this Rich Hickey presentation http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... which basically proves that mutable state actually makes state a function of a hidden/conflated "time" variable, proving it's not just wrong from a practical standpoint (in the form of extra bugs that are hard to reason about, and all this brittle mutex code) but from a theoretical one, too. Mutable state comes from a time when memory was expensive, and it's time to ditch the training wheels so we can get the real work done. Both Javascript and Ruby use mutable state extensively, and it's unfortunately not something you can just slap onto the language after the fact (although ClojureScript must make a valiant effort!) And if the high-level language wasn't built with it from the get-go, then you're stuck dealing with legacy libraries using the poorer-written code (see: Ruby gems).
- ab5tract 12y ago
  Right... Another fad brought up for the sheer fashionability of it. Saying "mutable state is bad" is just as inane as saying "immutability is bad". There are tradeoffs for either. There is absolutely no reason to pretend that one trumps the other in all cases. Other than looking cool to your peers, I guess.
  - 12y ago
tim333 12y ago
I like Meteor and have been learning it but it's not without it's drawbacks. It's basic design of loading a javascript app which then receives data from the server and renders the page makes load times kind of sluggish - compare HN and https://crater.io/ https://crater.io/ which is Meteor's HN equivalent. I've yet to find a Meteor site that's snappy. Also the design makes things like uploading photos a pain. If you look at the user pics on crater.io they are hosted on Twitter and Wordpress I think partly because doing that on a Meteor server is awkward - I've been writing a Meteor photo uploader and it can be done but most Stackoverflow answer suggest to give up and use S3. I wish them luck though.

laut 12y ago

Javascript has functional features too. A lot of Elixir developers come from platforms such as Python, Ruby, node.js

alco 12y ago
JavaScript has functions. The list pretty much ends there. There are some libraries that provide "functional features" like functions over collections, persistent data structures, promises. The language itself and the environment it's running in (DOM or Node) do not have a lot going for them in terms of functional programming essentials.

anonyfox 12y ago

plus, you can use (or mix&match) other languages that compile to JS if you want. Coffeescript is the most popular choice (I code in literate coffeescript by myself), but stuff like livescript adds some more functional features as well.

copsarebastards 12y ago

1. "Realm-time" isn't baked in. It certainly comes easier to write real-time programs (for some definitions of real-time) than in some other environments, but real time programming doesn't come for free in any environment. You're overreaching with this claim. 2. Tons of programmers know JavaScript well enough to avoid it. A language originally thrown together "to make the monkey dance" is generally a poor choice. 3. Sane templating engines are a dime a dozen. I could probably find 5 in Python alone. 4. Same later realization that it's really good at a few things at the expense of others, I'd bet. 5. Okay I'll cede one point. > Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality. That says more about you than about the quality of tools involved. I'd rather have quality of mindshare than quantity.

lectrick 12y ago

> but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. 1) Once upon a time, almost no one used object oriented languages except for Smalltalk weirdos. 2) Ruby, javascript and a host of other languages have "functional" features. Does your language have a "lambda" feature, where you can define nameless functions and pass them around as arguments to other functions? Then you are already working with functional language paradigms. There's nothing really "magically hard" about it, you're overselling how hard it is. This is not rocket science. Most existing programmers can handle it. The hardest thing I had to wrap my mind around when switching my work to Elixir was letting go of mutable state. And attributes and methods on objects. And guess what... It seems that it's a good idea, generally! If you see enough bugs that are only there because something modified an attribute in some unpredictable way which impacted upstream code... You will realize mutable state is bad. If you still aren't convinced that mutable state is evil, watch this Rich Hickey presentation http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... which basically proves that mutable state actually makes state a function of a hidden/conflated "time" variable, proving it's not just wrong from a practical standpoint (in the form of extra bugs that are hard to reason about, and all this brittle mutex code) but from a theoretical one, too. Mutable state comes from a time when memory was expensive, and it's time to ditch the training wheels so we can get the real work done. Both Javascript and Ruby use mutable state extensively, and it's unfortunately not something you can just slap onto the language after the fact (although ClojureScript must make a valiant effort!) And if the high-level language wasn't built with it from the get-go, then you're stuck dealing with legacy libraries using the poorer-written code (see: Ruby gems).

ab5tract 12y ago
Right... Another fad brought up for the sheer fashionability of it. Saying "mutable state is bad" is just as inane as saying "immutability is bad". There are tradeoffs for either. There is absolutely no reason to pretend that one trumps the other in all cases. Other than looking cool to your peers, I guess.
- 12y ago

tim333 12y ago

I like Meteor and have been learning it but it's not without it's drawbacks. It's basic design of loading a javascript app which then receives data from the server and renders the page makes load times kind of sluggish - compare HN and https://crater.io/ https://crater.io/ which is Meteor's HN equivalent. I've yet to find a Meteor site that's snappy. Also the design makes things like uploading photos a pain. If you look at the user pics on crater.io they are hosted on Twitter and Wordpress I think partly because doing that on a Meteor server is awkward - I've been writing a Meteor photo uploader and it can be done but most Stackoverflow answer suggest to give up and use S3. I wish them luck though.