>
> I don't know if "the enterprise" is ready to accept Erlang/ErlyWeb,
> but I think there's a growing realisation that Java and C# aren't the
> answer to every programming question. Java now runs acceptably fast,
> but as soon as your code starts to spawn threads off it starts to get
> ugly.
>
> C# is pretty much in the same ballpark
I think a big issue with Java, C#, etc as far as concurrency goes
isn't just the shared memory issues but also that those languages make
programmers afraid (justifiably so) of spawning threads whenever they
needs them. This leads to the creation of threadpools, whose min/max
numbers of threads are usually arbitrary ("yeah, 20 threads should be
just fine for my app! I think...") and which cause bottlenecks that
are hard to identify. If you're building a desktop app that does a few
things in the background, that's probably ok, but for scalable,
reliable servers it's a big disadvantage.
>
> There's also the case that the languages themselves aren't necessarily
> the best fit for a large range of problems. In two big companies
> where I've worked, there's a dawning understanding of two issues: (a)
> the cost of buggy code is just way too high, (b) the cost of securing
> sensitive code against buffer overflows and the like is also extremely
> high; functional languages remove a large part of the opportunity for
> these two problems to arise.
>
> I don't necessarily think Erlang/ErlyWeb are going to get significant
> enterprise mindshare, but I think that something other than Java and
> C# will, very soon.
Yeah, I agree. It's hard to estimate how much adoption Erlang will
have in the enterprise even if it is a better tool that what is used
currently. The problem is the training of programmers who don't know
Erlang. I actually think that Erlang is easy to learn (I often tell
people that it would be easier for me to teach Erlang than Java to
someone who knows nothing about programming) but maybe I've been using
it for too long :)
Who knows -- maybe Joe Armstrong's book will tip the balance in
Erlang's favor. And one or two successful Erlang startups
(MochiMedia?).
>
> With Ruby on Rails, the M and C do what you'd expect; the V's job is
> to format what C hands to it. In a Web services context, that means
> that (typically) V's job is to take a hierarchical collection of
> objects from C, and deliver it in the appropriate sequence or with the
> appropriate format.
>
> For example, C might return a set of authors, and under that, the set
> of books they've written, ISBNs and so on. The V might present it as
> <authors>
> <author name=>
> <book title=>
> <isbn id=>
> but a different V might present the same info as
> <books>
> <book title=>
> <author name=>
> <isbn id=>
>
> In essence, the V layer can be used to juggle the hierarchy of data
> given it to by C. I realise this could all be done in C, but then you
> might wind up with multiple C layers to present identical data in
> different ways; Rails uses multiple V layers instead, and gives a
> domain-specific language (RXML) to allow you to tweak data as per the
> above in a very simple manner. Extending and maintaining RXML code is
> particularly simple.
>
> I like the way this works in Rails, but in the end it's a syntactic
> sugar more than a must-have feature.
I think that the main difference between web services and web apps is
that in web services, the framework can do the rendering for you
automatically based on the input data (the controller function return
value) and the protocol flag. I think it would be less efficient to
let the data undergo another transformation in the view layer -- why
not just serve it from the controller in the form in which it needs to
be consumed?
> >
> > "ErlyWeb = enterprise scalability + agile development". If we only had
> > a marketing budget... :)
>
> I strongly suspect ErlyWeb could scale far better than J2EE for some
> specific use cases. Erlang's ability to create new processes quickly
> (not to mention simply) gives it an advantage that must have some
> benefits...
I think so too. It would be interesting to see some real benchmarks
comparing Erlang/ErlyWeb against Rails and J2EE. I'm not sure what the
page render time difference will be under light load, but I think what
we'll see is that both J2EE and Rails crash at a relatively low number
of concurrenct requests but ErlyWeb keeps on serving them, albeit
somewhat slower at heavy load.
>
> Yep, I can see how that makes sense. I haven't really used JSON in
> any non-learning context, so I'm still coming to grips with how/where
> I should be using it. I've had a bit of a prejudice against
> JavaScript as a "toy" language for years, and now I'm finding I have
> to unlearn that prejudice.
It may be a toy language, but it made Google (and other companies) a
lot of money :)
Yariv
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"erlyweb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
