Objective comparison between FreePascal/Lazarus and Delphi

[Murmandamus]

I apologize in advance if there is already one or more threads on this subject; feel free to point them out and close this one if so.

After the discussion on the Delphi Starter Edition news post and previous postings from Will and others expressing misgivings about FP/L and its stability compared to Delphi, it has caused me to think about potential "gotchas" in using FP/L for serious large-project development, both in general, and for game development specifically. I'm currently tooling up to start some major projects and am strongly considering going FP/L for them. I have done a bit of research into the features and shortcomings of FP/L, including using several versions and building several projects with them to see for myself firsthand.

That said, there seems to be a significant amount of antipathy towards the FP/L projects in terms of maturity and stability, but a dearth of documented "boots on the ground" substance to those misgivings. I'd like to know what other people's knowledge and experiences are with both products from a comparative viewpoint.

I want to state up-front that I DO NOT WANT to instigate a tool "holy war". Everyone believes the tools they chose are the best for their needs, and I don't want to argue over that or anything else. What I want is simply a side-by-side comparison of features and deficiencies that you think are important and why. What are they missing? What sorts of stability issues have you encountered? What features are missing from either one?

In other words, what important issues should someone who is mulling over the choice to build serious production projects in one or the other consider in his decision?

I think this type of discussion could yield some valuable information, not only for old codgers like me, but for new people looking to get started with development in Object Pascal. I also would LOVE to have a "gotchas" list to keep in mind when using either tool, so I don't beat my head against a brick wall as much trying to find out whether I've fallen down some rabbit hole, or if I just need to keep looking for my own PICNIC errors.

[Andru]

side-by-side comparison of features and deficiencies that you think are important and why
Delphi doesn't support yet: 64-bit and ARM architectures, Linux, MacOS X, "native" iOS support(only via MonoTouch) and Android. This list can be continued, but other platforms not so important.
Stable version of FreePascal has some problems with 64-bit ABI(one problem which I got was fixed in FreePascal 2.5.1).
Sometimes Delphi generates faster code than FreePascal does, but this is not critical.
FreePascal can be used with object files from GCC compiler and this feature is useful for me(static compilation with native libjpeg(in future I want to use libjpeg-turbo with MMX/SSE optimizations) and zlib for faster decoding jpeg and png, also I can use static compilation with Chipmunk and libogg). Delphi can be used only with object files from Borland C++, but I didn't get success to build and use something else than zlib...

[WILL]

Well I won't get into the obvious different between commercial (dedicated team who's careers it is to work on it) and open source (various people who work on it in their spare time) the effects of that speak for themselves so that's off the table from a technical stand-point.

My main issue with Lazarus is the Mac OS X port. I love it on Windows, it does a decent job, but on the Mac it fails miserably in the stability department. Windows it's better, but there are still issues. I'll try to list them as I know them.

Mac OS X Issues:

GDB debugger seems to crash all the time on my system (less than a year old iMac with the latest version of Snow Leopard) and other than blindly compiling/building I cannot debug my source with it. I've tried fixing it, but nothing seems to do the trick. This is a problem for the last stable release and even some of the more recent SVN versions too.

There is a thread about another develop having the same issue, but when he stores his source on an NTFS drive. You'd have to go to the Lazarus forums to get more details on that. It did however seem similar to the issues I was having. Forum Thread (http://www.lazarus.freepascal.org/index.php/topic,11636.0.html)

Beyond that, obviously because Lazarus uses GDB for debugging, instead of a much clearer debugger error message you sometimes get SIGSEV errors that merely tell you that you screwed up with memory management. This is common among all platforms. I remember Delphi's own in-suite debugger was a bit more helpful in this matter.

There is a project for a Lazarus/FPC specifically designed debugger, but it's still a long way away from being as nice as Delphi's or even GBD in a way.

Cross-platform Advantage:

Delphi doesn't yet have it, but sometime this year we'll be receiving a 64-bit Windows and a Mac OS X edition. Still this doesn't give us support for iOS yet. You can use Delphi Prism with Mono and such libraries as MonoTouch and XNATouch, it has been done (http://www.pascalgamedevelopment.com/content.php?157-Get-Perplxt-on-your-iPhone-or-iPad), but there will never be as nice as a more closer to 'native' solution.

FPC on the other hand is iOS capable and will allow you to make iOS Apps through Xcode. I don't think this can be done with Lazarus just yet.

[Andru]

Mac OS X Issues:
Seems I need real Mac, because as always debugging under MacOS X 10.6.6(previously I have had 10.6.3 when you made your first topic about lazarus and MacOS X) in VirtualBox just works for me...

[Murmandamus]

Good stuff. Keep it coming. :)

[WILL]

Seems I need real Mac, because as always debugging under MacOS X 10.6.6(previously I have had 10.6.3 when you made your first topic about lazarus and MacOS X) in VirtualBox just works for me...
When I run Lazarus in my virtual Windows XP using Parallels, it seems to work ok. With the exception that all my projects will crash just as they are being closed. Happens to them all and it had never done it before when I was running Lazarus on a PC with Windows XP. I don't confess to completely understand it. I only know that there are some major issues with GBD under Lazarus on Mac OS X.

[JSoftware]

FreePascal is made by developers. Not designers who care about end user experiences, like Delphi most likely is. Lazarus especially is rapidly changing in both form and configuration. Now, I haven't used Delphi since Turbo Delphi, which was okay, but limited, so I don't know how objective this post is :) (I always rebuild fpc/lazarus every 3 days or so)

You'll always have trouble setting FPC/Lazarus up on a unix system, if you haven't used the lower level configuration interfaces for at least a decade(Mac...). I still haven't figured out how even Linux folks can tolerate all the access restrictions and the amount of different directories. :)

Delphi is straight forward. You get what you think you get, which is a Win32 compiler with a graphical IDE. It works

Lazarus is straight forward when you have it running. You get what you've configured it, and all the other tools for, whether it's Win32, win64, linux, amiga, etc. If you accidentally have other tools in the path, or hidden in user folders somewhere it might act different from what you thought it would do. But at least you'll be able to change this :) You'll have to rebuild it to install components which might seem scary, but it's (almost) perfectly safe, and even beneficial in many cases

I mostly work in embedded systems those days(ARM, AVR32, etc), so I have no need for Delphi at all, so I'm of course biased ;)

[vgo]

Not sure about the objectiveness, but anyway...

- Documentation is even worse than in current Delphi version (Delphi 7 had the best documentation by far)
- No cnWizards or any other IDE plugins (I can't live without cnWizards!)
- Very limited number of components, many 3rd party components are for Delphi only
+ Cross-compiling that actually works (Using CodeTyphon)

[chronozphere]

At this point, I still use Delphi alot for my projects because it just feels comfortable. :) Allthough FPC/Laz have a great featureset, delphi is very stable and does it's job well. I would love to start using FPC/Laz for all my code, but there are a couple of things getting in my way.

> I've found that the delphi debugger works great in 95% of the cases, but GDB let me down way more often. It often gives me errors like: Symbol not found in context or similar. I just tried to debug an application, but it didn't work AT ALL. It just seemed to hang in debug mode after I hit F9... Ctrl+F2 doesn't help, and after some time the application will be shut down automatically (Do note that I am using an automatic build of a few days back). Also, each time I start my application (with certain linker options) i get a SIGSEGV error from the debugger, which is really annoying when you want to test your software quickly. I want to feel comfortable with these things, but I always end up getting annoyed by these issues.
> In delphi, I love to CTRL-click somewhere to jump to the definition. I really miss that in Lazarus.
> On ubuntu, it is not possible to restore the entire IDE with one action. I have to maximize every single IDE window separately, which slows me down quite a lot.
> And a nitpick: The delphi compiler seems quite a bit quicker than FPC. Not a big issue for me though, but it belongs in the list.

I want to start using FPC for the following reasons:

> Cross platform and 64bit support. ofcourse!
> I like how lightweight it is compared to Delphi, yet offering a lot of tools and components.
> I like the FPC pascal dialect (for example the +=, -= operators) and the fact that it's a bit more strict than the delphi syntax here and there.
> And it's opensource!! Would like to contribute someday, when I have a good idea for an extra feature.

I'd love to use FPC/Laz more often, when they are more stable and have a good debugger. That's their main problem now, so I believe. Now, I still use delphi mostly, but I try to keep my code FPC compatible.

Just my $0.02. ;)

[User137]

> I've found that the delphi debugger works great in 95% of the cases, but GDB let me down way more often. It often gives me errors like: Symbol not found in context or similar. I just tried to debug an application, but it didn't work AT ALL. It just seemed to hang in debug mode after I hit F9... Ctrl+F2 doesn't help, and after some time the application will be shut down automatically (Do note that I am using an automatic build of a few days back). Also, each time I start my application (with certain linker options) i get a SIGSEGV error from the debugger, which is really annoying when you want to test your software quickly. I want to feel comfortable with these things, but I always end up getting annoyed by these issues.
Sometimes this hints for lack of debug information in the project settings. There are alot of options for compiler options, and you also need to take out all code optimizations for smoother debugging. Also if the SIGSEGV is caused by a DLL like OpenGL or DirectX even Delphi can't trace what the problem is.


> In delphi, I love to CTRL-click somewhere to jump to the definition. I really miss that in Lazarus.
> On ubuntu, it is not possible to restore the entire IDE with one action. I have to maximize every single IDE window separately, which slows me down quite a lot.
> And a nitpick: The delphi compiler seems quite a bit quicker than FPC. Not a big issue for me though, but it belongs in the list.
In Lazarus you can Ctrl-click to jump to definition. And also Ctrl+Shift+Down to jump to implementation. All keys and controls are configurable.
I have not noticed any speed issues so far. Apps start really fast, on Windows 7 at least. I read some compiler options increased the speed greatly for Linux aswell, smart linking be 1 of them?

I don't even consider using Delphi anymore, though i have old Delphi 7 still installed. FPC/Lazarus is free which is the main thing. And as far as actual coding with the IDE go, i'm starting to like Lazarus alot. Have also managed to get 1 or 2 past issues fixed with the bug ticket system :)

[wodzu]

Hello.

I am not biased towards Delphi or FPC\L, if I am biased towards anything it is Pascal language in general ;-)

What I do like in FPC\Lazarus compared to Delphi:

IDE is faster and does not need the .NET crap!!
Crossplatform possibilities - does it require any comments?;) FPC + OpenGL + SDL is way to go!!!
If you discover a bug and report it, you will get a response (response not fix) in a matter of day or even hours. I've reported two bugs so far, and one has been solved in one day and the other in one week. I think it is very fast compared to Delphi in which some bug exists for years.

What I miss in FPC\Lazarus

The ability to see a mistake in your code in the time you made it. Delphi underlines erroneus code with red "line". (Altought this feature is sometimes buggy atleast in Delphi 2007)
The native debbuger. Delphi debugger is way better, and I doubt that the debugger for FPC will be ever released. However, I fully understand how complicated thing is to write one for crossplatform language. So it is on my big whish list but I accept the reality ;-)

[wagenheimer]

+1 to FPC/Lazarus Support! It is very good!

I posted some questions and I had reply in a matter of hours!

[WILL]

+1 to FPC/Lazarus Support! It is very good!

I posted some questions and I had reply in a matter of hours!

This doesn't always happen. I posted a suggestion/comment about a problem in documentation and I got told to go fix it myself. No additional information on where to look for the correct information or how elaboration on my problem. I was also being accused of being lazy. :)

[Murmandamus]

Just wanted to let you all know that I am compiling and collating these (and some of my own) into a list which I am planning to edit into my original post. I would like to expand into some details as well, but I'll get to that shortly.

The main goal is a "quick reference" with details that can be amended as time goes on (as well as helping me decide on tools; I like to turn my research efforts into something more broadly usable by others; I might as well, the work is being done anyway :D ).

[Murmandamus]

This doesn't always happen. I posted a suggestion/comment about a problem in documentation and I got told to go fix it myself. No additional information on where to look for the correct information or how elaboration on my problem. I was also being accused of being lazy. :)

That, sadly, is all-too-common in a lot of FOSS projects. Documentation is always the red-headed stepchild, and those who point out deficiencies in such a critical resource all too often get treated similarly.

There is simply no need for that kind of treatment, IMHO. All it takes is a little bit of effort to put in a bit of documentation infrastructure, say a basic wiki or outlining system, and gentle / courteous encouragements as well as enthusiastically answering queries by people who are doing the documentation effort.

[WILL]

Just wanted to let you all know that I am compiling and collating these (and some of my own) into a list which I am planning to edit into my original post. I would like to expand into some details as well, but I'll get to that shortly.

The main goal is a "quick reference" with details that can be amended as time goes on (as well as helping me decide on tools; I like to turn my research efforts into something more broadly usable by others; I might as well, the work is being done anyway :D ).

If you would like to article-ize it and put it into the next issue of Pascal Gamer I'd be happy to publish it. As long as it doesn't bash any one party or speculate too much. ;)

Re: Documentation-Debacle....

Yeah I was pretty disappointed. I think it might have been one of the core team members too. There was another of the core members (I believe Vincent, who I have a great deal of respect for) who did offer some information that explained some of the issues, but I really never got any information that would have helped in my hope to update the documentation to add what I felt was missing. It seems the core development team is pretty de-centralized and not really united in a common goal for the software. At least not that I've seen. The Laz team could use more structuring I think.

[JSoftware]

The Laz team could use more structuring I think.

I think what it needs is more contributors

[arthurprs]

Debuger is miles away.

[WILL]

I think what it needs is more contributors
That kind of falls into the 'too many cooks spoil the soup' scenario. More coders doesn't make a better project nessissarily. Yes the project could benefit from more people to tackle the LCL problem (huge workload, not enough coders to do it all), but there are other problems that plague the project that have nothing to do with the amount of coders contributing to it.

The biggest issue is that the original project leader seemingly bailed and others have been juggling the project as best they can. Kudos to them, but I've not seen much of an organizational structure published on the Lazarus site nor have I seen some kind of 'creative roadmap' other than a list of incomplete features yet to be completed. That doesn't mean that there isn't an organized core team, but publicly there isn't much of a presence which doesn't help to invite those seeking help or wanting to contribute. Mantis alone doesn't make a very good PR campaign to bring in more coders unfortunately. ;)

It's not an easy project to run and manage. It has huge goals (some we've seen completed mostly!) and requires a lot of man-power to complete them. Hell I have a hard enough time trying to get help on this site, so I understand. It's just realistically the project lacks in PR management. If they could solve that then a lot of things like documentation and public interest will sort themselves out in the course of time.

[Murmandamus]

If you would like to article-ize it and put it into the next issue of Pascal Gamer I'd be happy to publish it. As long as it doesn't bash any one party or speculate too much. ;)

I'm not interested in bashing anybody or speculating. Just the facts, and what they mean to me as a developer.


Yeah I was pretty disappointed. I think it might have been one of the core team members too. There was another of the core members (I believe Vincent, who I have a great deal of respect for) who did offer some information that explained some of the issues, but I really never got any information that would have helped in my hope to update the documentation to add what I felt was missing. It seems the core development team is pretty de-centralized and not really united in a common goal for the software. At least not that I've seen. The Laz team could use more structuring I think.

I think my main issue with both FP/L projects is the AWFUL websites. It is hard to find anything, and there are multiple places where you find similar information, but one version hasn't been updated in years, and another is woefully incomplete. So, I think it comes as no surprise that the organization at higher levels in the project is lacking; it is reflected in the public face of the projects. If it were up to me, that is the first thing I would tackle. With a better, more accurate, more efficient public face, it might attract more people to the project.

[WILL]

I'm not interested in bashing anybody or speculating. Just the facts, and what they mean to me as a developer.
And I wouldn't accuse you of such. I was only making a half-joke. Your thread was a really good idea actually.

With regards to the GBD on Mac OS X debugger issue; I found this in the FAQ... http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Mac_OSX

[Murmandamus]

Oh, no, I didn't think you were. It is an important point. Like I said when I started the thread, I don't want to turn it into a "holy war", as it is easy to get distracted into going there; been there, done that, got the t-shirt.

The goal is to not only help us choose the tool that is right for our needs, but also see where the each tool is weak and in need of improvement. In my opinion, that is more pertinent for FP/L because it can be fed directly into the development process, whereas such improvements might lag a bit with Delphi because of the general nature of closed-source software development versus FOSS development. It still is good for both, though.

One example for both is the lack of a real macro preprocessor extension. While I really don't like C (and its dialects) as a language, there are some superlatives about it that I miss in Object Pascal; one of those is a decent macro preprocessor built into the compiler. FP does have an experimental one, but it is somewhat limited. Of course, some folks will say to just use m4 or some other macro preprocessor, but m4 is a bit heavy syntactically, and it doesn't have an "integrated" feel to it.

[LP]

FreePascal compiler itself is pretty powerful and is comparable to Delphi (with few quirks, see below). Lazarus has evolved quite a bit and has some nice features, but when compared to Delphi it still feels uncomfortable.

The main drawback of using FPC/Lazarus is the compilation time, which is considerably longer. If you have a very large project and need to correct/recompile very often (for instance when doing some precise 1-pixel adjustments in the rendered scene), it slows you down very much.

Although other people reported success with the debugger, I was never able to make it work reliably on any computer I've tried. In the best scenario it works only once and then you can't view any of the variables. In practical terms for me, working in FPC/Lazarus means working without the debugger (instead I use logging to an external text file for debugging).

The generated EXE files by FPC/Lazarus are quite larger when compared to Delphi, even after stripping everything down. However, Delphi XE also generates larger EXE files when compared to Delphi 2007 and earlier. In practical terms, this is not a problem, but still a little bit annoying.

Lazarus IDE still have some bugs that were not fixed, like the scrolling speed too slow with mouse scrolling wheel in some configurations.

Specifically to FPC: the compatibility/incompatibility with Delphi is quite weird. The most annoying thing is that if you declare property "HelloWorld", you can't use it as a parameter to function in the same class, unless you turn on Delphi compatibility. If you turn on Delphi compatibility, you loose FPC overloading capabilities.

There are other obscure weirdness with the namespaces where you try to access some global class/variable, which is declared in different files, and you include both in Interface and Implementation sections. In Delphi, this is straightforward, in FPC it is quite obscure and unpredictable.

[Murmandamus]

Hmmm.. I am beginning to formulate a future research topic idea..

Figuring out exactly what the "bloat" is in generated executables from both tools. I mean, I know that a lot of FP/Ls exe size is due to debugging info and not using the smart linker. One test form I tossed together (just an app with a single MDI form, a 30-item menu, and about 10 other controls, no actual functional code) generated a whopping 12MB EXE. Of course, I went in and twiddled with compiler/linker settings, and it went down to 1.8MB, but that's still a bit excessive for not a whole lot of code. As a result, I would conclude that either the code is not as "severable" as it should be, or the linker is not as smart as it could be.

Guess I need to whip out my file analyzer and see what's under the hood. ;)

[LP]

As a result, I would conclude that either the code is not as "severable" as it should be, or the linker is not as smart as it could be.

I think the component set included with Lazarus by default is what makes the EXE so large. In a way, it is similar to Delphi - if you create a simple console application without any GUI whatsoever, the size is very small. In any case this may serve as an advantage; for instance, some applications compiled with VC++ need the VS runtimes to be distributed and installed, while in this case you have a fully stand-alone application. The "bloat" also exists (to a lesser degree) in apps compiled with Delphi XE, so we'd better get used to it.

[Murmandamus]

Oh yeah, I was aware that Delphi has the same problem. It always has; they even used to include a command-line utility called "W8LOSS.EXE" that scanned the EXE and stripped out some unused stuff the "smart" linker apparently missed. Primarily, it is the VCL which causes the bloat because there is potential for dynamic creation of any components at runtime, so it goes ahead and links it in, just in case.

Also, of course, all resources are linked into the EXE file.. any static bitmaps in TImageLists, Icons, strings, etc. General GUI data bloat adds its 20 pounds of flab to the EXE as well.

The one nice thing about it is that it generally is a one-time charge bloat. IE, the file sizes start out larger than you would expect for the basics, but don't balloon out at the same rate. Like you were saying, it more or less includes the equivalent of MSVSCRxx.DLL as part of the EXE, making it easy to pass around the standalone EXEs.

[JSoftware]

That kind of falls into the 'too many cooks spoil the soup' scenario. More coders doesn't make a better project nessissarily. Yes the project could benefit from more people to tackle the LCL problem (huge workload, not enough coders to do it all), but there are other problems that plague the project that have nothing to do with the amount of coders contributing to it.
I don't agree. And as far as I understood noone called you lazy, or insinuated that. But I think that would be starting to stride from the objectivity topic of the topic at hand.

It's not incredible goals the project is trying to achieve. It just seems to me that some people put the wrong expectations on the program(lazarus). Working with GDB isn't exactly magic, but it varies alot from each platform apparently, so I don't know why it's only Martin and Marc working on it. There's a standard, but GDB implementors don't even follow it themselves. I think I'll try abstracting it in the future because I need remote debugging to debug AVR32's

"Good opensource software is created out of necessity; not necessarily altruism" - I think Marco Van Der Voort said something like that once :)

As far as I've understood it's the only same guy who's been working on the official documentation for the last 10 years. Without getting paid of course

"In opensource projects there aren't any lack of people telling others which direction to take; only lack of people willing to implement those changes" - Some other dude from one of the epic the Embacadero threads on Lazarus