I’ve used revery-ui for toy projects and it worked well. But I used the reason-ml ecosystem.
3 Likes
I’m all for improving support for Windows, but helping people out of proprietary software is as important today as it was 20 years ago, and nothing is gained by pretending to be naive and that it’s just a matter of preference that doesn’t really matter.
There is no reason to be ashamed of the poor state of OCaml under Windows. There are good reasons why it’s the case. To state the obvious: I, for one, have never tested my software on Windows because I’m not allowed to.
1 Like
I don’t think it was a choice. It’s very likely that the engineer or team of engineers were part of the language’s community and it made sense for them to keep using that language. I believe pyre-check, hack, and initial versions of the rust compiler were written in OCaml for the same reason.
There’s little science to attracting developers away from other languages, it’s more often than not a chicken-and-egg problem. So pessimistically I think we should just stop trying. We keep having discussions about it on this forum and, as much as I enjoy reading and partaking in these discussions, none of it has been fruitful in any way.
2 Likes
would you know of any project using revery-ui with plain OCaml syntax?
I don’t know of any projects, but from what I know, it is possible to use plain OCaml syntax in the esy/reason-ml ecosystem.
But you can’t use revery-ui without the esy/reason-ml ecosystem. Not without a lot of hacking around at least. You can opam packages in esy, but the other way around is not easy.
Revery uses dune (via esy) for itself and all its dependencies and it could be possible to “vendor it” and all its dependencies into your project, monorepo-style
Not going to try it, though.
I have used js_of_ocaml with gjs and gobject-introspection to provide a gtk3/4 GUI in a toy application: to be honest, mainly to see how it went. It works, although using js_of_ocaml and lwt with gjs has some quirks (which I can expand on if anyone is interested). I don’t imagine this is in widespread use though.
I haven’t tried it, but looks like Tauri may also be an option: Tauri can be an option for desktop GUI with rescript - ReScript Forum
Tauri is like Electron, except lightweight because (IIUC) it doesn’t ship with Chrome but reuses the OS’s native webview.
1 Like
At LexiFi we have been writing Windows GUI apps using GitHub - LexiFi/csml: High-level bindings between .Net and OCaml, a general high-level bridge between .NET and OCaml for a long time. And I’ll say in passing that in many industries (ie: not hobbists, not researchers, not enthusiasts, but people who sell the software they write), targeting Windows is often not a choice, but a requirement.
Having said that, nowadays everyone (including said industries) is migrating to the web, so having access to system-specific GUI frameworks is going to be less important in the future…
Sorry, but this is not accurate: free Windows VMs for evaluation (including a full developer toolchain) are available for download at Download a Windows virtual machine - Windows app development | Microsoft Developer.
Cheers,
Nicolas
4 Likes
I agree it’s not something to be ‘ashamed’ of, just something to improve–which is happening thanks to the constant efforts of people in the community.
Sure, but according to my observations imposing a mainstream language is more common than imposing a target OS (because most client side software is just the browser). Lexifi is renown to be an exception to the rule.
Thank you for the link to the free VMs. I was indeed unaware of that. I will definitively try to setup an automated build using this.
Curiously, the GUI struggle is common among many higher-level languages. Rust, Haskell, few others - they all either have GTK+ bindings, some half-working Qt bindings, and nothing else. It’s not an OCaml’s fault.
The only languages that don’t have such problem are the tamed ones - languages that forcefully fitted into the narrow limitations of the .NET or Java virtual machines/bytecode.
So long since I looked at Java (huzzah! huzzah!) What’s the story there? Last I looked, they had a Swing implementation on top of an AWT canvas ? But nothing like QT or GTK. So it was not merely that it was tamed, but also that the GUI toolkit came with the language implementation and you really had no choices.
Has that changed?
Well you also have SWT, the toolkit used by the eclipse IDE, that relies on native UI bindings, but that never really took off outside of eclipse.
Swing was supposed to be replaced by JavaFX as the default for the JDK, but that was dropped. (JavaFX still lives, but it’s outside the JDK mainly pushed by a company called Gluon)
In the Java coporate land, none of this really matter any more. Most news UIs are web based, so something like react or vue with a SpringBoot backend.
There’s also Delphi / FreePascal/Lazarus, which have their own windowing toolkits developed over decades of work.
This is not about imposing this is adapting to your client’s tools and infrastructure which you rarely get to redefine entirely.
Lexifi is no exception. Most people I have worked with either use macOS (artists and graphic design shops) or Windows (small companies and engineering practices) and that’s where they want to see their tools run.
Also if they have a web presence, don’t think you’ll get a fancy vm infrastructure. What you mostly get is php shared hosting; and consider yourself lucky if you can ssh to it.
2 Likes
Should I use things like esy instead of opam? No. Use opam if you’re doing backend development
After working on Tezos for like 6 months I hardly disagree on this, opam experience is just not what I would want from a package manager in 2021. esy is not great either, but having sandboxing is a bless.
Basically, avoid using (pure) Windows for OCaml development. It’s likely to be a painful experience if you are a beginner.
Using a new operating system is also likely to be a painful experience, and this is mostly not a problem when using esy, which especially after the latest release works really nicely on Windows.
3 Likes
From my limited experience, the way software shops work around this is to minimize how much desktop or operating system specific client code they implement. So there might be an excel add-on or some small pieces that act as a windows client, but it helps with the last mile, and the heart of the system is a collection of cloud services, with apis and web front ends.
A terrible “workaround” which incurs recurring costs and maintenance that a lot of small companies are not willing to afford the cost of – and rightly so in my opinion.
I mean the guy points you to this very primitive but working CNC machine software that runs on Windows 95 and he paid once 20 years ago and has been doing very well for him since then. In fact so well that he perfectly knows how to work around these NaN convertion bugs when they occur. And you come up to him with some crazy cloud bullshit which is going to depend on an internet connection, a server at the other end of the world and cost him recurring service and maintenance costs. No way.
There’s a lot of sanity in these real (in the sense not technologist) people… and they are right in not trusting an industry whose services are utterly expensive and that keeps on rewriting its “solutions” onto themselves every five years.
8 Likes
I am neutral on this point. I think a typical cloud service will be affordable, it’s more whether the service will respect a users privacy.
As a developer, I would implement for cloud or desktop, but I just don’t want to have to deal with stress of having many deployed versions and having to distribute updates. If people build really high quality appimage auto update services and all of my users in some hypothetical software development scenario agreed to electing for auto upgrades, I would be happy to focus only on desktop.