6 ms·

Native Applications with Racket

83 points by Bogdanp 7y ago

saagarjha 7y ago
> it is a completely native Cocoa application whose frontend is built with Swift, the core business logic is all in Racket This is generally the way to go if you want to be cross-platform: write your core code in the language of your choice, but make sure you use the platform frameworks for the porcelain. If you do it well, your users won’t notice the difference!
- Klonoar 7y ago
  This is easy to say for Mac, where there’s a “true” platform framework. It’s not as clear cut for Windows/Linux, and hell if I’m going to spin my wheels writing UI code for ages. It’s been beaten to death relentlessly but there’s a reason nobody actually does this anymore. It’s also seriously funny that it’s the same accounts that argue this stuff every time it comes up on this site. ;P
  - rymate1234 7y ago
    There's a true platform framework for Windows, and that's either WPF if you need to target Windows pre 10, and WinUI / UWP for targeting Windows 10 People do this all the time, there's native mobile applications using the true platform frameworks for both operating systems
    - Longhanks 7y ago
      Win32 is still the definition of native on Windows, it's used by Explorer, Paint, cmd, WinRar, Chrome, Firefox and many more applications. Most UWP applications did not succeed their Win32 counterparts (yet?), for example Edge (which is replaced by Chromium, which is built on Win32), Paint 3D (where Microsoft paddled back from their initial statement of removing the "old" mspaint.exe), Groove Music (basically on life support). There's plenty of abstractions for Win32, too, such as Qt (see VLC for example, which feels native to Windows). The only major consumer program written in WPF I know is Visual Studio, but I haven't heard of WPF development in a long time (except for the move to open source).
  - catalogia 7y ago
    I think at this point GTK is the de-facto "native" for Linux desktops unless you've named your application something that begins with 'k'.
    - ilammy 7y ago
      Yeah, right. If you do that you are legally required to use Qt.
    - kitsunesoba 7y ago
      GTK has the advantage of having fully capable bindings for every language under the sun, so I would generally agree. Qt is harder to create bindings for since it’s C++, meaning it’s more likely that your language of choice doesn’t have bindings, in which case if said language doesn’t have C++ interop you’re stuck.
  - tomjen3 7y ago
    Honestly, just write the front-end in Visual Studio/C# and that should be native. Or write it in Win32 api, in C. For GNU/Linux, write it in GTK or QT, as appropriate.
  - saagarjha 7y ago
    It comes up quite often ;)
todd3834 7y ago
I’m working on a MacOS app and I started with a somewhat similar idea but with Go instead of Racket. I ended up ditching it for pure Swift. The main difference between myself and the author is that I ended up really liking Swift. Otherwise I would have stuck with my original approach.
- olah_1 7y ago
  > More importantly, I plan to support Windows and Linux which means that writing the core in a portable language is going to minimize the amount of work I have to do as well as the differences between the implementations on each platform. That's the main difference between you and the author.
  - todd3834 7y ago
    I plan to support those too. My hope is that some of the business logic written in Swift will be shared across platforms. So the big difference is definitely how we feel about the language. Our goals are very similar.
    - satyenr 7y ago
      The last I checked, Swift is not supported on Windows — and Linux support is tentative at beat. I mean, only Ubuntu is officially supported.
      - todd3834 7y ago
        I can’t find anything that suggests Ubuntu is the only officially supported distro. Can you share a reference for that? I have seen a lot of movement for Windows but you might be right that this could be a problem. My hope is that it gets resolved before I get there. Great point though. I kind of just assumed I could ship Swift on Windows.
        satyenr 7y ago
        https://swift.org/download/#releases https://swift.org/download/#releases
nixpulvis 7y ago
This notarization nonsense is being implemented very poorly it sure feels like. Shouldn't we be more focused on sand boxing and default settings for the sandboxes, vs forcing user applications to ask for everything they need? Put the burden on the runner, not the application. Am I missing something fundamental here?
- csande17 7y ago
  The way to think of notarization is that it's basically the same thing as Windows Defender's Automatic Sample Submission, which sends unknown executables to Microsoft for analysis. Only instead of having the end-user's machine upload the executable the first time it's run, the developer has to upload it to Apple. (This is better from a privacy/marketing standpoint.) In this case, the user application also had to explicitly request permission to run unsigned just-in-time-compiled code. This makes sense because macOS apps are typically written in compiled languages like Objective-C or Swift, so executing unsigned code usually means someone's doing something bad like a buffer overflow attack. Also, Apple probably wants to collect metrics on how many apps use JIT (and how) so they can restrict it more in future OS releases. I agree that a well-implemented sandbox seems like a much better solution here.
jsjolen 7y ago
Sounds slow to use RPC with JSON for communication. It seems that Racket does allow for C-to-Racket calls. You could write a glue program that generates C code that calls Racket functions and returns data, Swift code can then be generated to call that C code. That might be faster.
- Bogdanp 7y ago
  Sending/receiving (plus encoding and decoding) one payload takes less than 100 microseconds on my machine. It's far from being a problem, although you're right that linking against a shared library and making the calls that way would be faster.
JohnStrangeII 7y ago
Is there any "publishing service" for MacOS that takes a percentage of each sale and allows you to provide build scripts and source code, compiles and tests the application and distributes it on the app store? If not, do the Apple EULAs prohibit such a service or is it not considered lucrative enough? I used to develop for MacOS but have stopped supporting it entirely since Catalina, because I cannot be bothered with being locked into Apple's development tools, notarization, the Developer Network, and so on. It just isn't worth my time and money, but I'd still like to distribute native applications. Provided the EULA of such a service would be reasonable (e.g. good protection of the source code), I'd gladly use it, since otherwise all Apple sales are lost anyway. But there doesn't seem to be any such service, and it's IMHO weird that Apple don't offer that themselves.
- saagarjha 7y ago
  You’d have to give them your signing certificate.

83 points by Bogdanp 7y ago

> it is a completely native Cocoa application whose frontend is built with Swift, the core business logic is all in Racket This is generally the way to go if you want to be cross-platform: write your core code in the language of your choice, but make sure you use the platform frameworks for the porcelain. If you do it well, your users won’t notice the difference!

Klonoar 7y ago
This is easy to say for Mac, where there’s a “true” platform framework. It’s not as clear cut for Windows/Linux, and hell if I’m going to spin my wheels writing UI code for ages. It’s been beaten to death relentlessly but there’s a reason nobody actually does this anymore. It’s also seriously funny that it’s the same accounts that argue this stuff every time it comes up on this site. ;P
- rymate1234 7y ago
  There's a true platform framework for Windows, and that's either WPF if you need to target Windows pre 10, and WinUI / UWP for targeting Windows 10 People do this all the time, there's native mobile applications using the true platform frameworks for both operating systems
  - Longhanks 7y ago
    Win32 is still the definition of native on Windows, it's used by Explorer, Paint, cmd, WinRar, Chrome, Firefox and many more applications. Most UWP applications did not succeed their Win32 counterparts (yet?), for example Edge (which is replaced by Chromium, which is built on Win32), Paint 3D (where Microsoft paddled back from their initial statement of removing the "old" mspaint.exe), Groove Music (basically on life support). There's plenty of abstractions for Win32, too, such as Qt (see VLC for example, which feels native to Windows). The only major consumer program written in WPF I know is Visual Studio, but I haven't heard of WPF development in a long time (except for the move to open source).
- catalogia 7y ago
  I think at this point GTK is the de-facto "native" for Linux desktops unless you've named your application something that begins with 'k'.
  - ilammy 7y ago
    Yeah, right. If you do that you are legally required to use Qt.
  - kitsunesoba 7y ago
    GTK has the advantage of having fully capable bindings for every language under the sun, so I would generally agree. Qt is harder to create bindings for since it’s C++, meaning it’s more likely that your language of choice doesn’t have bindings, in which case if said language doesn’t have C++ interop you’re stuck.
- tomjen3 7y ago
  Honestly, just write the front-end in Visual Studio/C# and that should be native. Or write it in Win32 api, in C. For GNU/Linux, write it in GTK or QT, as appropriate.
- saagarjha 7y ago
  It comes up quite often ;)

todd3834 7y ago

I’m working on a MacOS app and I started with a somewhat similar idea but with Go instead of Racket. I ended up ditching it for pure Swift. The main difference between myself and the author is that I ended up really liking Swift. Otherwise I would have stuck with my original approach.

olah_1 7y ago
> More importantly, I plan to support Windows and Linux which means that writing the core in a portable language is going to minimize the amount of work I have to do as well as the differences between the implementations on each platform. That's the main difference between you and the author.
- todd3834 7y ago
  I plan to support those too. My hope is that some of the business logic written in Swift will be shared across platforms. So the big difference is definitely how we feel about the language. Our goals are very similar.
  - satyenr 7y ago
    The last I checked, Swift is not supported on Windows — and Linux support is tentative at beat. I mean, only Ubuntu is officially supported.
    - todd3834 7y ago
      I can’t find anything that suggests Ubuntu is the only officially supported distro. Can you share a reference for that? I have seen a lot of movement for Windows but you might be right that this could be a problem. My hope is that it gets resolved before I get there. Great point though. I kind of just assumed I could ship Swift on Windows.
      - satyenr 7y ago
        https://swift.org/download/#releases https://swift.org/download/#releases

nixpulvis 7y ago

This notarization nonsense is being implemented very poorly it sure feels like. Shouldn't we be more focused on sand boxing and default settings for the sandboxes, vs forcing user applications to ask for everything they need? Put the burden on the runner, not the application. Am I missing something fundamental here?

csande17 7y ago
The way to think of notarization is that it's basically the same thing as Windows Defender's Automatic Sample Submission, which sends unknown executables to Microsoft for analysis. Only instead of having the end-user's machine upload the executable the first time it's run, the developer has to upload it to Apple. (This is better from a privacy/marketing standpoint.) In this case, the user application also had to explicitly request permission to run unsigned just-in-time-compiled code. This makes sense because macOS apps are typically written in compiled languages like Objective-C or Swift, so executing unsigned code usually means someone's doing something bad like a buffer overflow attack. Also, Apple probably wants to collect metrics on how many apps use JIT (and how) so they can restrict it more in future OS releases. I agree that a well-implemented sandbox seems like a much better solution here.

jsjolen 7y ago

Sounds slow to use RPC with JSON for communication. It seems that Racket does allow for C-to-Racket calls. You could write a glue program that generates C code that calls Racket functions and returns data, Swift code can then be generated to call that C code. That might be faster.

Bogdanp 7y ago
Sending/receiving (plus encoding and decoding) one payload takes less than 100 microseconds on my machine. It's far from being a problem, although you're right that linking against a shared library and making the calls that way would be faster.

JohnStrangeII 7y ago

Is there any "publishing service" for MacOS that takes a percentage of each sale and allows you to provide build scripts and source code, compiles and tests the application and distributes it on the app store? If not, do the Apple EULAs prohibit such a service or is it not considered lucrative enough? I used to develop for MacOS but have stopped supporting it entirely since Catalina, because I cannot be bothered with being locked into Apple's development tools, notarization, the Developer Network, and so on. It just isn't worth my time and money, but I'd still like to distribute native applications. Provided the EULA of such a service would be reasonable (e.g. good protection of the source code), I'd gladly use it, since otherwise all Apple sales are lost anyway. But there doesn't seem to be any such service, and it's IMHO weird that Apple don't offer that themselves.

saagarjha 7y ago
You’d have to give them your signing certificate.