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

361–370 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#361

Post by kminehart »

smnplk wrote: post #356
banachtarski wrote: post #329

Earlier quoted context omitted.

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

I agree, classes are silly in JavaScript. It just masks the prototype and creates ambiguity; using the prototype effectively is part of being a good JavaScript developer.

I understand the hate and everything but honestly I think it presents a fun and refreshing way of solving problems.

Also npm is pretty awesome, aside from how massive the node_modules folder gets.

Re: Crystal: Fast as C, Slick as Ruby

#363

Post by transfire »

yxhuvud wrote: post #88
transfire wrote: post #31

I've done some coding Crystal when I have Ruby scripts I really need to run faster. I generally see about a 5x performance over Ruby. It certainly is great to be able to jump right into Crystal coming from Ruby. It isn't very hard to convert most Ruby code to Crystal -- you just have to go through and "typify" everything. A few methods have different names and of course some don't exist but most of it is there. My on…

You may want to revisit that splat issue. Asterite did some changes regarding splats a few months back that was pretty impressive.

Cool. I'll have to see if I can get my Clik library working now. Thanks.

Re: Crystal: Fast as C, Slick as Ruby

#364

Post by Koshkin »

dikaiosune wrote: post #294
Koshkin wrote: post #293

Earlier quoted context omitted.

The biggest problem with GC, it seems, is some sort of non-determinism that it introduces in the program's behavior. Otherwise, garbage collection, being 'lazy', is, in fact, more efficient way of releasing unused memory compared to how it is usually done in C and, especially, C++, where memory is released 'eagerly' (e.g. as part of the destructor), thus wasting precious machine cycles on something that may not be ev…

> wasting precious machine cycles on something that may not be even necessary at all. I'm not familiar with very many scenarios where one has a garbage collector but doesn't need to free some piece of memory when it's no longer used. Could you clarify what you mean here?

This is true for those compute job types which are mostly 'CPU bound' and which usually create most of the objects that they need at the very beginning; these objects would not be released until the job is finished anyway. I admit that in this case it may take some thought and deliberate effort on the programmer's part to avoid creating many short-lived objects.

Re: Crystal: Fast as C, Slick as Ruby

#366

Post by steveklabnik »

hetman wrote: post #277
progman wrote: post #85

Earlier quoted context omitted.

There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org I am using it for years already, and it is really performant, somewhere between C and Rust. I am still wondering why so few people use it. Benchmark: https://github.com/kostya/benchmarks Nim vs Rust: http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs... Performance discussion: http://forum.nim-lan…

All the benchmarks you posted suggest that Rust is faster than Nim, not the other way around. Did you have something else in mind?

A lot of them did show the other way, then came to Rust people's attention and improvements were submitted. As well as both languages' implementations changing over time.

Re: Crystal: Fast as C, Slick as Ruby

#367

Post by mmargerum »

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…

In the era of cloud computing, memory usage and performance are as important as they have ever been. If you can rent a smaller instance to do the same job that it really money savings.

Re: Crystal: Fast as C, Slick as Ruby

#368

Post by progman »

valarauca1 wrote: post #216
def- wrote: post #119

Earlier quoted context omitted.

> I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No major backer like Google for Go or Mozilla for Rust 2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language 3. Some unique decisions instead of what…

4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12

I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly!

Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim.

All strange special features should be optional, not default.

Re: Crystal: Fast as C, Slick as Ruby

#369

Post by dom96 »

progman wrote: post #368
valarauca1 wrote: post #216

Earlier quoted context omitted.

4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12

I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly! Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim. All strange special features should be optional, not default.

What makes you think this is default? It most certainly is not and will be removed completely in the future.

Edit: here is a source: http://nim-lang.org/docs/manual.html#syntax-strong-spaces ("... if the experimental parser directive #?strongSpaces is used..."). The last time this was discussed I said that it would be removed completely, and I still believe it will be. It's simply not a priority for us right now.

Re: Crystal: Fast as C, Slick as Ruby

#370

Post by mastax »

exDM69 wrote: post #164
bluetomcat wrote: post #136

Earlier quoted context omitted.

Shameless plug: is it considered totally uncool in 2016 for one to be developing a memory-unsafe, manual MM, non-OO, thread-denying language that preserves most of the C semantics? https://github.com/bbu/quaint-lang

No, definitely not! I'd be very interested in a language that is roughly as low level as C, but has some obvious warts "fixed" while still being able to run on bare metal or with a minimal runtime system. I also don't care about a standard lib as long as I can call open(), close(), read(), write(), socket(), etc. Native threads is another requirement for me. Things I'd like to see in a language: - compile to native e…

You might also be interested in Jai [0] which has many of those things but is not a 'real language' yet or possibly ever. Lots of interesting ideas though.

[0]: https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

Post reply on HN