Crystal: Fast as C, Slick as Ruby • Hacker News Board

Re: Crystal: Fast as C, Slick as Ruby

#231

Post by chrislgrigg » Thu, Aug 04, 2016, 2:18 PM UTC

paulddraper wrote: post #213

koffiezet wrote: post #196

Earlier quoted context omitted.

Having worked in environments where GC was an absolute "no go", I'm always amazed that so many people have problems with a GC. Yes there are types of software where using a GC'd language would probably be a bad thing. If you're talking about huge projects with heavy performance constraints (os kernels, AAA games and browsers come to mind), I would probably try to avoid it. But most likely - you simply do not need a l…

GCs are complex and require lots of end-user tuning -- just look at the performance articles on Java. Beyond that, however, there are many uses for ownership beyond controlling memory resources. Closing a TCP connection, releasing a OpenGL texture...there are lots of applications of having life cycles built in to the code rather than the runtime. EDIT: fixed typo

This is all true for some languages but I think it it's far from universal. It seems to me that in many of the most frequently used and taught modern languages, the nearest most devs will come to being concerned with GC is an awareness of why object allocation should be minimized. For their purposes, that is a much better use of time than giving any consideration to GC tuning.

Re: Crystal: Fast as C, Slick as Ruby

#232

Post by GirlsCanCode » Thu, Aug 04, 2016, 2:19 PM UTC

Ruby is not slick.

Re: Crystal: Fast as C, Slick as Ruby

#233

Post by filereaper » Thu, Aug 04, 2016, 2:19 PM UTC

exDM69 wrote: post #170

anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

About GC: it would be nice if there would be some kind of standard-ish implementation framework for a GC in an LLVM language. LLVM has been enabling fantastic new programming languages, and while it has support for a GC, I have not found a GC library that would be easy to embed in a new compiler/runtime environment. Now there are dozens of LLVM-based languages (or language prototypes) that have different, incompatibl…

"About GC: it would be nice if there would be some kind of standard-ish implementation framework for a GC in an LLVM language."

Not quite LLVM, but take a look at the Eclipse OMR project.

OMR intends to provide a set of reuseable components like a GC, port-library and given more effort a jit to be reused into existing language runtimes or build a whole new language out of them.

https://github.com/eclipse/omr

Re: Crystal: Fast as C, Slick as Ruby

#234

Post by pathsjs » Thu, Aug 04, 2016, 2:19 PM UTC

exDM69 wrote: post #222

pathsjs wrote: post #193

Earlier quoted context omitted.

Nim fits everything you ask, except for "can target GPUs via LLVM or SPIR-V". Even that may eventually be fixed by having OpenCL C as a compilation target. Also, I am not sure what you mean by "first class SIMD structures", but you can definitely have a single definition for sin4f and sin8f if they are line by line equal except types, by using union types.

Nim is definitely on my short list of languages to learn, however... Targetting GPUs is a deal-breaker. I'm sure the Nim compiler would be pretty easy to retarget to GPUs via SPIR-V (the new binary IR for Vulkan/OpenCL shaders and kernels) or OpenCL/CUDA C. But I don't think that would work for Nim's runtime system or existing Nim libraries (including any standard libs it has). Also Nim's pauseless low latency automa…

A union type in Nim can only be used in funciton arguments, and it does the obvious thing: when you actually call the function, it specializes to the type you are calling with. Think about templates in C++, where the type parameter can only assume one of two (or more) values. Hence it would generate exactly what you would write by hand, but the syntax is much less messy than C++ templates

Re: Crystal: Fast as C, Slick as Ruby

#235

Post by rogerdpack » Thu, Aug 04, 2016, 2:20 PM UTC

Svenskunganka wrote: post #19

Athas wrote: post #6

The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 47.5s, while a corresponding C program executes in 0.88s - that's a factor 54 difference, while the article reports a factor 35 for Crystal. That's good, but what causes the difference? This benchmark is pretty much all function call overhead, so I doubt it's re…

There's some benches between various languages, including Crystal as well, for those interested https://github.com/kostya/benchmarks EDIT: There's also this: https://github.com/nsf/pnoise

Here's a small HTTP style benchmark across various languages (a bit limited, but still interesting): https://github.com/costajob/app-servers

Re: Crystal: Fast as C, Slick as Ruby

#236

Post by rogerdpack » Thu, Aug 04, 2016, 2:22 PM UTC

anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

I think it's target is more along the space where "go" is, as little code as possible (like a scripting language), but still speedy. So in true scripting language form, you don't have to worry about collecting your objects ever. I'm not aware of any benchmarks on the cost/hit of this, I do know it uses the BDW GC which is hopefully pretty battle tested...

Re: Crystal: Fast as C, Slick as Ruby

#237

Post by m_mueller » Thu, Aug 04, 2016, 2:22 PM UTC

exDM69 wrote: post #156

m_mueller wrote: post #73

Earlier quoted context omitted.

Obj-C? Or do you count ARC as a GC?

Whether reference counting is GC or not is arguing about semantics. But correctly implemented reference counting is essentially pause-free. It's consistently "slow", which is better for some cases that unpredictably "fast".

IMO it's not just semantics, rather, GC is too general of a term if it includes ARC. In terms of performance analysis the two are vastly different. One has basically an unbounded worst case but a good average case, the other is the opposite.

Re: Crystal: Fast as C, Slick as Ruby

#238

Post by rogerdpack » Thu, Aug 04, 2016, 2:22 PM UTC

clessg wrote: post #4

Looks very nice. I hope it gains momentum. For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked more over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum. If you want some idea of…

Apparently it entered the TIOBE list recently, so perhaps it will gain some momentum.

Re: Crystal: Fast as C, Slick as Ruby

#239

Post by rogerdpack » Thu, Aug 04, 2016, 2:23 PM UTC

xutopia wrote: post #215

lmm wrote: post #149

Earlier quoted context omitted.

Is Elixir actually any more mainstream/momentum-having than Crystal? I'd be more inclined to point people to e.g. OCaml.

Crystal aims to replace Ruby but at Railsconf and Ruby meetups I go to Elixir/Pheonix is mentioned 100x more than Crystal is.

I don't think it aims to replace ruby (they don't even claim any kind of "compatibility" level with ruby, more like "inspired by ruby" I would think), but...I wish it would replace it :)

Re: Crystal: Fast as C, Slick as Ruby

#240

Post by Asooka » Thu, Aug 04, 2016, 2:24 PM UTC

paulddraper wrote: post #213

koffiezet wrote: post #196

Earlier quoted context omitted.

Having worked in environments where GC was an absolute "no go", I'm always amazed that so many people have problems with a GC. Yes there are types of software where using a GC'd language would probably be a bad thing. If you're talking about huge projects with heavy performance constraints (os kernels, AAA games and browsers come to mind), I would probably try to avoid it. But most likely - you simply do not need a l…

GCs are complex and require lots of end-user tuning -- just look at the performance articles on Java. Beyond that, however, there are many uses for ownership beyond controlling memory resources. Closing a TCP connection, releasing a OpenGL texture...there are lots of applications of having life cycles built in to the code rather than the runtime. EDIT: fixed typo

Now that you mention other resources, I would kill for a generalised GC implementation. One where more resources than memory could be tracked. And even for memory it will be beneficial to have several GCd heaps so you could put different classes of objects on different heaps with different limits.

In short rather than not wanting GC, I think GC doesn't go far enough.