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

311–320 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#311

Post by catnaroek »

asterite wrote: post #308
catnaroek wrote: post #82

Earlier quoted context omitted.

> The abstract class defines which methods every class that inherits from it must define by using abstract methods. In their example, the type checker can infer that Animal has a `talk` method, even if it's never explicitly defined: abstract class Animal # no talk method here! end class Dog In their own words, “Now the code compiles:” john.pet.talk #=> "Woof!" Now, what happens if, in a separate module , I define a S…

It will simply stop compiling the code and it will say "undefined method 'talk' for Snake". You will get a similar error if `talk` is defined as an abstract method in the base abstract class. So abstract methods are just a standard way to document this and to improve error messages. There's no safety hole here.

So the behavior of a subclass of an abstract class depends on whether both classes are defined in the same module or in different ones:

(0) If Snake is in the same module as Animal, the error is that “john.pet.talk” is a call to a nonexistent method.

(1) If Snake is in a different module from Animal, the errors is that Snake doesn't have a talk method.

This isn't nice.

Re: Crystal: Fast as C, Slick as Ruby

#312

Post by bluejekyll »

anp wrote: post #262
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…

> But most likely - you simply do not need a language without a GC. Absolutely. That doesn't mean I can't want predictable performance or deterministic destruction. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up (i.e. on the overhead of managed runtimes and GCs). Before, I'd have argued that it was just necessary. Having spent a bunch of time…

> That doesn't mean I can't want predictable performance or deterministic destruction.

Exactly. To just add to your point, there is no longer a reason to settle for GC pauses with Rust. It does require more thought while writing the code, but what you gain is a firmly consistent runtime. If your memory allocation is slow, you can create your own allocator/slab, and then use that for hot memory space and optimize it out.

As a longtime Java geek who never understood the argument against GC, this has been a mind altering experience. I was a big C++ person before, but after one too many memory leaks and segfaults, I could never imagine not wanting a GC. Then Rust came along and taught me better.

Re: Crystal: Fast as C, Slick as Ruby

#313

Post by uptownfunk »

koffiezet wrote: post #196
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…

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

Re: Crystal: Fast as C, Slick as Ruby

#314

Post by ekzy »

mshenfield wrote: post #60

Crystal doesn't support a REPL yet because inferred static typing complicates incremental compilation. Blog: https://crystal-lang.org/2014/12/06/another-language.html Github Issue: https://github.com/crystal-lang/crystal/issues/681

here is an implementation https://github.com/greyblake/crystal-icr

Re: Crystal: Fast as C, Slick as Ruby

#315

Post by wtetzner »

paulddraper wrote: post #225
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.

And you can do it because someone found that it was necessary to do. It's crazy I can't tell Java and NodeJS "use the memory you need". Instead I have to specify max memory sizes (and then watch as they inevitably consume all of it).

Of course they will consume all of it. That's how GCs typically work. They won't invoke a collection until there's no space left to allocate. Just because they "use all of it" doesn't mean all of that memory is actually live. It just hasn't done a collection yet.

Re: Crystal: Fast as C, Slick as Ruby

#316

Post by asterite »

catnaroek wrote: post #82
Svenskunganka wrote: post #78

Earlier quoted context omitted.

> In the Animal/Dog/Cat example, what happens if, in a separate module, if define a Snake class that doesn't have a `talk` method? There are several possibilities, sadly all pretty bad The abstract class defines which methods every class that inherits from it must define by using abstract methods. If you write a class that inherits from an abstract class, and you do not define a method that the abstract class says th…

> The abstract class defines which methods every class that inherits from it must define by using abstract methods. In their example, the type checker can infer that Animal has a `talk` method, even if it's never explicitly defined: abstract class Animal # no talk method here! end class Dog In their own words, “Now the code compiles:” john.pet.talk #=> "Woof!" Now, what happens if, in a separate module , I define a S…

I can't seem to reply to your reply to this, but the error message has nothing to do with where a class is defined.

You can't compile a part of your application in crystal, there are no linked crystal libraries. You compile your whole app, will all class definitions. The compiler then will have all the type information to know if a method is missing in a subclass, when that method is used from a parent class.

Re: Crystal: Fast as C, Slick as Ruby

#317

Post by happyslobro »

renox wrote: post #256
paulddraper wrote: post #225

Earlier quoted context omitted.

And you can do it because someone found that it was necessary to do. It's crazy I can't tell Java and NodeJS "use the memory you need". Instead I have to specify max memory sizes (and then watch as they inevitably consume all of it).

> 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?

Re: Crystal: Fast as C, Slick as Ruby

#318

Post by bjourne »

ghayes wrote: post #84
thinkpad20 wrote: post #62

Earlier quoted context omitted.

Manual or deterministic memory management might be a must-have for certain usage domains, but for any domain in which one would be using ruby, this seems unlikely, and presumably one could FFI into C when this is the case. There are hardly any languages commonly used in industry which don't have GC (essentially just C/C++). And many of these garbage-collected languages are capable of blazingly fast code with a small…

One of the largest areas of concern is for real-time systems (systems which fail if they do not respond within some small time threshold). Most GC involves stopping the world to perform the GC which can pause your program's execution for some number of milliseconds. If GC pauses exceed your real-time requirements, you're out of luck. Some languages, like erlang, do slightly better by garbage collecting erlang process…

Any program running on any non-realtime OS can stop for any number of milliseconds. There are a billion reasons for such interruptions like other processes wanting to run, cleanup phases internal to the OS, memory paging...

If your program stops for 50 ms, do you really care if it was because of a GC cycle or something else? If you really do care, then you are not allowed to target Linux, Windows or OS X all of which are decidedly not real time operating systems.

Re: Crystal: Fast as C, Slick as Ruby

#319

Post by catnaroek »

asterite wrote: post #316
catnaroek wrote: post #82

Earlier quoted context omitted.

> The abstract class defines which methods every class that inherits from it must define by using abstract methods. In their example, the type checker can infer that Animal has a `talk` method, even if it's never explicitly defined: abstract class Animal # no talk method here! end class Dog In their own words, “Now the code compiles:” john.pet.talk #=> "Woof!" Now, what happens if, in a separate module , I define a S…

I can't seem to reply to your reply to this, but the error message has nothing to do with where a class is defined. You can't compile a part of your application in crystal, there are no linked crystal libraries. You compile your whole app, will all class definitions. The compiler then will have all the type information to know if a method is missing in a subclass, when that method is used from a parent class.

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.

Re: Crystal: Fast as C, Slick as Ruby

#320

Post by ethagnawl »

erez wrote: post #100

First thing I look for whenever I run across another "C competitor" is to look which language it is implemented in. Usually that's C, or C++, but this time, it does look like Crystal is implemented in Crystal, which is, to me, a very good indication that this is a "real" system language. I believe Rust is also implemented in Rust and Go, after a few years of being implemented in C has now a compiler written in Go.

> ... which is, to me, a very good indication that this is a "real" system language.

Could you expound upon that point a bit? What's the difference, in your mind?

Post reply on HN