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

381–390 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#381

Post by SamReidHughes »

quotemstr wrote: post #301
m_mueller wrote: post #237

Earlier quoted context omitted.

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.

Reference counting also has an unbounded worst case: what if you drop the last reference to a very large graph of objects? Then you free the whole thing, which can take an arbitrarily large amount of time.

You don't have to free the whole thing right away, you (the implementation) can free O(1) things and put the rest on a list to process later.

Re: Crystal: Fast as C, Slick as Ruby

#382

Post by mcosta »

happyslobro wrote: post #317
renox wrote: post #256

Earlier quoted context omitted.

> It's crazy I can't tell Java and NodeJS "use the memory you need". Define the 'memory you need'? You know the computer doesn't have a cristal ball to know what latency vs memory usage trade off you want..

I wonder, could we just tell each JVM instance that it may use all of the memory on the system, and then let the OS kill the first VM that allocates more than the system has to offer? Would this get us the same semantics as those of a native application? Or does the JVM preallocate all of the memory that it is allowed to use?

The JVM allocates at start a portion, takes what it needs whenever it needs until the max, but never releases memory back to the OS. So in a given moment a 6GB vm is a 5GB process but internally is using just 3GB.

Re: Crystal: Fast as C, Slick as Ruby

#383

Post by mcosta »

happyslobro wrote: post #317
renox wrote: post #256

Earlier quoted context omitted.

> It's crazy I can't tell Java and NodeJS "use the memory you need". Define the 'memory you need'? You know the computer doesn't have a cristal ball to know what latency vs memory usage trade off you want..

I wonder, could we just tell each JVM instance that it may use all of the memory on the system, and then let the OS kill the first VM that allocates more than the system has to offer? Would this get us the same semantics as those of a native application? Or does the JVM preallocate all of the memory that it is allowed to use?

A native application on what OS?

Re: Crystal: Fast as C, Slick as Ruby

#384

Post by bdcravens »

welder wrote: post #281
paxcoder wrote: post #212

Earlier quoted context omitted.

I've heard this said numerous times, so I'm going to disagree on the record. I think syntax of a programming language is a very important characteristic. A language with a nice syntax is easier to learn, easier to read and understand, and delightful to write. Crystal's syntax is a great differentiator between it and its statically typed, garbage-collecting competition.

Exactly! I guess people used to the Ruby syntax are just desensitized or don't know how much of a joy programming can be without having to type 'end' everywhere.

I think the same could be said about the joy of not having to have perfect whitespace.

Re: Crystal: Fast as C, Slick as Ruby

#385

Post by Narishma »

yoklov wrote: post #263
ynniv wrote: post #218

Earlier quoted context omitted.

just look at hand the performance articles on Java. Just look at the hand performance articles on C... People talk about it because you can do it, not because you have to do it.

Most of the articles I see on C performance tuning are generalizable to any programming language, GC or no. Stuff like maintaining cache coherency, avoiding false sharing for threaded code, etc. I don't write java, but my impression is the articles being talked about are much more java specific than the C ones are (C specific).

Cache locality, not coherency.

Re: Crystal: Fast as C, Slick as Ruby

#386

Post by m_mueller »

quotemstr wrote: post #372
m_mueller wrote: post #305

Earlier quoted context omitted.

The main difference there is: You can control the timing of when to pay that penalty. With a full blown GC, if you run into performance issues because of it, you basically have to rearchtect the whole app (with something like memory pools, which you pay by needing more RAM than strictly necessary and with a vastly more complex code). With ARC I can track down a slow memory operation to a single line of code and deal…

> IMO a full GC is just the wrong level of abstraction for anything that's timing relevant, which includes all UI threads. Hard real-time GC systems exist. In these systems, you can prove that pauses last no longer than a certain number of milliseconds. They're definitely applicable to programs with UI. Can you prove that dropping a reference doesn't free an arbitrarily large number of objects? You can probably convi…

I keep hearing about these, but which of the popular GC languages (read: lots of library support) have real time GC? Aren't we talking about industrial RT applications rather than GUIs?

Re: Crystal: Fast as C, Slick as Ruby

#387

Post by jsmith0295 »

rdtsc wrote: post #327
jsmith0295 wrote: post #264

Earlier quoted context omitted.

Well it does, but it still doesn't do it efficiently. That was the only point I was making. But in general, yes, Elixir/Erlang will handle CPU bound tasks better than node whenever they can be effectively parallelized.

> Well it does, but it still doesn't do it efficiently. Oh interesting. Does it run callbacks on multiple threads? That's new, I haven't followed it for a couple of years.

Well what I meant to say is that both JS and Elixir/Erlang aren't very efficient at using CPU resources. Elixir/Erlang does a better job at compensating for this by being able to run many operations in parallel and across different machines, which isn't something you can easily achieve (or should even attempt) with Node.

Re: Crystal: Fast as C, Slick as Ruby

#388

Post by AstroChimpHam »

yxhuvud wrote: post #140
AstroChimpHam wrote: post #102

So, this is like Ruby's answer to cython?

No, not in any way whatsoever.

Cython looks like typed Python. Crystal looks like typed Ruby. Both are compiled, and both are not quite as fast as C, but much faster than the language they're based off of. The point of both is to be able to write something that looks like a clean scripting language while getting close to the speed of C. Was that unclear, or are you just trolling?

Re: Crystal: Fast as C, Slick as Ruby

#389

Post by SamReidHughes »

catnaroek wrote: post #309
lmm wrote: post #296

Earlier quoted context omitted.

An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time - it's much easier to notice in the first place, and as long as you have one instance of the exception you have a stack trace to start from. And in practice the JVM/standard library throws ConcurrentModificationExecption pretty reliably.

> An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time The fundamental problem still remains, that in neither case can I use the language's semantics to guide the design of my program. > and as long as you have one instance of the exception you have a stack trace to start from Oh, really? How am I supposed to find what the problem is in the gener…

I think a stack trace and an exception would help most people with a modicum of debugging skills.

Re: Crystal: Fast as C, Slick as Ruby

#390

Post by catnaroek »

SamReidHughes wrote: post #389
catnaroek wrote: post #309

Earlier quoted context omitted.

> An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time The fundamental problem still remains, that in neither case can I use the language's semantics to guide the design of my program. > and as long as you have one instance of the exception you have a stack trace to start from Oh, really? How am I supposed to find what the problem is in the gener…

I think a stack trace and an exception would help most people with a modicum of debugging skills.

> I think a stack trace and an exception would help most people with a modicum of debugging skills.

What if the error is difficult to reproduce in the first place? This isn't too uncommon in concurrent programming.

Post reply on HN