> it's still a far cry from your ~200 Mb Electron hello world.
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)
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?
I remember some years ago that I was able to make this less than 1mb. It needed a little tweaking like upx but nothing very complex.
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
I think unfortunately what holds Lazarus back is the Pascal programming language. Although it is a very capable language that can hold its own against other languages, it suffers from a reputation of being obsolete.
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.
2.5 MB is for most of the Lazarus Component Library (LCL) with minimal size increases even as program complexity grows. For example, Dadroit JSON Viewer EXE is less than 6 MB while having complicated tree views, JSON handling, networking, and more.
By the way, an empty CLI EXE on Windows is less than 50KB.
I imagine it's for the same reason Delphi can't strip much, which is that it supports run-time reflection. You can create an instance of a class using a string of the name.
Forms (windows) are deserialized during loading, which relies on this mechanism.
Maybe you're the person to ask. My Python Qt app is sluggish when it loads tens of thousands of values from SQLite. Various variations of pagination and lazy loading hurt usability. But isolating the issue and testing with C++ and Rust show that those two languages don't have the performance hit of Python.
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.
Thank you. I don't see Java as having a performance edge over Python ))
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.
Java is about an order of magnitude faster than Python. It's a JIT-compiled statically typed language, after all, and Oracle's JIT compiler is the best in class.
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).
Java is actually pretty fast, and certainly much, much faster than python. There are plenty of reasons Java isn't my preferred language, but speed is not one of them.
The jokes were mostly about startup time for the JVM (only happens once as when its in RAM it stays there and the loading time doesn't repeat for the next java program you run). It was also a lot more notable in the 90s when java was a browser plugin to run applets and browsers were single threaded (so the browser froze for a few seconds while the JVM loaded).
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).
I'm not necessarily advocating java, I think rust is def the best solution in most cases -- but java definitely has a significant performance edge on python. The JVM will never be quite as fast as native code, but it's very fast these days and it gets better every year. Certainly much, much faster than python on the average.
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.
Yes, that's what I'm doing. It's the initial load that is heavy.
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.
Thanks. I forget why I discounted cxx-qt. It think it didn't support some common Q* object but I don't remember which. I'll experiment with it and with Slint, which I've been eyeballing anyway. Thank you.
Cython is a great idea, thank you. I'll definitely try that. The code is all properly typed anyway.
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?
More generally, which all tools that can target multiple platforms, produce relatively small binaries for simple applications? And which of these are lean themselves?
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).
That’s a lot. I don’t know the specifics of Lazarus, but this typically screams static linking with everything and the kitchen sink being thrown into this one binary. Entire cross-platform runtime, GUI assets, metadata, etc. Could be a fat debug build, too.
It was the common complaint about writing VCL apps in Delphi - that single message box app would be 0.5MB binary.
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
That's indeed a statically linked binary. Release, with smart linking (so only things that are actually used are linked; otherwise it'd be ~20 Mb), debug symbols stripped. Measuring .exe size when linking dynamically would kinda defeat the purpose of the experiment, since you'd still need to distribute the DLLs to the users for any real world app.
Best part for me that it's a single file executable. I chose to do a thing in Pascal last year just because of this one killer feature. I made some initial attempts to achieve this with something else but I didn't find any modern tool that could do that without some weird, sometimes involved, sometimes straight up experimental steps.
I think Go will do it, but I indeed enjoy Free Pascal for this as well. It's also nearly trivial to set up cross compilation using FPCUpDeluxe, so I've shipped applications to clients on Windows when I do all development and compiling on GNU/Linux.
.NET can create self-contained executables pretty easily (via _dotnet publish_), both including the required framework assemblies and without them. But they'll still be comparatively large.
Not necessarly, that is a possible option if you want to keep the JIT around, other one is to AOT compile, 100% straight machine code, like any other compiled language.
For JIT binaries it’s best to apply /p:PublishTrimmed=true which (sometimes massively) reduces their size. Applications written in AvaloniaUI or, nowadays, WinUI 3 can be compiled with NativeAOT which reduces the size and memory usage even further.
I was going to complain how Avalonia still has issues with large binaries even with NAOT but I just tested it on https://github.com/sourcegit-scm/sourcegit on Windows, and the resulting size of the folder without symbols (the binary and like 4 dlls) is ~55MiB. The binary itself is 41MiB which is as much as Qt6-based qBitorrent binary takes on Windows. So it seems while Avalonia works well enough on macOS, the size of binaries and memory consumption are higher than on Linux and Windows huh.
Fair enough, although I trust them more to sort out those issues, than to keep waiting for Project Reunion to deliver what was promised at BUILD 2020, or by C++/WinRT team at CppCon 2017 (which is WinUI 3.0 foundation).
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.
Wait what? AvaloniaUI is not WPF, neither is WinUI3 which is new and maybe something you'd consider if you only target Windows (I presume it's better than using it through Uno, otherwise you'd probably choose Avalonia to support all OSes).
With WinForms you can do much better, in large part because .NET itself ships with Windows and thus the app can just rely on it being there, but also because C# compiles to bytecode rather than native code (so it's not exactly a fair comparison). Anyway, the identical hello world GUI app in C#/WinForms is ~11 Kb.
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).
You couldn't redistribute NGen'd binaries tho, it was basically a local AOT'd cache.
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.
Win32 ones don't only new WinUI ones do (similar to GTK2 vs GTK3+). You need to add that coloring manually. You can query the dark mode with Win32-only API[1] but you need to make your own styles or you can use undocumented APIs (that can break anytime) that Microsoft uses internally for the applications shipped with Windows[2]
(GTK 2 does support dark themes, of course, it just doesn’t have a concept of “light/dark theme variants” natively. And come to think of it, it’s the same in Win32: see e.g. the Zune theme for Windows XP.)
I had a client habing trouble with and old vb6 software they where using in production. Replaced it with a lazarus app, and been running for 10 years now without problems.
Me too! I have a software in production for a client made with Lazarus 3 (in Pascal of course) and everybody loves the "Windows feel" of the Gui.
On Linux there is Gambas [1] wich is like Lazarus but for Basic.
ALGOL-60 was huge, in around 1960. Niklaus Wirth had a detailed proposal for the next version of ALGOL, to be called ALGOL-X.
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.
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?
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?
The wiki is full of incomplete, obsolete, or otherwise not-so-useful articles. It suffers from typical "wiki as documentation" efforts, where instead of concentrated efforts from domain experts, you get a thousand half-baked opinions.
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?
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.
The only relevant part I can find from that article is:
> 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?
I'm incorrectly asking questions? You sound like a great author.
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.
I stopped using the Lazarus documentation a year ago when the AI prompts (which seem to be trained on the actual documentation) became easier and faster to use.
Also AI also seems to get above average results with pascal code generation IMHO.
I only toyed with Lazarus/Free Pascal. There was some things I couldn't get used to. Maybe time to toy around again :) I feel like mentioning a few things that helped in the past: fpcdeluxe for installing a build of fpc and lazarus and a plugin called anchordockingdsgn to get all the floating windows in one window. It would be nice if 4.0 defaulted to that. The Castle Engine Pascal tutorial was actually pretty good also (which is mentioned in another thread here.) (edit: for the plugin, I see an option in fpcdeluxe to dock all windows - so it's possible to build that plugin in initially.)
fpcupdeluxe is great if you want to get a particular revision or build cross-compiling.
If you need a stable version, just download the setup from. The docked IDE is the default option for this version.
That's one problem I haven't had. I've even run Lazarus on a Raspberry Pi Zero W, it was slow but it actually worked. I don't know what kind of hoops the Mac has, but on Windows or Linux it's easy peasy.
Nice to see this, and I jumped on it immediately since I really wanted to do a minimal form-based UI to a tool I'm building, but on macOS I keep getting linking errors when compiling (on a fresh install, on a machine that never had Lazarus before).
Ok, using WinAPI means it is not easily theme-able, unless they provide custom set of controls. I assume it is possible to use Qt back-end for Windows as well. I wish Lazarus also supported C++ akin to C++Builder. Pascal is a deal-breaker many.
This is one of the best introductions to what programming a computer is about that I know. I highly recommend checking it out, even if Pascal-like languages are not your cup of tea.
> To return a value from a function, assign something to the magic Result variable. You can read and set the Result freely, just like a local variable.
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"
I'll often use `result` as the return value in other languages, largely because I learned it in Delphi 25 years ago. It doesn't have the automatic return value semantics elsewhere, so you also need `return result` or whatever, but it's crystal clear what the intent is. I prefer it for that reason alone.
`Result` is clearer given that in Pascal, a function name by itself in any other context is a function invocation (with no arguments). That is, you then have this kind of stuff:
type PInteger = ^Integer;
var X: Integer;
function Foo: PInteger;
begin
Foo := @X;
Foo^ := 123;
end;
The first assignment here is assigning to the magic result variable, while the second one recursively invokes the function and dereferences the returned pointer to assign through it. This is technically not ambiguous (since you can never have a naked function call on the left side of the assignment, unlike say C++), but it's a subtle enough distinction for human readers. No such problem with `Result`, obviously, which is presumably why it was one of the things that Delphi added since day 1.
>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"
Isn't it basically equivalent to an anonymous tuple which is automatically deconstructed on assignment?
To the novice reader in golang, it was an unexpected "wait, where did these symbols come from?" because I wasn't used to being able to look after the function signature for variable names, and that's doubly true for symbol names that didn't come from caller data
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
I also just realized they're one of the places where golang doesn't emit a compile error for unused variables (as in the example above). Now I extra hate it
It would be great if release announcements like this always included a description of what the product actually is.
>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.
Because these things get shared elsewhere and end up getting looked at by someone who has no idea what the product is, like me, this time, with Lazarus.
You are overreacting. It takes one click - the logo on top left - to go back to main site which covers "what is lazarus?" clearly. Is that logic, that a main logo of the site goes back to home page, already lost?
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.
Since I read about the guy who was surprised that anything other than SPAs exist (the full page reload magic incident), I realized there are way younger people in the field with no context or knowledge of CS history whatsoever, so some of them not knowing about Lazarus or Delphi sounds totally plausible.
I think it's not elitist at all to say that people with no CS education (whether academic, self taught, or acquired over time) should probably not be considered when writing documentation or release notes.
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 know Delphi, yet I didn't know Lazarus until now. I'm sure there are others like me.
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.
Which is an excellent point for conversations, but in the context of the release notes in the website of the project, I understand that this xkcd principle does not apply.
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.
Sometimes I click on HN submissions out of idle curiosity, not because I seek those out, or because I know what the link refers to.
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
> Delphi and Lazarus have been around for decades. It's like asking what lisp is.
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.
HN submissions don't have a field for description. And you are supposed to use original title. And there is a length limit on title. And some angry internet user will make a comment - sometimes even the submitter.
I think you'd have a larger impact if you convinced other communities, like the Linux kernel or Xfce, that their "products" ought to have a note like that in their release announcements.
https://github.com/ying32/govcl is a binding of the Lazarus LCL GUI library to Go. It works pretty well, although I really got the impression that GTK2 and Win32 were the best supported targets, anything more modern was pretty buggy, so don't rely on it for hidpi support.
Best part: a hello, world GUI app (a dialog with a textbox and a button that pops up a message box) is ~2.5 Mb on Win32.
This was something like 500 Kb back in 2000, but it's still a far cry from your ~200 Mb Electron hello world.
> it's still a far cry from your ~200 Mb Electron hello world.
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?
I remember some years ago that I was able to make this less than 1mb. It needed a little tweaking like upx but nothing very complex.
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
I think unfortunately what holds Lazarus back is the Pascal programming language. Although it is a very capable language that can hold its own against other languages, it suffers from a reputation of being obsolete.
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.
And complex compiling. Pascal compilers are very fast.
Can someone recreate it in Go?
Go is basically Pascal with curly braces anyway. Wonder if a Pascal to Go transpiler could work here...
But if you don't target windows, but the web as target plattform, you will need just 53 bytes that will work, wherever a browser works.
<input type="button" onclick="alert('hello world')" />
2.5 MB is for most of the Lazarus Component Library (LCL) with minimal size increases even as program complexity grows. For example, Dadroit JSON Viewer EXE is less than 6 MB while having complicated tree views, JSON handling, networking, and more. By the way, an empty CLI EXE on Windows is less than 50KB.
Why doesn't the linker strip out unused code?
I imagine it's for the same reason Delphi can't strip much, which is that it supports run-time reflection. You can create an instance of a class using a string of the name.
Forms (windows) are deserialized during loading, which relies on this mechanism.
Maybe you're the person to ask. My Python Qt app is sluggish when it loads tens of thousands of values from SQLite. Various variations of pagination and lazy loading hurt usability. But isolating the issue and testing with C++ and Rust show that those two languages don't have the performance hit of Python.
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.
> What are my options?
> 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:
* https://github.com/rcalixte/libqt6zig
Thank you. I don't see Java as having a performance edge over Python ))
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.
Java is about an order of magnitude faster than Python. It's a JIT-compiled statically typed language, after all, and Oracle's JIT compiler is the best in class.
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).
Yes, that is exactly what I have been doing. Thank you.
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.
In Qt you should use the model/view framework if possible. It gives a virtualized list with a render callback. https://doc.qt.io/qtforpython-6/overviews/qtwidgets-model-vi...
Java is actually pretty fast, and certainly much, much faster than python. There are plenty of reasons Java isn't my preferred language, but speed is not one of them.
This is great to know, thank you. I still remember the days of the knock, knock jokes about Java.
The jokes were mostly about startup time for the JVM (only happens once as when its in RAM it stays there and the loading time doesn't repeat for the next java program you run). It was also a lot more notable in the 90s when java was a browser plugin to run applets and browsers were single threaded (so the browser froze for a few seconds while the JVM loaded).
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).
I'm not necessarily advocating java, I think rust is def the best solution in most cases -- but java definitely has a significant performance edge on python. The JVM will never be quite as fast as native code, but it's very fast these days and it gets better every year. Certainly much, much faster than python on the average.
Thank you, I will evaluate Java for this purpose, though I almost certainly won't actually use it in the rewrite.
https://areweguiyet.com/
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.
This website is useless if accessibility compatibility is not mentionned.
Yes, that's what I'm doing. It's the initial load that is heavy.
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.
> I could use C++ and stick with Qt, but I'd much prefer Rust. Rust has no good Qt bindings. What are my options?
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.
Thanks. I forget why I discounted cxx-qt. It think it didn't support some common Q* object but I don't remember which. I'll experiment with it and with Slint, which I've been eyeballing anyway. Thank you.
Is Cython and/or avoiding copies an option?
Cython is a great idea, thank you. I'll definitely try that. The code is all properly typed anyway.
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.
Sometimes Python code makes copies when we’re not expecting it to. Hard to know but performance optimization books/blogs discuss it.
I'll Google for that, thank you!
More generally, which all tools that can target multiple platforms, produce relatively small binaries for simple applications? And which of these are lean themselves?
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.
Java perhaps? That was one of the core promises of the Java ecosystem.
> produce relatively small binaries for simple applications
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.
https://wxwidgets.org/
Thanks.
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.
On Android, Java running on top of the Android Runtime is the native framework for apps.
That’s a lot. I don’t know the specifics of Lazarus, but this typically screams static linking with everything and the kitchen sink being thrown into this one binary. Entire cross-platform runtime, GUI assets, metadata, etc. Could be a fat debug build, too.
It was the common complaint about writing VCL apps in Delphi - that single message box app would be 0.5MB binary.
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
That's indeed a statically linked binary. Release, with smart linking (so only things that are actually used are linked; otherwise it'd be ~20 Mb), debug symbols stripped. Measuring .exe size when linking dynamically would kinda defeat the purpose of the experiment, since you'd still need to distribute the DLLs to the users for any real world app.
Not Pascal but here is something I wrote on the same lines in C++: https://latedev.wordpress.com/2011/10/06/simple-windows-dial...
Best part for me that it's a single file executable. I chose to do a thing in Pascal last year just because of this one killer feature. I made some initial attempts to achieve this with something else but I didn't find any modern tool that could do that without some weird, sometimes involved, sometimes straight up experimental steps.
I think Go will do it, but I indeed enjoy Free Pascal for this as well. It's also nearly trivial to set up cross compilation using FPCUpDeluxe, so I've shipped applications to clients on Windows when I do all development and compiling on GNU/Linux.
.NET can create self-contained executables pretty easily (via _dotnet publish_), both including the required framework assemblies and without them. But they'll still be comparatively large.
I couldn't find the right checkbox to click in VS.
Are those not just large zip files?
Not necessarly, that is a possible option if you want to keep the JIT around, other one is to AOT compile, 100% straight machine code, like any other compiled language.
Does it matter what format they use to pack the exe with data?
For JIT binaries it’s best to apply /p:PublishTrimmed=true which (sometimes massively) reduces their size. Applications written in AvaloniaUI or, nowadays, WinUI 3 can be compiled with NativeAOT which reduces the size and memory usage even further.
100% great advice, but really better go with Avalonia, Uno, WPF, Windows Forms, WinUI 3.0 only if one is a Microsoft employee.
https://github.com/microsoft/microsoft-ui-xaml/issues
https://github.com/microsoft/WindowsAppSDK/issues
https://github.com/microsoft/CsWinRT/issues
https://github.com/microsoft/cppwinrt/commits/master/
I was going to complain how Avalonia still has issues with large binaries even with NAOT but I just tested it on https://github.com/sourcegit-scm/sourcegit on Windows, and the resulting size of the folder without symbols (the binary and like 4 dlls) is ~55MiB. The binary itself is 41MiB which is as much as Qt6-based qBitorrent binary takes on Windows. So it seems while Avalonia works well enough on macOS, the size of binaries and memory consumption are higher than on Linux and Windows huh.
Fair enough, although I trust them more to sort out those issues, than to keep waiting for Project Reunion to deliver what was promised at BUILD 2020, or by C++/WinRT team at CppCon 2017 (which is WinUI 3.0 foundation).
> written in AvaloniaUI or, nowadays, WinUI 3
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.
Wait what? AvaloniaUI is not WPF, neither is WinUI3 which is new and maybe something you'd consider if you only target Windows (I presume it's better than using it through Uno, otherwise you'd probably choose Avalonia to support all OSes).
GP argues that UI frameworks in .NET come and go, despite each one being “the final one”.
Can't you still do much the same with WinForm, or maybe GTK?
With WinForms you can do much better, in large part because .NET itself ships with Windows and thus the app can just rely on it being there, but also because C# compiles to bytecode rather than native code (so it's not exactly a fair comparison). Anyway, the identical hello world GUI app in C#/WinForms is ~11 Kb.
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).
Even if C# compiles to bytecode, NGEN has been part of the framework since version 1.0, although using strong named assemblies might be bit of a pain.
Then there is .NET Native and Native AOT.
You couldn't redistribute NGen'd binaries tho, it was basically a local AOT'd cache.
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.
Is that statically linked or dynamically link? If the later, does it include all the libraries and assets it uses?
Does it have dark theme support and does it sync it's theme with the system one?
Not with the Win32 backend, since those widgets themselves don't have that notion.
Qt backend should be able to do that, though (but then of course you need all those Qt DLLs).
Windows widgets don’t have dark mode support on Windows?
Win32 ones don't only new WinUI ones do (similar to GTK2 vs GTK3+). You need to add that coloring manually. You can query the dark mode with Win32-only API[1] but you need to make your own styles or you can use undocumented APIs (that can break anytime) that Microsoft uses internally for the applications shipped with Windows[2]
[1]: https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-wi... [2]: https://github.com/ysc3839/win32-darkmode
(GTK 2 does support dark themes, of course, it just doesn’t have a concept of “light/dark theme variants” natively. And come to think of it, it’s the same in Win32: see e.g. the Zune theme for Windows XP.)
> Not with the Win32 backend, since those widgets themselves don't have that notion.
Lazarus is still my favorite when developing desktop apps.
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.
I had a client habing trouble with and old vb6 software they where using in production. Replaced it with a lazarus app, and been running for 10 years now without problems.
Me too! I have a software in production for a client made with Lazarus 3 (in Pascal of course) and everybody loves the "Windows feel" of the Gui. On Linux there is Gambas [1] wich is like Lazarus but for Basic.
[1] https://gambaswiki.org/website/en/main.html
Lazarus is available on Linux too, and on some other platforms as well, is what I've read on its site.
Pascal is more ALGOL than C
ALGOL-60 was huge, in around 1960. Niklaus Wirth had a detailed proposal for the next version of ALGOL, to be called ALGOL-X.
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.
Lazarus and Open Pascal is fun!
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?
> It’s such a turn off.
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?
The wiki is full of incomplete, obsolete, or otherwise not-so-useful articles. It suffers from typical "wiki as documentation" efforts, where instead of concentrated efforts from domain experts, you get a thousand half-baked opinions.
It has good stuff, but I'd wager the "bad stuff" outweighs it by a large margin.
Thank you for your response and your example.
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.
> And so it drives me crazy to see the state of their documentation.
I talked about this in my article about the release:
https://www.theregister.com/2025/05/09/new_lazarus_4/
The only relevant part I can find from that article is:
> 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?
No. You are incorrectly chaining statements.
* 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'm incorrectly asking questions? You sound like a great author.
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.
He did not say you are incorrectly asking anything. He said you were reading it wrong and explained why.
I stopped using the Lazarus documentation a year ago when the AI prompts (which seem to be trained on the actual documentation) became easier and faster to use.
Also AI also seems to get above average results with pascal code generation IMHO.
I only toyed with Lazarus/Free Pascal. There was some things I couldn't get used to. Maybe time to toy around again :) I feel like mentioning a few things that helped in the past: fpcdeluxe for installing a build of fpc and lazarus and a plugin called anchordockingdsgn to get all the floating windows in one window. It would be nice if 4.0 defaulted to that. The Castle Engine Pascal tutorial was actually pretty good also (which is mentioned in another thread here.) (edit: for the plugin, I see an option in fpcdeluxe to dock all windows - so it's possible to build that plugin in initially.)
fpcupdeluxe is great if you want to get a particular revision or build cross-compiling. If you need a stable version, just download the setup from. The docked IDE is the default option for this version.
It took way too long to figure out what Lazarus is based on their own website. Only found out because somewhere some random post said "Lazarus IDE".
I believe you are referring to their community forum. The link to "their own website" is in the left sidebar.
It is a pity that Lazarus and FPC seems to be so hard to deploy. It is of course an open source project, so its understandable.
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.
That's one problem I haven't had. I've even run Lazarus on a Raspberry Pi Zero W, it was slow but it actually worked. I don't know what kind of hoops the Mac has, but on Windows or Linux it's easy peasy.
I tried it and I can tell you that it's a lot easier with Lazarus 4 than it was with Lazarus 2.
At the same time it was deprecated[1] in Homebrew. Hope the mainstream will address the issue.
[1] https://github.com/Homebrew/homebrew-cask/pull/199559
Nice to see this, and I jumped on it immediately since I really wanted to do a minimal form-based UI to a tool I'm building, but on macOS I keep getting linking errors when compiling (on a fresh install, on a machine that never had Lazarus before).
I guess I'll wait for the next minor.
Run Windows or Linux in a VM on macOS, and Lazarus in that VM?
Also, is there no binary installer for macOS on the Lazarus site? Just asking. Don't know if there is one.
This was the name of a sadly gone Firefox extension that saved all your form field values automatically
Wow you just triggered a memory. I absolutely remember that plugin and it saving me a few times.
yeah this is what i remembered too when i saw the name. that extension was so great!
> Windows: 2k, 32 or 64bit, Qt, Qt5, Qt6 (64bit only)
Besides Qt, does it have a pure Win API back-end as well?
Yes. Try the IDE itself; on Windows it is built with Win API. PeaZip is a sample of it https://github.com/peazip/PeaZip
Ok, using WinAPI means it is not easily theme-able, unless they provide custom set of controls. I assume it is possible to use Qt back-end for Windows as well. I wish Lazarus also supported C++ akin to C++Builder. Pascal is a deal-breaker many.
Custom control set is supported too, and there are multiple alternatives.
Yes, Lazarus has a native Win32/64 widgetset (LCL-Win32) that directly uses the Windows API without Qt dependencies.
Obligatory https://castle-engine.io/modern_pascal
Alternatively, Jeff Duntemann just released new edition of "FreePascal from Square One", free PDF: https://www.contrapositivediary.com/?p=5399
This is one of the best introductions to what programming a computer is about that I know. I highly recommend checking it out, even if Pascal-like languages are not your cup of tea.
> To return a value from a function, assign something to the magic Result variable. You can read and set the Result freely, just like a local variable.
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"
I'll often use `result` as the return value in other languages, largely because I learned it in Delphi 25 years ago. It doesn't have the automatic return value semantics elsewhere, so you also need `return result` or whatever, but it's crystal clear what the intent is. I prefer it for that reason alone.
That’s what I do too, but it never occured to me that I got it from Delphi. Makes perfect sense :)
`Result` is clearer given that in Pascal, a function name by itself in any other context is a function invocation (with no arguments). That is, you then have this kind of stuff:
The first assignment here is assigning to the magic result variable, while the second one recursively invokes the function and dereferences the returned pointer to assign through it. This is technically not ambiguous (since you can never have a naked function call on the left side of the assignment, unlike say C++), but it's a subtle enough distinction for human readers. No such problem with `Result`, obviously, which is presumably why it was one of the things that Delphi added since day 1.> I'm torn about which is clearer, that magic variable style or assigning to the function name as one does in VBScript.
That's also "old style" Pascal, and still supported by Free Pascal (even though the compiler gives you a warning for doing it!).
>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"
Isn't it basically equivalent to an anonymous tuple which is automatically deconstructed on assignment?
Not exactly because you cannot store the entire tuple in a variable.
To the novice reader in golang, it was an unexpected "wait, where did these symbols come from?" because I wasn't used to being able to look after the function signature for variable names, and that's doubly true for symbol names that didn't come from caller data
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
I also just realized they're one of the places where golang doesn't emit a compile error for unused variables (as in the example above). Now I extra hate itFor glance reading code, a predictable variable name or return keyword is a lot easier imo.
Note that both are possible in Delphi and FreePascal - the intrinsic procedure `Exit(X)` is the equivalent of C `return`.
It would be great if release announcements like this always included a description of what the product actually is.
>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.
It's a link to a whole forum purely focused on that IDE, with it's name in domain name.
Why would they explain that to their audience? They know.
Because these things get shared elsewhere and end up getting looked at by someone who has no idea what the product is, like me, this time, with Lazarus.
You are overreacting. It takes one click - the logo on top left - to go back to main site which covers "what is lazarus?" clearly. Is that logic, that a main logo of the site goes back to home page, already lost?
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.
Also what's new in V4. Edit: it is linked in the post: https://wiki.lazarus.freepascal.org/Lazarus_4.0_release_note...
Delphi and Lazarus have been around for decades. It's like asking what lisp is.
Since I read about the guy who was surprised that anything other than SPAs exist (the full page reload magic incident), I realized there are way younger people in the field with no context or knowledge of CS history whatsoever, so some of them not knowing about Lazarus or Delphi sounds totally plausible.
> Since I read about the guy who was surprised that anything other than SPAs exist (the full page reload magic incident)
now you have referred to something I do not know about. Was it on HN or where?
yes it was on HN a couple weeks back, but I have a hard time finding it now, does anyone else remember some more details to find a match?
I think it's not elitist at all to say that people with no CS education (whether academic, self taught, or acquired over time) should probably not be considered when writing documentation or release notes.
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 have also met people who have to ask what Lisp is. You might be surprised at how many people don't know things like this.
You forget that every day, someone wakes up who is new to this planet.
And on that day their first priority is securing a good open source object Pascal compiler.
It was so much harder when I was a baby- you had to bootstrap the whole thing on an IBM 360.
I know Delphi, yet I didn't know Lazarus until now. I'm sure there are others like me.
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.
10000 thousand people a day hear about any given topic for the first time in their life https://xkcd.com/1053/
Which is an excellent point for conversations, but in the context of the release notes in the website of the project, I understand that this xkcd principle does not apply.
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.
Sometimes I click on HN submissions out of idle curiosity, not because I seek those out, or because I know what the link refers to.
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
> Delphi and Lazarus have been around for decades. It's like asking what lisp is.
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.
HN submissions don't have a field for description. And you are supposed to use original title. And there is a length limit on title. And some angry internet user will make a comment - sometimes even the submitter.
Yeah, technically you could add text with the link submission, but it will demote the link somewhat and I guess is just frowned upon here.
Oh it seems my point was ambiguous, I really meant the website should include it
I think you'd have a larger impact if you convinced other communities, like the Linux kernel or Xfce, that their "products" ought to have a note like that in their release announcements.
Can you suggest free resources for FreePascal and Lazarus?
Have people tried combining it with better-supported languages like Python or Go or Rust, leaving only the GUI to Pascal? Any guides out there?
https://github.com/ying32/govcl is a binding of the Lazarus LCL GUI library to Go. It works pretty well, although I really got the impression that GTK2 and Win32 were the best supported targets, anything more modern was pretty buggy, so don't rely on it for hidpi support.
> Have people tried combining it with better-supported languages like Python or Go or Rust, leaving only the GUI to Pascal? Any guides out there?
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).
Delphi does - eg https://blogs.embarcadero.com/getting-started-wit-python4del...
I use Lua from Delphi and vice versa regularly