This was something like 500 Kb back in 2000, but it's still a far cry from your ~200 Mb Electron hello world.
Lazarus should have been the golden standard for creating desktop apps. Every other solution I've tried is subpar either in licensing or costs in general, executable size and resource usage, non native components, extra dependencies etc
It’s a pity that the C family of languages won out over Wirth’s languages. Pascal’s superior string handling alone would have saved us from countless security flaws.
I think that projects that ship packaged web apps but attempt to use the system native web views where available are really nice, like Wails: https://wails.io/ (so for example, on Windows it would use Webview2, so you don't have to package an entire Chromium install yourself)
Here's a comparison of how the distribution sizes change, Wails in particular also has way faster builds than something like Tauri: https://github.com/Elanis/web-to-desktop-framework-compariso...
That said, I wish we got more native software, or even something like LCL that can target Win32, GTK, Qt or whatever else is available. Sure, writing components that are available on a lot of platforms and work similarly everywhere is a pain for the developers, but I applaud the effort regardless, since the above solutions like Wails don't actually do anything for the memory usage and CPU cycles, whereas native GUI software is better for most apps that don't try to be very interactive.
I could even see myself using Lazarus/Pascal more if it seemed to have a more active ecosystem, right now I couldn't tell you what are the equivalents of something like Spring Boot for webapps, or even consuming Web APIs in client software, handling OAuth2/OIDC/JWT, seems like mORMot 2 would fit the bill the closest?
With respect to Lazarus, I agree that the ecosystem around it is not exactly great. It would be interesting to see LCL ported to something more modern that is reasonably simple, cross-platform and has good tooling. E.g. Go, much as I dislike it as a language, would probably be a great fit for something like that. And Pascal being fairly conservative and easy enough to parse, I suspect you could even automate this translation for the most part.
Forms (windows) are deserialized during loading, which relies on this mechanism.
Be aware that this is what you're getting into when you pick dotnet for GUI applications. It's been that way for decades at this point, there are many unfixed bugs in WPF for example, in spite of it being touted as the final word in GUI development in its time and still being used for some Microsoft applications like VS.
Meanwhile, with Delphi you were using VCL 20 years ago, and you're still using VCL today, and its development velocity and performance is light years ahead of anything Microsoft put out during that time. This also applies to Lazarus's LCL.
The funny thing about Windows GUI story is that the older the framework is, generally speaking, the better it is supported. WinForms still gets bug fixes and improvements; so does WPF. OTOH if you were early on the WinRT bandwagon, tough luck, and it's been meaningless churn ever since.
https://github.com/microsoft/microsoft-ui-xaml/issues
https://github.com/microsoft/WindowsAppSDK/issues
I could use C++ and stick with Qt, but I'd much prefer Rust. Rust has no good Qt bindings. What are my options?
The app makes use of QV/HBoxLayout, QWidget, Qdialog, QPushButton, and other really standard features. It reads from the filesystem, reads and writes to SQLite, and outputs sound from mostly ogg files at various speeds (through VLC behind the scenes). I stick with Qt because I like how it integrates with KDE and other desktops flawlessly.
> I stick with Qt
These come up on search results if you combine Qt plus the language.
Go:
* https://github.com/mappu/miqt
Java:
* https://github.com/OmixVisualization/qtjambi
Nim:
* https://github.com/jerous86/nimqt
* https://github.com/seaqt/nim-seaqt
Zig:
Same for the other languages - they likely won't have the performance of C++ or Rust. But I'll test them anyway, even just for the academic exercise the endeavour is worthwhile. Thank you.
That said, given your original request, I don't think it has much to do with language choice. Displaying a very large number of rows in a data grid or similar is a classic GUI task in line-of-business apps, and the answer has always been either virtualization (lazy loading) or pagination.
One trick to improve UX when virtualizing data is to do preloading asynchronously in the background - ideally on a separate thread - and start it before the user scrolls all the way to the end (e.g. when there's still a couple of pages of data left).
One thing that I would like to discover is how to adjust the scroll bar size so that it appears as if more records are loaded than actually are.
I think it's been out of date for a long time with modern computers having much more RAM and speedy SSDs (and also JVM optimizations). For actual run time performance once its loaded the JVM has had great performance in the early 00s already and improved since. And for server side it was never an issue as you don't restart the server very often (so the JVM is always already loaded).
Also did you test similar functionality in C++, I haven’t compared many implementations but I app I use that has an SQlite db being read with Qt(C++) is pretty sluggish whenever you touch the DB.
Maybe store the values in a dict and only read/write from sqlite when needed. Dicts are very fast in python.
I've also tried implementing lazy loading and pagination, with a pseudo-infinite scroll technique based on SQL LIMIT pagination, but the resulting CPU and memory spikes are noticeable.
There are several Qt binding for rust, for example cxx-qt. I haven't tried myself but it looks maintained. Why is it not good?
Otherwise, the most promising equivalent to Qt in Rust would be Slint.
I'm not sure what you mean by avoiding copies. I'm rather stringent with memory, I don't have superfluous copies of data in memory. Or did you mean something else?
Thank you.
May be I am doing something wrong, but I had installed Android Studio, then Android emulator, SDK, etc., and before I could get a hello-world app to compile, some 30 GB were gone from my disk space.
If it comes to it, I do not personally mind using multiple tools and code for different target platforms, as much as (a) both the tools themselves and the binaries generated are lean, and (b) the development tooling itself is on a single platform just so that I do not need to maintain multiple hardware. (I currently use Windows, would likely need to move over).
Thanks.
The problem is that you need to have a huge Java runtime installed or use something like Jlink which still produces very large binaries for GUI apps.
I think wxWidgets is the Lazarus alternative that is the closest to what grandparent was asking for.
Is there something similar for Android as well?
Asking ChatGPT, it has made recommendations for Haxe most importantly, which claims to support a large number of platforms.
In particular, his tech e-mail announcement/newsletter was where I first learned of a small startup w/ the unlikely name of "Google".
But that was the static overhead of VCL core library and the benefits were considerable compared to writing raw WinAPI.
And unlike MSVC 16kB WinAPI executable you didn't have chance of sudden surprise "oh, but you need to update msvcrt.dll to run this" because Delphi (and Lazarus/FPC) default to statically linking the runtime
<input type="button" onclick="alert('hello world')" />
HTML and JS is compact. The browser is not. But often installed already, so my PWA is very small as a result, but behaves quite native.
(But if you mean, that Lazarus can do that easily with a GUI, that would still be cool. Can it?)
With Gtk, no, because it implements all widgets by itself rather than wrapping Win32, so it'll necessarily be larger. Also, statically linking it can be a pain (and AFAIK isn't even supported in Gtk 4 anymore).
Then there is .NET Native and Native AOT.
As far as Native AOT, last I checked it requires trimming which breaks WinForms (and WPF) according to the official docs.
I don't think this matters much, though. There's simply no practical reason to AOT-compile a WinForms app. Not when the framework is guaranteed to be there, and JIT compiler is plenty fast.
Qt backend should be able to do that, though (but then of course you need all those Qt DLLs).
[1]: https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-wi... [2]: https://github.com/ysc3839/win32-darkmode
And so it drives me crazy to see the state of their documentation. The wiki needs to be archived and replaced with a coherent documentation platform. It’s such a turn off. The whole website is a SWAG site frankly.
‘ SWAG sites
SWAG is an archive of tips and example programs for Turbo Pascal/Borland Pascal and early Delphi. Much of it is still applicable to today's Object Pascal - and much is obsolete...’
How can a language compete when a new user sees this?
Is this the wiki you somehow want to have removed? https://wiki.freepascal.org/
It seems perfectly fine, information-dense even which is even better. Seems a lot better than the typical one-long-landing-page-docs many languages have today. What exactly is the problem with the wiki that cannot be fixed and must be re-made from scratch?
It has good stuff, but I'd wager the "bad stuff" outweighs it by a large margin.
The problem is optics. Pretend I'm a brand new user and I want to build GUI applications. I've heard of a language called Freepascal and of an IDE called Lazarus. I think they're connected but I don't know how. And what's Delphi?
Where do I start?
? Welcome to the Free Pascal and Lazarus Wiki [2] https://wiki.lazarus.freepascal.org/
? Lazarus Documentation https://wiki.freepascal.org/Lazarus_Documentation
? Welcome to the Free Pascal and Lazarus Wiki [1] https://wiki.freepascal.org/
? https://www.lazarus-ide.org/
Most IDEs and languages have a Documentation link. Which link do I use to start with?
FreePascal has lazarus docs and Lazarus has FreePascal docs?
As a new user I can slog through 4 different links of schtuff, I guess. (Disappointment and frustration lie ahead; broken old buggy software that doesn't match the documentation. New User doesn't know that yet.) Maybe I'll just look for Youtube videos, but my enthusiasm is draining.
I'm used to this:
https://go.dev/doc/ Everything linked from go.dev/doc works today and it's coherent. Everything.
As other responses mention, the docs as a rule are out of date and confusing.
[1] btw redirects to [2] from search engines.
I talked about this in my article about the release:
> One criticism we've seen of the FreePascal project in general concerns its documentation, although there is quite a lot of it: eight FPC manuals, and lengthy Lazarus docs in multiple languages. There is a paid-for tutorial e-book available, too.
The criticism is that there is too much documentation available? And they're long, and dare even to be available in multiple languages?
* Many criticise the docs; * There _are_ docs, and a lot of them.
This is not an "A therefore B" proposition.
It is offering 2 points, not positing a connection:
"The docs are not very good." AND "Docs do exist, lots of them."
In other words: there are docs, lots and lots of docs, but they are not very good.
For instance, specifically, the indexing and cross-referencing is, I am told, poor.
Too much documentation, if badly organised, can be as bad as too little.
I was asking about why the documentation was bad, with one example. You could reply "No" but instead shared some word-salad?
You could have just replied "Someone told me the indexing and cross-referencing is poor, I agree/disagree with that because of X" so we could have a normal human conversation instead of you trying to lecture some random internet commentator on completely irrelevant logic. Just be human instead.
Also AI also seems to get above average results with pascal code generation IMHO.
This doesn't match my own experiences, I've tried a few times to ask about Pascal and the results have always been appallingly bad. From nonsensical syntax (sometimes mixing in C-style syntax), to made up unit and object names, I'm surprised if it can even manage a correct "hello, world".
By comparison, Python generation can be pretty decent (not that it can't run into the same issues, but it is less frequent). I always assume it's because Pascal's online presence is gravely reduced compared to other languages. It is still a fairly popular language, but I'd wager most Pascal written is not published online.
Gemini 2.5 was the last one I used for generating an interface to a really old OLE based SCADA system, the base code it generated required almost no re-work to read and write the interface.
Language is not a problem. Pascal is just C/C++ in another favor. LCL/VCL is a wonderful library, everything just works like what I am expecting.
The ALGOL committee rejected it, choosing a competing and much more complex language headed by Adriaan van Wijngaarden. This became ALGOL-68 -- and killed ALGOL.
Wirth took what was known as ALGOL-W and turned it into Pascal.
FWIW I wrote about this:
https://www.theregister.com/2024/01/04/niklaus_wirth_obituar...
https://www.theregister.com/2025/01/07/algol_68_comes_to_gcc...
Another offshoot of Algol-60 was CPL, intended to be more general-purpose and capable. But it was big and hard work to get it working.
So Martin Richards designed, a simpler intermediate version, BCPL. (He also built an OS in it, TRIPOS. This formed part of AmigaOS 1.x.)
BCPL was further stripped down to B, and then evolved into C.
I'm torn about which is clearer, that magic variable style or assigning to the function name as one does in VBScript. I guess the magic variable makes refactoring dirty fewer lines
I also have mixed feelings about golang's `func Doit() (result int, err error)` syntax. To quote another platform, "there should be one, and preferably only one, obvious way to do it"
type PInteger = ^Integer;
var X: Integer;
function Foo: PInteger;
begin
Foo := @X;
Foo^ := 123;
end;
That's also "old style" Pascal, and still supported by Free Pascal (even though the compiler gives you a warning for doing it!).
Isn't it basically equivalent to an anonymous tuple which is automatically deconstructed on assignment?
I'm sure this solved some Google-y problem but for my tastes it is just needlessly confusing since I have never met a programmer who needed help creating local variables and that's got to be infinitely true now that AI gonna take all our jobs
> Isn't it basically equivalent to an anonymous tuple which is automatically deconstructed on assignment?
Your comment brought up an interesting point: a certain audience may also think those names appear in the caller's scope because they're part of the function's published signature but are an implementation detail
func Doit() (result int, err error) {
return 123, nil
}
func main() {
// a, b := Doit()
// fmt.Printf("In reality %d %+v\n", a, b)
Doit()
fmt.Printf("Uh-huh %d %+v\n", result, err)
}
./fred.go:13:32: undefined: result
./fred.go:13:40: undefined: err
func Doit() (result int, err error) {
result = 123
return 456, nil
}Lazarus and FPC is a great project. Building GUI apps like with Lazarus does not have an easy alternative, from which I'm aware.
I have tried it now on my Mac, and I have to jump through some hoops to get it going. Again a pity, its a great option.
>Lazarus is a Delphi compatible cross-platform IDE for Rapid Application Development. It has variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces.
now you have referred to something I do not know about. Was it on HN or where?
If you generate AI slop web dev code (and the chances are incredibly high if you haven't heard of Lisp or Delphi) you probably won't need Lazarus or care that native apps even exist.
I'm all for teaching and explaining, and I know a small percentage of new CS people are curious and interested, but... release notes aren't the place for helping them.
That said, an explanation of what Lazarus is is genuinely needed, because people who have written Delphi for years might not have heard it (thanks, Embarcadero). So your have a point beyond your main point there.
I can understand not wanting to explain Delphi, but come on, not everyone knows the name of every IDE for every language. It doesn't hurt to add one sentence explaining that. If I hadn't seen the comment above, I wouldn't be able to consider Lazarus in the future if I ever use Delphi again.
Fewer people will know the project in the context it's meant to be used. That seems strictly negative. What's the positive?
If one goes to the release notes for Lazarus, they either sought those release notes out, and hence already know what it is. Or they were linked to it in a specific context, such as Hacker News, which the expectation of curiously clicking around to understand the project is natural.
It doesn't mean that I will actively try and navigate out of a forum completely separated [1] from the actual product site just to see what it is.
[1] It's the bane of nearly all projects, both commercial and open-source: blogs, release notes, discussions, forums and often even documentation don't have a single link back to the product page
No.
Everyone thinks their pet project is obvious and self-explanatory.
This is NEVER EVER a safe assumption. Remember that our entire industry is a mysterious black box to the outside world.
I worked for A Prominent North American Linux Vendor for a while. I was hired to work on the docs for one of their projects.
I'm an industry veteran with at that time over 25 years of broad cross-platform tech experience from CP/M to Linux to mainframes.
It took me a month of hard digging to get an extremely vague overall concept of what the product was and did.
Most of the company had no idea -- it's not Linux-related in any way -- and many of them regard the entire product platform as an evil to be expunged.
This is typical for that vendor. Aside from their Linux distro, ask for a tweet-length summary of any of their portfolio, expressed in general terms not specific to that product or vague marketing-ware, and nobody in the company can give it.
Nonetheless they are a multi-billion-dollar vendor.
But they only sell into established markets.
Why would they explain that to their audience? They know.
They made an internal forum announcement. It's trivial to find out what that is. If you lack context, blame the place that cited this resource without it. So HN and OP.
I guess I'll wait for the next minor.
Also, is there no binary installer for macOS on the Lazarus site? Just asking. Don't know if there is one.
When arm64 came out, I couldn't even get an arm64 build for my Mac, but fpcupdeluxe just handled it.
I do it with C, using opaque pointers for C objects. Painless because everything is statically compiled in.
If you want a more dynamic solution (i.e. Python), you'll need to find a way to link every component in (or at least the ones your Python would use).
I use Lua from Delphi and vice versa regularly
Besides Qt, does it have a pure Win API back-end as well?