Hacker News Reader

Hacker News

Comment by sergiotapia | Hacker News Reader

Full thread

sergiotapia

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.

View on HN

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.

> 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-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).

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.

Nobody's "pretending" that immutability trumps mutability. Rather, we're observing it firsthand. By making immutability the rule rather than the exception thereof, one eliminates a huge swath of bugs and makes an even bigger swatch much more difficult to achieve.

That said, you're right that there are tradeoffs, which is why languages like Rust - while defaulting to immutability - allow a programmer to define variables as mutable, and why Elixir (unlike Erlang) allows variables to be reassigned (though the data stored in those variables is still immutable; this is something that's enforced by BEAM).

And of course, you can still get many of the benefits of immutability with mutable variables by being careful about how you're using those variables; the difference, however, is that a language which assumes immutability will be able to catch those bugs more easily, forcing the programmer to fix them (either by making the variable mutable (in applicable languages) or refactoring until mutability isn't necessary).

I spent over 10 years writing and working on (and debugging... many hours of debugging) Ruby code.

Towards the end I started to write all my Ruby code, as much as possible, as so-called PORO objects (Plain Ol' Ruby Objects). These feature zero inheritance, and are initialized with all the state they need to do their work. I started doing this because I found that writing code that way produced more easily testable, more maintainable, more stable code.

Then I realized that functional languages basically all already forced you to do those things, by not holding state anywhere, forcing you to pass it around.

These were all logical steps (with the end goal optimization of "useless work elimination"). There was no faddiness involved, other than having "a good feeling" about working with Elixir (over, say, Clojure, Haskell or the other options out there).

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/ 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.

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

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.

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.

Reply on news.ycombinator.com