The feature widely advertised about Erlang is its ability to hot-swap code modules while the app is running and is shown as a unique killer-feature not available in other languages.
Here is a quote from Joe Armstrong's book:
Most servers execute a fixed program, and
if you want to modify the behavior of the server, you have to stop the server
and then restart it with the modified code.
Though, in context of web development, the majority of languages support so-called hot-swapping of the code even without calling it so. It's just updating code and publishing it on the web via git or a continuous integration solution.
I know Erlang has a lot of applications in domains other than web, so I am sure it makes sense in those cases.
But, does this feature have benefits in comparison to dynamic languages used for web, like Python, Ruby, JavaScript? What are the cases for web development where it outperforms popular web-oriented languages?
The hot code swaping in erlang offers more than the ability to upgrade the code (I won't make any comparison with python, ruby or javascript, I have a very limited knowledge of them):
You can decide, for each node, when you will load a new version of code
Then 2 versions of code will be present in the VM, all the running processes will use the old version of each module until a next fully qualified call to this module occurs (Mod:Func/arity)
if you are using OTP behaviors, the server (or fsm or gen_event) will be called first with their code_change call_back, receiving in the parameters, the old version of the module. So it is possible to check either or not it is possible to manage the upgrade, and to perform any necessary operation on the state Data, ETS, process synchronization... before really jumping into the new code.
if you are not using OTP behavior, it is still possible to receive the messages of the form {system, From, Req} and then call sys:handle_system_msg/6 which in turn will call the code_change call_back.
This feature is not targeted at web development just as Erlang itself was not created with web development specifically in mind.
One possible area where this feature outperforms model used in general dynamic languages used for web is precise control over the way code is upgraded.
code can be updated not only between calls, but also during call
you can provide explicit path of upgrade for state related to call
Related
Can someone explain what does this phrase mean in this sentence?
Dart is a client-optimized programming language for apps on multiple platforms.
The first thing you need to understand is that it is about optimization by the Dart developer (that is, Google).
This means that Google does not optimize Dart for use in applications other than client-oriented applications.
For example, in Dart there is no such thing as RDBMS (Relational Database Management System) and Google does not plan to contribute to this kind of development (to optimize the use of this type).
All software like this is very fragmented and not compatible with each other due to the lack of optimization from the developer’s side.
Simple, dart use a Dart Virtual machine that helps to optimize the code and compile just in time super fast and render or re-render UI very easy, Dart VM works very similar that JVM with Java, Dart Virtual Machine compile your code to low level very fast so if you want to build web apps, mobile apps o desktop apps you will has a full optimized machine code, for Flutter, dart VM compile from Dart to C++, for the web Dart VM compile from dart to Javascript, Dart is a good robust language designed to make very easy characteristics like Hot reload and Hot restart.
A programming language optimised for building user interfaces with features such as the spread operator for expanding collections, and collection if for customising UI for each.
For example spread operator
var list = [1, 2, 3];
var list2 = [0, ...list];
assert(list2.length == 4);
To clarify, the "Client" in Client-Optimized is referring to the actual user client, same idea as as Client/Server in web technologies.
Here it refers to the part of the App that is responsible for sending requests to the rest of your App for it to do all the functions you've built it to do.'Client' here includes the front-end parts that the person using your application is interacting with
For many reasons (including the ones mentioned in the other answers), Dart is really well suited to make all things Client run super smoothly. Its Optimized how it renders the UI, the layout, the animations, the load times, how it compiles, etc so everything the user (or "Client") does is Optimized.
As mentioned before, it lacks optimization for things that are not client facing such as database management.
This is a somewhat general question but I'm hoping someone will have specific info or recommendations.
I have an application suite that includes a service application that acts as a communications interface and data historian for industrial pollution-control hardware. The service contains a singleton COM server to allow the rest of the suite to have access to the hardware and data via the service.
I've read the stuff about how SvCom is required to make COM servers work in Delphi service apps. I have and use SvCom - it does what it claims. But I'm not all that comfortable with it, the product and my coding styles and expectations don't match, and it makes debugging somewhat more of a headache.
But my real problem is with the idea that the lengths SvCom goes to to make a COM server work in a service app is absolutely required. Their documentation, and some of the stuff that comes up in searches on the subject, makes it sound like their toolbox is absolutely required for any COM-server-in-service scenario. But I have a couple of different 3rd-party libraries for implementing OPC servers, Prosys Sentrol and the older Production Robots library (if you're not familiar with OPC, it's a pretty-much ubiquitous data-interchange standard built on COM) and both support the OPC COM server being put in standard TService-based apps without special handling beyond doing in the AfterInstall and BeforeUninstall events what would normally be done in a stand-alone EXE when run with the /regserver or /unregserver command-line switches, and of course using DelayInitialize := True. So at least SOME COM servers can be done as typical TService-based apps without the extraneous steps SvCom goes through.
So my question is: Is the line between "what sorts of COM servers work in a TService-based app" and "what causes the need for the extra stuff SvCom does" clearly known? If so, what is it and/or where is it documented? If not, I'm kind of surprised - seems like implementing COM servers in service apps would be a fairly common need, but I've does several deep searches and, based on the dearth of info I've found on the subject, maybe it's not.
Possible Duplicate:
What Web Application Framework for Delphi is recommended?
We have a Delphi 2007 desktop application which we have hosted using Citrix. Now we want to get rid of Citrix and somehow web-enable it.
I have done bit of research and found that it is possible by using the uniGUI.
http://www.unigui.com
Conclusion: Can be done, but would require a re-write and only a subset of components are supported. Serious questions remain are the monolithic application structure in a web environment.
There are two more options morfik and atozed and they also require a re-write.
I want to know if there is any other option which requires a very less re-write work and how fragile is it?
How fragile it is, is based on the quality of your code. If you have a good structured application, with business logic and data access fully separated from the GUI, it will be pretty safe, although you still have to rewrite mostly all your GUI.
If there's logic in your forms, and the code that talks to the GUI components is intwined with the code that checks your input and stores the data, then you have a big problem.
In that case, this is a great opportunity to refactor large portions of your app and do it better this time. ;)
Since there is no "silver bullet" here, it doesn't matter much which product you use. You have the same challenges with any of them. I would recommend spending a few days on a Proof-of-Concept (PoC) re-write of 2-3 typical screens. Implement the POC for each "finalist" product, and see how it works out. Keep track of how long it took for each one, things that were easier/harder, and how the end result appears to the end-user (performance, good/funny-looking, robustness, "feel").
As for the actual re-write, I would recommend the following:
Re-factor existing application to remove business logic from the UI.
Full Regression testing, and push that into production.
NOW proceed with conversion to one of the web tools.
Oops - I left out a step. Step 0: FREEZE all features/fixes. If fixes are needed to current production, they'll need to be done in a separate branch, and then rolled-up into this project later.
Note that this type of work lends itself nicely to outsourcing, as the work is straightforward and the requirements are simple. Especially if it can be delivered one form at a time, so progress, timelines, and $$$ can be measured in small chunks.
Another preliminary step is to develop a "cook book" for stripping the business logic from the existing GUI layer. It should identify naming conventions, common libraries (for code that should have been shared all along but wasn't), and should describe the conversion methodology.
AFAIK, there's not tool will convert your desktop application to web application without requiring rewrite for most of GUI Parts.
as Golez said, you will have to refactor your application, try to separate your business logic from the GUI, then you can use some tools like Intraweb to develop the GUI as web and reusing the existing business logic with it.
Another option by converting your application to n-tiers technology and warp your business logic as web services or any open technology and make your web part by any web languages such as ASP.Net or PHP.
Depending on how 'Web enabled' you want the App to be.. I use Cybele Software's (https://www.cybelesoft.com/) Thinfinity UI to extend Apps to the Web, including Database Apps.
It only requires the installation of their ThinFinity Server and one line of code added to the Proj source and you are in business.
The Apps all run on your PC.
Well perhaps I simplified it a little, but worth a look.
HTH.
Regards,
Ian
Just started reading the OTP chapter on the great Erlang book by Francesco Cesarini. Are most Erlang applications such as MochiWeb, Riak, RabbitMQ, Zotonic, ejabberd and CouchDB OTP applications?
CouchDB had lot of problems with that but the newest sources published by Cloudant show CouchDB in rebar, so it must be otp compliant.
Riak - the same, on rebar (btw. the same devs rebar and riak). Btw2. it is very nicely written app, good place to learn good practices.
Zotonic source code looks like mess a little bit. I can see there 'application' etc. but directory structure do not look like any proper OTP node. Btw. even Licence is not added on the top of all modules :?
ejabberd is full of sups and apps, but it has also some interesting;) design choices, so maybe do not learn Erlang on this example.
The Hibari database app is definitely OTP-based. The server is broken into several OTP apps, including a small one for managing config and logging (gmt), a big one for the server itself (gdss), a small one for native Erlang clients (gdss_client), and separate OTP apps for each of the server-side protocol handlers (e.g. JSON-RPC, UBF, EBF/BERT).
Sometimes a picture is worth at least a few hundred words. I've got some screen captures from the Erlang "appmon" (application monitor) app that shows the supervisor-and-worker process tree. Sorry, the protocol handler apps aren't shown in image #01, but they would be if I had had them running when I captured the image.
The link is here: OTP 'appmon' screen shots
-Scott
MochiWeb follows basic OTP Design Principles: it utilizes supervisor(3) behaviour to restart crashed processes (module mochiweb_sup.erl), and gen_server(3) behaviour. However it implements many routines to process data, such as ones found in mochinum.erl for faster floating point numbers serialization and mochijson[2].erl to process JSON etc.
The bad thing with mochiweb (I made it clear why here) IMHO is that it uses questionable and officially undocumented (since 2003!) technique of modules parameterizing (module mochiweb_request.erl, notice -module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]). in the head of the file). The same applies to another Erlang HTTP-library misultin (misultin_req.erl).
Correct me if I'm wrong.
I've been checking out the Nitrogen Project which is supposed to be the most mature web development framework for Erlang.
Erlang, as a language, is extremely impressive. However, with regards to Nitrogen, what I am not too keen about is using Erlang's rather uncommon syntax (unless you're native in PROLOG) to build UIs.
What is your experience with it as opposed to other mainstream web frameworks such as Django or Rails?
I've done very little with Nitrogen so far, but I've been monitoring the mailing list for months, so I think I have something useful to say about it.
To your concern about the syntax of Erlang and the Nitrogen framework, I'd respond that that sounds like a pure case of unfamiliarity, rather than unsuitability. Objectively, HTML is not a beautiful language, and it has plenty of quirks. You're used to this now, so it doesn't seem so bad. Give Nitrogen/Erlang a chance and you may find that you get used to it soon enough, too.
To your question about comparison to other languages and frameworks, I'd say the biggest difference is that with Nitrogen, the entire web site is being served directly by the Erlang runtime. Ruby on Rails has such a mode, but it's intended only for testing. Many other frameworks don't even offer the option of running everything within a single long-running process.
Running the entire web application and its underlying infrastructure within a single long-running process has significant implications on how the site runs:
With Apache, each child gets killed off every N connections, where N=500 or so, and you can't say whether a given child will always handle all of a given client's requests. Because HTTP is stateless but web apps almost always require some client state, an Apache child must rebuild its view of client state as part of handling a new connection. By default, this means going back to disk for persistent data stored about that client. There are alternatives like memcached, but these aren't built into the core of a LAMP type stack. With Erlang, nothing is killed off periodically, and Erlang offers standard facilities like Mnesia which provide disk-backed in-memory DBs.
Incidentally, if you're familiar with nginx, it's built on the same principles as Erlang, and it's fast for the same reason. The main difference between nginx and an Erlang instance running a web server is that nginx isn't a programming environment, so it still has to delegate a lot of processing to outside code. That means it shares the same IPC and persistent state problems as Apache.
Because the runtime stays up continuously and is a fully-functional programming environment, you can probably build more parts of your system in Erlang than with a lashed-together LAMP type stack. This magnifies the above benefits. The various parts of your system can coordinate via message passing and Mnesia instead of heavyweight IPC and MySQL, and all the pieces stay up and running continually, leading to less time-consuming state reconstruction.
A dozen or so Apache children all accessing the persistent client state data store is a lock-based hairball. The frameworks all handle locking and such for you transparently, but what they can't hide is the time it takes to do all this correctly.
Erlang is an impure functional language, which implies but does not require data purity; it is also built with multiprocessing in mind, going clear down to the core of the runtime design. These two facts mean you're less likely to spend time waiting on locks in an Erlang based server than one naively built on one of the other frameworks. It is certainly possible to optimize away lock delays in the other systems, but is that really what you want to be doing? Do you want to be on the thousandth team that has to learn how to optimize its web stack after the service becomes popular, or would you rather leave it all up to the tooling so you can spend your time doing something no one else has done yet?
I, too, was once concerned about clunky Erlang syntax. I've built a couple of tools to alleviate its annoyances for everyday web programming, and perhaps you will find one or both of them helpful:
ErlyDTL is an Erlang implementation of the Django Template Language; it's not available in Nitrogen, but it is available in other frameworks, such as Zotonic, Erlang Web, BeepBeep, and Chicago Boss
Chicago Boss is a full-stack Erlang framework that does a lot of code generation so that you can access data fields with function calls instead of Erlang's rather verbose record syntax (e.g. Person:name() instead of Person#person.name)
Note that Nitrogen does not include a database layer, so it's not really comparable to Rails or Django. For a comprehensive comparison of the database-driven frameworks, check out my answer to this StackOverflow question:
https://stackoverflow.com/questions/1822518/current-state-of-erlang-web-development-frameworks-template-languages/2898271#2898271
I would check out Webmachine if I were you. It is quite simple, fast, and leaves the interface up to you.
Erlang Web should also be considered mature. It is an MVC framework, whereas Nitrogen is more event based. It's a matter of preference.
I haven't used the other tools mentioned here except Webmachine, which I think it's a wonderful tool, but it is not a web framework like the others. It is as HTTP processor, and is ideal for building a restful interfaces.
I would also suggest you give the Erlang syntax a chance. Erlang is one of my favourite languages to use.