[erlang-questions] your first choice?

Fri Feb 20 18:47:03 CET 2015

@David: I agree with all of your points. Having been in this business for a
long time, time-to-market is always of high priority, if you are in the
game to make money. So, getting something up and running quickly, something
that can be shown to potential customers, or better yet, VCs, is very
important. I recently worked on a project that was done entirely in
python/wsgi mainly because of time to market. That product would be better
done in Erlang/OTP, but there was simply no time for the development team
to take on that learning curve.

@Peter: I am in the same position you are. I desperately want to become
proficient with Erlang, and have taken on a project to develop a web app,
the particulars of which I am pretty familiar - I won't have a lot to learn
about the "interesting problem", as I've been through all that before. So,
my focus is on how to implement that in Erlang. I've only been working on
this for a couple of months, and I don't really have a lot of time to spend
on it due to the fact that I have a day job that keeps me too busy. Here's
where I stand after going through the same process of discovery that you
are going through. YMMV, of course:

I originally thought about doing this as a Haskell/Yesod project, but got
bogged down in Haskell's infamous "dependency hell" issue. Yesod claims to
be able to handle 100k+ concurrent web connections, which is why I first
thought about going that way.

After getting frustrated with Haskell, I fell back to Erlang, which I
already know, somewhat. I don't know enough to be hired to do Erlang for a
paycheck yet, but I'm definitely trying to get to that level. At the same
time, I discovered Elixir, which runs on the Erlang vm, and spent a couple
of weeks looking at that. My impression of Elixir is that it looks
promising, but is still rather immature, and will need some time to become
industrial strength. So, once again, back to Erlang.

What I now have is the beginnings of a web server, written in Erlang, using
gar1t's e2 framework (makes OTP easier) and his modlib (makes working with
erlang's httpd module way easier).  Here is my current tools/frameworks
list:

Language: Erlang R17
Frameworks: e2 on top of OTP
                      modlib for the web framework.
Data storage: Riak 2.0.4 - storage of metadata. Storage of user data TBD.
JSON - I hate XML.
Eclipse rather than IntelliJ, simply because I've been using Eclipse for
about 15 years.
Linux. I hate MS worse than XML. But that's a "religious" issue which we
really don't need to discuss, cuz it will get us nowhere.

I would be happy to share my experiences with you as I progress through
this project. Drop me a line any time.

Thanks all,

Michael

On Fri, Feb 20, 2015 at 10:49 AM, David Welton <davidnwelton@REDACTED>
wrote:

> > Indeed, the great lure of frameworks are they make prior choices for you
> > under the pretense the choices are correct and useful for your problem.
> By
> > making the decisions quickly, you get a minimum viable product faster and
> > have a shorter time to market. In turn, you gain the de-facto monopoly
> > anyone hopes to get.
>
> It doesn't even need to be about a monopoly, but about just getting
> something out there and figuring out if there's a viable business
> there at all.
>
> > So you need prior knowledge of what problem you need to solve, or it is
> > square pegs through rounds holes all the way down.
>
> You don't necessarily get that, so sometimes it's best to get up and
> running quickly and start learning.  Maybe out of 5 features you had
> in mind, the customers love 1 and buy your product for it, and don't
> care much about the other 4.  It's difficult to know that a priori.
>
> > The crux of my argument is based upon the prior choice of features.
> First, you need prior knowledge of the framework itself. You need to know
> its performance model: what is fast and what is slow. You need to know the
> internal architecture. Otherwise, you are probably worse off than just
> writing the code. A network effect is apparent: the more you work in a
> framework, the more accumulated knowledge you have and the faster can you
> build new stuff. The 10th Rails project is easier to write than the 1st.
> Second, your problem has to match the frameworks framing, in the sense that
> the problem space you are facing matches somewhat well with that of the
> framework. As an example, it is hard to take the MVC pattern and fit into
> an Event Sourcing/CQRS model. Of course you could learn a new framework,
> but this requires prior knowledge as well.
>
> You actually may not need to know the framework that intimately.
> There are a whole slew of problems that you could solve with pretty
> much any old thing out there, given how bad existing solutions are.
>
> > My claim is that any interesting problem has high risk.
>
> For a business, at least, in a lot of cases the risk is 'market' risk,
> though: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2325 -
> which may not correspond to an 'interesting problem' in terms of
> technology at all.  You could use PHP and MongoDB and whatever other
> icky tech, and it'd probably work out if you get that one key thing
> that makes people want to buy your product.
>
> As a well-known example from the world of bootstrapped businesses:
> http://www.bingocardcreator.com/ which has been amply discussed
> online.  He originally made it as a downloadable Java program, then
> redid it as a Rails web application. Realistically, I'm sure he could
> have used pretty much any old thing he knew well enough: the
> 'interesting' part of BCC is not the technology, but the marketing he
> put into it.
>
> >  In turn, any
> > interesting problem is unknown by definition. Hence, you don't know a
> priori
> > if your framework fits the problem in any way, and learning one is more
> or
> > less hit-or-miss. You may get a lucky strike, but it was definitely not
> by
> > considerate aiming of the weapon.
>
> From that point of view, even tools carry risks.  Twitter started with
> Ruby on Rails, which, much as it's nice for some things, is manifestly
> the wrong thing to be using for what they do.  Postgres, which I
> happen to like a lot, is the wrong thing for some problems.  Erlang
> itself is the wrong tool if you need every last bit of performance
> from your CPU to crunch numbers.  And yet Erlang is still probably not
> a bad starting place if you don't know that ahead of time: you could
> use it to manage the number crunching code, and you're likely to get
> some kind of system up and running a bit quicker than if you hand code
> it in C.
>
> > This is why I prefer tools to frameworks. For a risky problem, the
> freedom
> > of picking tools for the job dwarf the advantage of using a framework. I
> > thrive much better by gluing my own solution together.
>
> Backing away from the abstractions, the guy asked about creating a web
> application.  That's a known problem and involves some of the
> following:
>
> * A web server.
> * Something to connect it to to run code dynamically, rather than
> simply serve static web pages.
> * Some kind of templating system.
> * Some kind of data store.
>
> Having a starting place that does all of that is a good jumping off
> point for working on whatever it is that is actually interesting to
> customers.  Having something to start from also means you will
> discover sooner, rather than later, if it's not adequate for what you
> need, and give you firmer ideas about what you actually do need.
>
> This is also an information asymmetry problem: people who are just
> getting started are the ones least able to evaluate a bunch of
> disparate tools, so giving them something that at least *works* out of
> the box is going to save them time and give them a leg up to a point
> where they are more comfortable, understand more things, and are able
> to start making any decisions about replacing bits and pieces or doing
> things differently.
>
> --
> David N. Welton
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150220/c8f557cd/attachment.htm>