Embed Crystal code directly in Ruby • Hacker News Board

Re: Embed Crystal code directly in Ruby

#61

Post by throwiforgtnlzy » Fri, Apr 12, 2024, 4:21 AM UTC

jjice wrote: post #46

nomilk wrote: post #44

Ha. TIL you can do 1_000_000.times do ... (equivalent to 1000000.times do ...). That's really nice.

A lot of languages have added support for this over the last few years. It's a nice little quality of life improvement. I use it very regularly now. I find it really handy for currency amounts in cents, so I can say `10_00` for ten dollars, in cents.

Sorry, it's a been feature in a number of languages for decades. Perl has it at least as early as 5.005 in 1998. So naturally, Ruby had it since at least before 1.6 / 2002. Java added it in 2011. It didn't work with Python 2.1 from 2001, but I found it was added relatively late in PEP 515 in 2016 with Python 3.6.

As a latecomer, C23 went with ' just like C++ did almost 10 years earlier with C++14.

Re: Embed Crystal code directly in Ruby

#62

Post by sa-code » Fri, Apr 12, 2024, 7:26 AM UTC

raffraffraff wrote: post #48

So ruby fans want Crystal to get more publicity and python fans want Nim to get more. Has anyone used both in any serious project, and if so can you compare? I've spent a tiny amount of time with Nim but found documentation, training videos, books etc extremely thin on the ground. Lots of Nim projects on github are ancient and haven't been updated in years. Chat GPT never gave me working code. How is Crystal in this…

I think Python users are more on the mojo bandwagon rather than Nim now

Re: Embed Crystal code directly in Ruby

#63

Post by Wouterken » Fri, Apr 12, 2024, 9:10 AM UTC

Hey HN,

Author of the gem here. Appreciate the attention!

I hacked this together last weekend to scratch an itch and have some fun. This got a lot more attention than I was expecting so early on.

I've had to scramble a bit to start hammering this into something that's less prototype, more legitimate project. I hope it's now close to a cohesive enough state that someone trying it out will have a relatively smooth experience.

Given the interest, I definitely plan to sink a bit more dedicated time into this project, to tick off a few key missing features and add some polish. It would be great to see it grow into something that can be useful to more than just me. Seems like there's definitely some shared desire for this type of tool.

It probably goes without saying that you probably shouldn't convert large amounts of mission critical code to depend on this (for now).

It's still early days and the API hasn't been "crystallized" yet...

Re: Embed Crystal code directly in Ruby

#64

Post by octachron » Fri, Apr 12, 2024, 2:24 PM UTC

celdon25 wrote: post #25

nextaccountic wrote: post #20

Earlier quoted context omitted.

> You won't ever see fast compilation times with it, and here's why: > > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] There are fast type inference implementations. For example, the OCaml compiler is pretty fast No reason Crystal couldn't improve this part of compile time in future

I suspect that doesn't hold true for some larger projects (10K+ LOC) with no annotations but point taken. My experience with F# (which was way back in version 2.0, but based on OCaml which does type inference very similarly), was that the inference would become slower as the size of the project increased, eventually taking multiple seconds. I eventually adopted a habit of adding type annotations to commonly-used func…

Adding type annotations in OCaml never reduce the typechecking time: it adds more information for the typechecker to process and it can only increase the size of type. Typechecking time is proportional to the size of types but those tends to stay constants and small inside normal project. I think that F# should have a similar behaviour?

Re: Embed Crystal code directly in Ruby

#65

Post by dafelst » Fri, Apr 12, 2024, 3:40 PM UTC

unixhero wrote: post #57

dafelst wrote: post #38

Earlier quoted context omitted.

I have to assume you're trolling, but if not, the reason compile times matter is because iteration time is important. Having to wait longer to see the results of one's work results in loss of focus and productivity.

Yeah I know what time is. My point is, this is 2024 and computers are insanely powerful now. Compilation times can't be that bad.

For large projects using complex compiled languages like Rust, C++, and ostensibly according to this post, Crystal, yes, they are bad.

I have worked on several projects where a full clean compile of the project takes 30+ minutes, and even incremental compiles and links to a large module will take 60-90s at absolute minimum because linker times are still shitty - and this is even with modern, powerful hardware, think 32 or 64 hyperthread Ryzen CPUs, not just your typical dev laptop.

It may not seem like much, but 60-90s is definitely enough to get you distracted and out of the zone.