Hacker News Reader

Comment by pjmlp | Hacker News Reader

Not the OP, for me what I am looking forward is a systems language with automatic memory management, in the same vein as Modula-3, Active Oberon, D or System C#.

Swift fills that slot, but only on Apple platforms. Linux hardly has portable support even for file access and Windows will get supported some day, and most 3rd party libraries assume Apple anyway.

D has a great community, but still found lacking in some areas.

.NET AOT compiled with the learnings taken from System C# (7.x - 9) is the closest for my daily coding activities.

Ideally Delphi like with automatic memory management.

Or maybe having a Rust IDE with visual representation of lifetimes would already be productive enough.

View on HN

Maybe a stupid question: if I want to write cross-platform desktop GUI apps and be able to take full advantage of the desktop GUI (menus, status icons in the system tray, etc.), and I'm mostly developing on Windows, what should I learn? That's what I'm looking for, and I'm sure it already exists; I just don't know how to find it other than asking around.

(I tried to install some Haskell GUI libraries, but that's very difficult on Windows. I eventually got haskell-gi to install, but as far as I could tell, it had no support for status icons.)

If you are doing Windows stuff and want native UI, then there is no way around Delphi, .NET or C++ (or C if you are masochist enough to use bare bones Win32).

Qt does a pretty good job for C++ and Python, but it is not native if that is what you're looking for.

JavaFX would be a good approach if you are into JVM languages, but you might need to do some JNI wrappers to call stuff like system tray, as just like Qt it does its own rendering.

Some corporations, go the route of having common code for the business logic, and then create an abstraction layer for stuff like system tray, UI widgets and stuff. Although is does require additional development cost.

So you call something like show_tray_message "New Email" and have an implementation for each OS that you care about.

If you are using Haskell, have you tried Haskell Platform?

Thanks for the information! Qt is fine. I might switch back to Linux in the future, and want to be able to carry over anything I write if I do. I have a working prototype in Python using PySide already (which handles the system tray well), but I figure I ought to know a compiled language with static typing. (I know interpreted vs. compiled is a questionable distinction to make these days; what I want is a language that comes with something to produce independent executable files as part of its basic tooling.

I've tried Haskell Platform. I had a lot of path problems in trying to install gtk2hs - it wasn't always obvious where things were (nor that Stack came with its own mingw, so I got my own, and that caused more problems... eventually I wiped everything Haskell-related and started from scratch with Platform), and there's also a known problem with gtk2hs where you have to edit some cabal files to make installation work on Windows, so I would've had to do local installs. I think I got gtk2hs to install at one point, and even to compile their sample hello-world program, but trying to actually run it gave a litany of obscure errors. WxHaskell has an installer batch file, but it just spewed errors at me. I spent about a week trying to install various GUI libraries, and the only one I tried that I managed to get working was gi-gtk... which doesn't have system tray support.

I'm hoping to avoid C++ and Java, but if I have to bite that bullet, I will.

> what I want is a language that comes with something to produce independent executable files as part of its basic tooling

Worth noting that the Fman Build System (fbs)¹ gets you most of the way there with Python and Qt5, allowing you to "freeze" a PyQt5 application and automatically generate a Windows installer. I don't recall of the top of my head if there's a way to condense that into a single standalone executable, but it certainly produces a single folder by default (which you can stick anywhere, like any other "portable" Windows app).

I haven't used this in production yet, but testing it has been promising enough, and I'm using this for my next desktop development project.

¹: https://build-system.fman.io/

A single folder is good enough. This looks useful - thanks!

> but you might need to do some JNI wrappers to call stuff like system tray

I don't do much desktop programming, but I think that the system tray has had support in Java for many years now:

https://docs.oracle.com/javase/tutorial/uiswing/misc/systemt...

Not if you want the Windows 10 stuff.

And that whole JDesktop stuff from Sun is unfortunately unmaintained since years (still left to rotten under Sun's stewardship).

Ah. Well, now that Microsoft have said they want to contribute to OpenJDK, maybe you could persuade them to do something about that.

It would be nice I guess.

I like both platforms anyway.

> I am looking forward is a systems language with automatic memory management

Doesn't Nim check those boxes? Didn't try it personally but I was instantly reminded of Nim when I read your comment.

Indeed, however it seems having a community even smaller than D, and it is still on the phase of depending on C or C++ as compiler backends, just like C++ and Objective-C on their early days.

Depending on C is actually a feature. Why do you consider it a negative?

You don't replace something that you depend on, for starters.

Then C is not portable Assembly that keep being talked about, so unless you stick with care to ISO C, there will be UB and compiler specific behaviour creeping into backend.

Even languages that use LLVM suffer from this, because its design is tainted by clang, and for certain bitcode sequences, it assumes C semantics.

This broke a couple of Rust optimisations. Not sure if they already got around fixing this.

Then C does not really expose the CPU features, so if you want to actually access everything. Either you need to support inline Assembly as well, or ship Assembly alongside C anyway.

Having C as backend is only useful as means to bootstrap an eco-system to not spend too much time implementing a backend.

However when a language matures, it is time to move on, just like C++ and Objective-C did.

Reply on news.ycombinator.com