4 ms·

I read your comment and realized I don't think much about what it means to have native Windows support in a programming language. A crystal issue page [1] talks

I read your comment and realized I don't think much about what it means to have native Windows support in a programming language. A crystal issue page [1] talks about two ways to support Windows: - Cygwin (POSIX) - Native Windows API support Though I wonder if targeting .NET would be something to consider. It would not save much effort, compared to Windows API, but in principle, .NET is a portable platform (like POSIX). Also I wonder why the LLVM project doesn't make it relatively easier to support multiple platforms (including Windows). The whole promise of LLVM is that your prog-lang just targets LLVM (so to speak) and doesn't have to worry about specific platforms. [1] https://github.com/crystal-lang/crystal/issues/2569 https://github.com/crystal-lang/crystal/issues/2569

smt88 7y ago
If Crystal added CLR[1] (what you likely meant by .NET) or WebAssembly as a target, I guarantee its popularity would vastly increase. LLVM would be smart too, but I suspect that having access to the complete .NET ecosystem from a Ruby-like language would be very appealing to devs who worked on Ruby at home (or at startups) and are now at big enterprises that demand big-name stacks. 1. https://en.wikipedia.org/wiki/Common_Language_Runtime https://en.wikipedia.org/wiki/Common_Language_Runtime
- gdxhyrd 7y ago
  The GP is talking about the standard library support etc. of the compiled objects, while still being native.
ezrast 7y ago
> The whole promise of LLVM is that your prog-lang just targets LLVM (so to speak) and doesn't have to worry about specific platforms. "Platform" in this case mostly means executable format. LLVM is too low-level to be able to abstract away operating system features. The hard part of porting a project like Crystal isn't generating a valid binary (since LLVM does handle that part well), it's adapting the standard library for dealing with all the places where Windows and POSIX offer different interfaces to userspace - stuff like filesystem semantics, networking behavior, and threading where the system calls can't always be translated in a straightforward way.
pjmlp 7y ago
Having LLVM support is only half of the story, someone needs to make the runtime and standard library work on the platform as well.
yellowapple 7y ago
> Also I wonder why the LLVM project doesn't make it relatively easier to support multiple platforms (including Windows) LLVM's concern is the generation of machine code. That does indeed work for Windows even with Crystal; you can cross-compile a "Hello, world!" program and it'll run just fine in the Command Prompt. The actual problem lies in the OS-specific APIs. Windows and Unix are very different operating systems with very different designs and very different feature sets. LLVM can't really do much to fix that.

smt88 7y ago

If Crystal added CLR[1] (what you likely meant by .NET) or WebAssembly as a target, I guarantee its popularity would vastly increase. LLVM would be smart too, but I suspect that having access to the complete .NET ecosystem from a Ruby-like language would be very appealing to devs who worked on Ruby at home (or at startups) and are now at big enterprises that demand big-name stacks. 1. https://en.wikipedia.org/wiki/Common_Language_Runtime https://en.wikipedia.org/wiki/Common_Language_Runtime

gdxhyrd 7y ago
The GP is talking about the standard library support etc. of the compiled objects, while still being native.

ezrast 7y ago

> The whole promise of LLVM is that your prog-lang just targets LLVM (so to speak) and doesn't have to worry about specific platforms. "Platform" in this case mostly means executable format. LLVM is too low-level to be able to abstract away operating system features. The hard part of porting a project like Crystal isn't generating a valid binary (since LLVM does handle that part well), it's adapting the standard library for dealing with all the places where Windows and POSIX offer different interfaces to userspace - stuff like filesystem semantics, networking behavior, and threading where the system calls can't always be translated in a straightforward way.

pjmlp 7y ago

Having LLVM support is only half of the story, someone needs to make the runtime and standard library work on the platform as well.

yellowapple 7y ago

> Also I wonder why the LLVM project doesn't make it relatively easier to support multiple platforms (including Windows) LLVM's concern is the generation of machine code. That does indeed work for Windows even with Crystal; you can cross-compile a "Hello, world!" program and it'll run just fine in the Command Prompt. The actual problem lies in the OS-specific APIs. Windows and Unix are very different operating systems with very different designs and very different feature sets. LLVM can't really do much to fix that.