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

Crystal: Fast as C, Slick as Ruby

blog.codeship.com

Post reply on HN
Print view View original

351–360 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#351

Post by pjmlp »

uptownfunk wrote: post #313
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…

> Just face it: there is an need for something intermediate to fill the gap of a script-like, native compiled, low-overhead, modern language, and a GC is part of this. The popularity and "I want to be cool so I hate it" trend of Go proves this, but the devops space is getting new useful cool toys at a breakneck speed, pretty much exclusively written in Go. Could the answer be lbstanza when it gets there? Lbstanza.org

> the devops space is getting new useful cool toys at a breakneck speed, pretty much exclusively written in Go.

This is why I came to peace with Go's way of life.

Way better to push for less code being written in C, than argue about the language design decisions.

Re: Crystal: Fast as C, Slick as Ruby

#352

Post by pjmlp »

m_mueller wrote: post #237
exDM69 wrote: post #156

Earlier quoted context omitted.

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.

Any good CS book about GC includes RC as a GC algorithm.

For example, the classical "The Garbage Collection Handbook"

http://gchandbook.org/

Re: Crystal: Fast as C, Slick as Ruby

#353

Post by pjmlp »

GFK_of_xmaspast wrote: post #203
progman wrote: post #90

Earlier quoted context omitted.

> You avoid allocations wherever possible If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast that garbage collections don't really matter in most cases. Consider SBCL (compiled Common Lisp) which is almost as performant as Java and C++. http://benchmarksgame.alioth.debian.org/u64q/lisp.html I used…

RAII and smart pointers go a long way towards eliminating the need for GC in c++.

True, but usually one doesn't have control over the code others write to force them to use such tools.

Re: Crystal: Fast as C, Slick as Ruby

#354

Post by kminehart »

banachtarski wrote: post #329
kminehart wrote: post #306

Earlier quoted context omitted.

Of course. I've used C pretty extensively, Java enough to hate it, and C#. I consider myself a javascript developer because that's what I've done my best work in and that's what I enjoy the most.

He said decent type system, not static one.

C, Java, and C# have decent type systems, especially compared to JavaScript.

Re: Crystal: Fast as C, Slick as Ruby

#355

Post by pjmlp »

wott wrote: post #184
bluetomcat wrote: post #67

Earlier quoted context omitted.

All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as muc…

> All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as m…

I bet C# is using Mono.

Re: Crystal: Fast as C, Slick as Ruby

#356

Post by smnplk »

banachtarski wrote: post #329
kminehart wrote: post #306

Earlier quoted context omitted.

Of course. I've used C pretty extensively, Java enough to hate it, and C#. I consider myself a javascript developer because that's what I've done my best work in and that's what I enjoy the most.

He said decent type system, not static one.

How can someone enjoy javascript ? Even closures are not done right and now they added classes. Just what we need sigh

Re: Crystal: Fast as C, Slick as Ruby

#357

Post by catnaroek »

asterite wrote: post #343
catnaroek wrote: post #319

Earlier quoted context omitted.

Well, that's even worse. Whole-program compilation has positive aspects to it, like enabling more aggressive optimizations, but it should be strictly opt-in. For future reference: The easiest way to reply to a message that doesn't have a “reply” link below, is to click on the “X minutes ago” link above.

Thank you! I didn't know that easy way to reply. The compiler does some incremental compilation for the generated object files, so compile times are kept relatively small. Other than that, I don't think it makes a big difference for a developer except saving compile times. On the other hand, in this way you can't have a compiled library conflict so you have to "clean and rebuild" when this happens. For example in Rub…

Incremental compilation isn't a good alternative to actually separate compilation. If I implement a module Foo that depends on another module Bar, the only information I need is the interface Bar exposes, so I shouldn't have to wait until Bar is actually implemented to begin implementing Foo.

Re: Crystal: Fast as C, Slick as Ruby

#358

Post by bunderbunder »

dikaiosune wrote: post #300
pjmlp wrote: post #290

Earlier quoted context omitted.

The C++ advantage will not be so much after Java 10 comes out and finally have the value types and reified generics the language should have had since beginning. Also I am yet to see any large scale production deployment of those Hadoop alternatives. But it might still be like 5 years from now, so who knows how it will evolve.

Re: deployments, I expect that would take some time for a transition to occur. The first post date on the ScyllaDB blog is from February 2015 ( http://www.scylladb.com/2015/02/20/seastar/ ), and it looks like it wasn't until September 2015 that they specifically started publishing benchmarks of the database itself as opposed to the network I/O library they built for it ( http://www.scylladb.com/2015/09/22/watching_sc…

From what I've seen, stack based value types are not necessarily the big performance win they're touted to be. The rule of thumb I've noticed is that, if the struct is much bigger than the size of a pointer, you start seeing a pattern where it's quicker to allocate in the first place but slower to pass around.

I think this is because, on a platform like Java or .NET that uses generational garbage collection, the heap starts to behave like a stack in a lot of ways. Allocations are fast, since you just put objects at the top of the heap. And then, since they're at the top of the heap, they tend to stay in the cache where access is fast, so pointer chasing doesn't end up being such a big deal. On the other hand, if you use a struct, every time you pass or return it you end up creating a shallow copy of the data structure instead just passing a single pointer.

(Disclaimer: preceding comment is very speculative.)

Re: Crystal: Fast as C, Slick as Ruby

#359

Post by transfire »

wott wrote: post #184
bluetomcat wrote: post #67

Earlier quoted context omitted.

All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as muc…

> All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as m…

I don't think your list is quite right. Crystal is probably more on the tier of Go. Julia is also much faster than that, at least up there at TCL. Of course both vary a great deal depending on what you are using for.
Post reply on HN