I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim.
If the goal is to learn GTK, Rust, and C, then it's not a big deal. If the goal is to build something that you need, you end up scratching it and going back to something you know already.
(In my case? Java which has the underrated JavaFX 2.0. And I'm sure I'll look elsewhere some other time - I'd really like to learn Rust better, but I think I'll do something other than a desktop app, or at least wait for better documentation or more time.)
That said, Lazarus looks really cool as well and may be the thing I always hoped for...
Of course, Lazarus/FPC is still quite nice. But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
Thus, don't hope too eagerly...
This is true but in practice the Carbon backend will work fine and if that isn't good enough you can use the Qt backend which uses Cocoa (but then you'd have to bundle Qt with your app which increases its distribution size a bit). To preempt a "then why not just use Qt" reaction, this isn't the same as using Qt since you can use the Win32 and Gtk backends in the other platforms.
Cocoa is of course under heavy development, but keep in mind that there are only a handful of Lazarus developers that even have access to a Mac and they actually had to write a special dialect for the compiler (Objective Pascal) to be able to handle Cocoa objects directly without the need of an intermediate (like Qt that needs libqt4pas that exposes the Qt API as a C interface that is then linked dynamically with FPC through a C-to-Pascal binding).
> Development is not on Github.
This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
> Syntax has no common style.
What do you mean? The IDE even provides formatting tools.
> Documentation is uneven.
Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
> The whole ecosystem feels (well, is) dated.
Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
> But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
>> Development is not on Github. >This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
(Most important is, what the fpc/lazarus developers want). -- Many people likely don't want to bother/install the 'ugly and stupid' SVN nowadays and Lazarus/FPC looses all those potential contributors at once. I don't like monocultures either but GitHub (maybe Gitlab) is the pragmatic choice and imho helps to have/find contributors.
>> Syntax has no common style. >What do you mean? The IDE even provides formatting tools.
Comparing Lazarus, FPC, MSEgui and some component sets, I had the impression that there are many (small) differences, e.g. 'integer', 'Integer', 'INTEGER', where begin..ends are placed and many more 'non-conventions'...
Tool is good, but (imho) the issue is that there is no BDFL which would gently nudge towards a commonly agreed style guide. Likely not helpful is also that Pascal is not case-sensitive and that there are multiple modes (OBJFPC, DELPHI, FPC..)?
>> Documentation is uneven. >Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
I don't want to complain. Core FPC docu is high-quality, written in Tex. But I found it difficult to get an overview: which are the relevant pdf's/links, where is the source for it, how would I contribute or report an error? For a quick shallow fix, it seems too complicated: Tex, xml; inline help, huge separate svn docu project; FPDoc generator. Contrast this to many environments where you can quickly fix a typo or phrase in the browser and the project gets a PR.
>> The whole ecosystem feels (well, is) dated. >Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
Difficult to be specific. If you e.g. look at go (golang.org/), rust (www.rust-lang.org), julia (julialang.org) and/or haskell (haskell.org) and some of their tool-choices, it feels for me very different than FPC/Lazarus. This is not mudling, it's just a realistic look at the situation. Dated also doesn't mean that it wouldn't work any more.
It is imho a problem if e.g. there is newpascal.com site with a more modern feel instead of the old trusted projects moving to a more modern approach. Don't know details but this choice raises the complexity for a user as it is not clear, what to choose.
>> But to really shine and be a valid alternative, it would need a large infusion of money and manpower. >Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
Do you have examples for such companies / situations? As the code is mostly GPL-2 (components LGPL2 with link-exception or MPL), it seems to be difficult for a company to take over. And personally I wish that there were steerings towards a more uniform and easier-to-enter 'FPC/Lazarus-world'.
>The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
Yes I hope things improve with new blood. For the 'Pascal universe' as a whole, lack of developers means 'not attractive enough'. As I really like the language I would blame the choice/proliferation of 'dated stuff' to be a contributing factor.
Last but not least, Lazarus worked well last November when I tried it out again. I was positively surprised. Nevertheless one has to have realistic hopes...
Not necessarily. D has dlangui and dwt, tcl (and also python?) has tk. Vala is also available for gtk. I think VB also lets you write GUIs although not sure I never used it. Objective-c has cocoa (gnustep outside of macosx).
