I would really like to know about support for the following in Erlang.
Support for Windows COM. COM support in itself covers all requirements regarding accessing Access, Excel and Word documents. Both read and write.
PDF generation and printing. Note printing is easy if it can be done on a Windows printer server. And many printers don't have any driver beside Windows.
And a good database support which doesn't make any task harder than doing it on a SQL server. Erlang Mnesia is OK, given that there is nothing harder to perform on Mnesia than on any SQL server.
The business app that I am planning to port will be web based. It will be nice if I could port it to GUI later, but asking for that might be too much for Erlang, I guess. I am OK with that.
Edit: I would like to add that support for MS-Office is not that a big deal. A language only needs to support COM. And the whole microsoft world will be at your door step. Even Perl/PHP/Python/Ruby has COM support. Though none of those languages were born for the Windows world.
Even if I'm a great Erlang/OTP fan currently developing my application server (http://code.google.com/p/tideland-eas/) in Erlang I think it's not the right tool for you. Erlang is brilliant in the domain of concurrency, distribution, and reliability. But you need a tough integration into the Microsoft world. So maybe you should take a look at F# to get at least a kind of Erlang feeling here.
If you want COM support you better work with more microsoft-friendly language
The same
The same, but erlang has ODBC interface that allows you to work with 'ordinary' SQL-servers. I know it can mysql, not sure for mssql
Anyway you should think about some helping applications like 'print_pdf.exe', 'change_word.exe' that would be managed by erlang system, but not one erlang application which doing everything. Please read about C Nodes and Erlang FAQ's question "What sort of applications is Erlang particularly suitable for?"
-- sorry my English )
Related
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.
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.
I think Erlang is very well suited for server systems developed in my workplace (currently developed in Java). I am a bit skeptical how this would be accepted both by developers (who have no idea about functional or Erlang) and by managers.
Any ideas on how to approach the issue? I am thinking about some hybrid system, where the hardcore highly reliable infra uses Elrang, and app specific stuff developed in Java (as nodes?)
There are a few approaches, and neither have any guarantees to actually work
Implement something substantial in a short time frame, perhaps using your own time. Don't tell anyone until you have something to display that works. Unless you have a colleague in on it.
Pull up lots of Erlang projects that are good demonstrations of the features you want. Present it to your managers and try to frame them about the risk in keeping using Java with this kind of technology available.
If the company you work for actually have a working code base in Java already, they're not likely to take you seriously when you suggest to rewrite it in another language.
The true test that you believe in Erlang being a much better choice: Quit and start up a competing company and bring the technology insight you have in your current industry. Your managers are really comparing a similar risk-scenario as you would do if you were to quit your job, and they are looking for the same assuring facts for success as you would do, to consider leaving a "safe" paycheck.
As for how to integrate, check out the jinterface application in Erlang. It allows Java code to send messages to Erlang nodes, and it allows Java to expose mailboxes to the Erlang nodes as if there were Erlang processes.
It's all about ROI (Return On Investment) to a manager: a manager will be concerned about performance (of the company). In order to appeal to his business nature, you'll have to make a case for it using dollar$ (or whatever appropriate currency).
Beware that undertaking a "skunkwork" project on the side to "prove" your solution based on Erlang might backfire: "so you had time to play with Erlang, why didn't you spend the time on the project then?" (Of course, not all managers/companies would think this way).
You have to take into account the whole proposal e.g. impact on the team, skills to be developed etc. It's all about money.
If I have an advice for you: start small, plant a seed, nurture it and watch it grow.
A wise man once said to me:
"It's not about technology, it's about
the product & market".
Start by not targetting a rewrite but using erlang for a new feature/project. Rewrites can be expensive and taking a chance on erlang for something that is already a time consuming and costly undertaking is a hard sell. But if there is a new piece that could be done in erlang and java, you stand a better chance. The project will be small enough hopefully that you can discover early if erlang is a good fit and adapt accordingly. And when erlang proves itself in that project you will have better data to make your case with.
We're introducing RabbitMQ into our infrastructure, which currently runs a combination of C++, Java and Python applications. I'm not specifically intending to move the team towards Erlang, but if I were, introducing a well-written third-party tool that just happens to use Erlang is a very good way to get the foot in the door.
One major caveat is that while Erlang is a wonderful language to learn, the surrounding technology (OTP in particular) has a huge learning curve and is extremely primitive in many ways (debugging, IDE's, etc.). It is getting better all the time, but reluctant converts will crucify you if you don't warn them about the pain of learning to program in a radically different environment. Even simple things like the lack of code-sense technology (E.g., type 'foo.' and the IDE tells you what methods you can call on foo) can leave a really bad taste in the mouth.
I want to develop an application that can retrieve information such as, DLL version, DLL build mode(debug or release), info. regarding OS, memory, processer, processes/threads, program version etc. I am developing this mainly for Windows, but it'd be good if the application supports Linux too(wherever applicable).
I am basically a java programmer, and I know C, C++ to some extent.
Which programming language should I go for, that'd make my job easy? i.e. which language has APIs to fetch these kind of information?
Well... APIs are available regardless of the language... But the easiest way to get at what you are trying to do is going to be a C or C++ app. That doesn't mean it'll be easy (getting a DLL version is easy, getting memory and processor type is easy. The other stuff is certainly possible, but you may have to roll up your sleeves and learn the win32 API).
You might want to take a look at an application that already does exactly what you are asking about (Process Explorer) before you try to develop this yourself... It's going to be a big undertaking - and the folks at Sys Internals are really, really good at this stuff, and have already done it.
You commented on Kevin Day's answer that you would prefer to use Java for this.
Java is not very well suited for this, because the information you want to get is very platform-specific, and since Java is designed to be platform-independent, there are not a lot of ways to get at this kind of information from Java.
There are some methods in classes java.lang.System and java.lang.Runtime to get information about the platform that your Java program is running on. For example, class Runtime has a method availableProcessors() that tells you how many processors are available to the Java virtual machine. Note that this is not the same as the number of processors (or cores) that exist in the computer; the documentation even says that the number may change while the program is running.
Lookup the documentation for java.lang.System and java.lang.Runtime for more information.
Most likely you're not going to get exactly the information that you need by using pure Java - C or C++ will be better suited to get this kind of platform-specific information. If you would need this information from a Java program, you could write a small DLL or shared library and use JNI to call into it from your Java program.
Since DLLs are mentioned I presume we are talking about Windows.
I would recommend using WMI queries. They look very much like SQL and give you access to many very useful classes.
e.g. all info about the OS can be found here - in W32_OperatingSystem:
http://msdn.microsoft.com/en-us/library/aa394239(VS.85).aspx
You can use WMI classes from any language including C++.
As a side note - if you start a new application from scratch consider using PowerShell - new scripting language from Microsoft.
I am considering Erlang as a potential for my upcoming project. I need a "Highly scalable, highly reliable" (duh, what project doesn't?) web server to accept HTTP requests, but not really serve up HTML. We have thousands of distributed clients (other systems, not users) that will be submitting binary data to central cluster of servers for offline processing. Responses would be very short, success, fail, error code, minimal data. We want to use HTTP since it is our best chance of traversing firewalls.
Given this limited information about the project, can you provide any weaknesses that might pop up using a technology like Erlang? For instance, I understand Erlang's text processing capabilities might leave something to be desired.
You comments are appreciated.
Thanks.
This sounds like a perfect candidate for a language like Erlang. The scaling properties of the language are very good, but if you're worried about the data processing abilities, you shouldn't be. It's a very powerful language, with many libraries available for developers. It's an old language, and it's been heavily used/tested in the past, so everything you want to do has probably already been done to some degree.
Make sure you use erlang version R11B5 or newer! Earlier versions of erlang did not provide the ability to timeout tcp sends. This results in stalled or malicious clients being able to execute a DoS attack on your application by refusing to recv data you send them, thus locking up the sending process.
See issue OTP-6684 from R11B5's release notes.
With Erlang the scalability and reliability is there but from your project definition you don't outline what type of text processing you will need.
I think Erlang's main limitation might be finding experienced developers in your area. Do some research on the availability of Erlang architects and coders.
If you are going to teach yourself or have your developers learn it on the job keep in mind that it is a very different way of coding and that while the core documentation is good a lot of people do wish there were more examples. Of course the very active community easily makes up for that.
I understand Erlang's text processing
capabilities might leave something to
be desired.
The starling project already provides basic unicode support and there is a EEP (Erlang Enhancement Proposal) currently in draft, but going in to bring it into the mainstream of Erlang/OTP support.
I encountered some problems with Redis read performance from Erlang. Here is my question. I tend to think the reason is Erlang-written module, which has troubles while processing tons of strings during communication with Redis.