Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiling Ruby to machine language

patshaughnessy.net

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Compiling Ruby to machine language

#41

Post by jb1991 »

hk1337 wrote: post #24
jlarocco wrote: post #5

IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead. I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.

AFAIK, you can still use Objective-C and create apps for macOS, iOS, and iPadOS? The APIs previously used may not be available anymore.

I think you misunderstood the comment. They were referring to Ruby and accessing the APIs.

Re: Compiling Ruby to machine language

#43

Post by vidarh »

jlarocco wrote: post #5

IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead. I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.

The creator of MacRuby left Apple, and created RubyMotion. It's continued by different people, but still around, though it seems the main focus of the people involved now is DragonRuby (a game-focused Ruby implementation)

Re: Compiling Ruby to machine language

#44

Post by vidarh »

jweir wrote: post #19

Speaking of compiling Ruby. And Stripe coders who have used the Sorbet compiler? https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...

It seems to be gone from the repo, and doesn't seem to be worked on any more? A shame.

AOT compiling Ruby is hard. I'm trying [1] [2].

Sorbet would be in a good position because part of the challenge of making it fast is that Ruby has a lot of semantics that are rarely used but that makes making compiled Ruby fast really hard. E.g. the bignum promotion adds overhead to every single operation unless you can prove invariants about the range of the values; the meta-programming likewise adds overhead and makes even very basic operations really expensive unless you can prove classes (or individual objects) aren't being mucked with...

So starting with type checking is an interesting approach to potentially allow for compiling guarded type-specific fast paths. If my compiler ever gets close enough to feature complete (it's a hobby project, so depends entirely on how much time I get, though now I also justify more time for it by using it as a test-bed for LLM tooling), it's certainly a direction I'd love to eventually explore.

[1] https://hokstad.com/compiler (not updated for a decade)

[2] https://github.com/vidarh/writing-a-compiler-in-ruby/ (updated now primarily by Claude Code; it's currently focusing on actually passing RubySpec and making speedy progress, at the cost of allowing some fairly ugly code - I do cleanup passes occasionally, but most of the cleanup will be deferred until more passes)

Re: Compiling Ruby to machine language

#45

Post by pjmlp »

jlarocco wrote: post #5

IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead. I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.

It lives on as RubyMotion after the author left Apple, http://www.rubymotion.com/

https://en.wikipedia.org/wiki/RubyMotion

Re: Compiling Ruby to machine language

#46

Post by pjmlp »

eek2121 wrote: post #11
jlarocco wrote: post #5

IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead. I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.

Typical. I may get absolutely destroyed for this, but being professionally proficient in a ton of languages, including Ruby and the ones I mention below, and the ones I'm about to mention: This sounds like Microsoft when they moved from VB6 to VB.Net. At least they have a good thing going with C# though. VB6 was quite an interesting beast. You could do basically everything that you could do in languages like C/C++, b…

By .NET 2.0, VB.NET got most of the stuff back VB 6 folks complained about.

Now what .NET never did as good as VB 6, was ease of COM development experience.

Which given the role of COM in Windows APIs since Vista, is a major pain point as I don't get if COM is so relevant, why Microsoft teams keep rebooting, badly, the COM development experience.

Re: Compiling Ruby to machine language

#47

Post by byroot »

cutler wrote: post #25

Making dynamically typed, single threaded languages faster via JIT usually comes at the cost of a significant increase in memory consumption which for businesses smaller than Shopify is a much more significant factor.

Is it? Smaller business usually comes with smaller applications. Most cloud and hardware vendors give you about 4GiB of RAM per core, maybe only 2 when using "CPU optimized instances", that's huge and leave plenty of space for a couple hundred MB of JITed code.

Re: Compiling Ruby to machine language

#49

Post by bmm6o »

atherton94027 wrote: post #23
pizza234 wrote: post #21

Earlier quoted context omitted.

VB6 deserves the huge popularity it had, but the reason wasn't because of the language design, rather, its (extremely) rapid GUI application development. It was actually a two-edged sword - it facilitated writing spaghetti code. > You could do basically everything that you could do in languages like C/C++ As long as there is some form of memory access, any language can do basically everything that one can do in C/C++…

> As long as there is some form of memory access, any language can do basically everything that one can do in C/C++, but this doesn't make much sense. No VB6 had really easy COM integration which let you tap into a lot of Windows system components. The same code in C++ often required hundreds of lines of scaffolding, and I'm not exaggerating

It probably still sucks in C, but the C++ DX got a lot better. Importing the idl would generate wrapper functions that made calling code look much more like a normal function. It would check the hresult and return an out param from the function. They also introduced types like _variant_t that help boxing and unboxing native types. It still wasn't fun but it greatly reduced line count.

Re: Compiling Ruby to machine language

#50

Post by pjmlp »

bmm6o wrote: post #49
atherton94027 wrote: post #23

Earlier quoted context omitted.

> As long as there is some form of memory access, any language can do basically everything that one can do in C/C++, but this doesn't make much sense. No VB6 had really easy COM integration which let you tap into a lot of Windows system components. The same code in C++ often required hundreds of lines of scaffolding, and I'm not exaggerating

It probably still sucks in C, but the C++ DX got a lot better. Importing the idl would generate wrapper functions that made calling code look much more like a normal function. It would check the hresult and return an out param from the function. They also introduced types like _variant_t that help boxing and unboxing native types. It still wasn't fun but it greatly reduced line count.

Nah, unless talking about C++ Builder extensions for COM, in Visual C++ land it still sucks big time.

For some reason, there are vocal teams at Microsoft that resist anything in C++ that is comparable to VB, Delphi, .NET, C++ Builder ease of use regarding COM.

Hence why we got MFC COM, ATL COM, WRL, WinRT (as COM evolution), C++/CX, C++/WinRT, WIL, and eventually all of them lose traction with that vocal group that aparently rather use COM with bare bones IDL files, using the command line and VI on Windows most likely.

Post reply on HN