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

131–140 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#131

Post by clouddrover »

duaneb wrote: post #57
acangiano wrote: post #24

Earlier quoted context omitted.

Elixir is not a fast language. Not even close. Yes, it handles concurrency and parallelism beautifully which in turn enable distributed applications to perform quite well. But the language itself is significantly slower than Crystal / Rust / Go / Swift. It's not in the same category at all. That said, it's a great language worth recommending.

I'm not sure why you're grouping those four languages as they overlap very little. Go has latency and emphasizes network bound services (and randomly docker for some reason, I'm sure a good one); rust is a c replacement; swift is for writing iOS/Mac apps; and crystal is a newborn. I'd actually call it quite close to go: a high emphasis on concurrency and services. Single thread performance matters much less when scal…

> swift is for writing iOS/Mac apps

I think that's a little simplistic. It's true that it's early days for cross platform Swift but clear progress is being made:

1. https://swift.org/download/

2. https://github.com/SwiftAndroid

3. https://github.com/tinysun212/swift-windows

4. https://swiftforwindows.codeplex.com/

Better cross platform support is a goal of Swift 3.0:

https://github.com/apple/swift-evolution

Re: Crystal: Fast as C, Slick as Ruby

#132

Post by abrookewood »

AstroChimpHam wrote: post #102

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

I don't know why you are getting down voted - the example of Crystal running an existing Ruby file makes it looks like it could be a compiler for unmodified Ruby files. It isn't - it's a separate language - but at first glance that might not be clear.

Re: Crystal: Fast as C, Slick as Ruby

#133

Post by twblalock »

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

Scala has type inference with strong static typing, and a useful REPL. A Crystal REPL should be doable, unless Crystal's creators made some bad choices in the design of the type system that Scala's creators did not.

Re: Crystal: Fast as C, Slick as Ruby

#134

Post by catnaroek »

TickleSteve wrote: post #117
catnaroek wrote: post #75

Earlier quoted context omitted.

> UB is simply the latest stick to hit C with. Honest question, which is the case? (0) You find it easy to determine, by visual inspection, whether a piece of code has undefined behavior. (1) Your coding practices make it difficult to accidentally introduce undefined behavior in the first place. > Same with lack of a GC; this is a plus point for C for most applications, not a negative. Agreed. C addresses use cases f…

Its a combination of both. The vast majority of all code you write will not invoke UB, most people tend to stick to an 'easy' subset of syntax, unlike say C++ where everyone uses a different subset of features making it in effect multiple languages. A combination of testing the known edge cases, wraparound issues, size issues, static analysis and tooling means running into an example of UB is extremely rare in most c…

> The vast majority of all code you write will not invoke UB

That's a bit like saying “the vast majority of the haystack doesn't contain any needles”.

> most people tend to stick to an 'easy' subset of syntax

I'm not sure I understand what you mean. Undefined behavior has nothing to do with syntax. It's strictly a semantic issue.

> It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science.

If I understand correctly, the objection isn't that it's rocket science, but rather that you get little help from your tools if you do it wrong. Memory debuggers will only tell you about memory management bugs that manifest themselves in a particular program run. If a bug will only manifest itself under conditions that are hard to replicate, you're out of luck.

Of course, none of this is an indictment of manual memory management per se, or suggests that garbage collection is a universally good solution. But manual memory management has usability issues, which fortunately being addressed in more modern language designs like Rust.

> If you need dynamic memory allocation, you had damn well better know how to use it properly.

Sure, but are better compile-time diagnostics too much to ask for? Notice that compile time diagnostics don't introduce any runtime performance penalty.

> Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.

No disagreement here.

> so what would normally be UB is actually DB in most cases,

As far as I can tell, the trend among C and C++ compiler writers is to optimize programs very aggressively under the assumption that UB simply will never happen, rather than to turn UB into DB.

> its defined by the compiler and hardware that we're intimately familiar with.

Well, “works on this machine” isn't good enough for most of us.

Re: Crystal: Fast as C, Slick as Ruby

#135

Post by yxhuvud »

fauigerzigerk wrote: post #104
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…

Crystal seems to be targeted at a domain where ruby is not fast enough. That includes domains where GC is a problem. A tracing GC means that you either have to deal with potentially long GC pauses or you need a lot of extra free memory at all times to give the GC time to catch up before running out of memory [1]. Go says it can achieve 10ms max pause time using 20% of your CPU cores provided you give it 100% extra me…

Note though that a lot of the problems with GC in crystal can be worked around by replacing classes with structs. The latter are passed by value and allocated on the stack. There is also access to pointers and manual allocation if that should be needed (though that will end up with roughly the same lack of memory safety as in C) to optimize a hotspot.

Re: Crystal: Fast as C, Slick as Ruby

#136

Post by bluetomcat »

progman wrote: post #85
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…

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…

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

Re: Crystal: Fast as C, Slick as Ruby

#138

Post by Ygg2 »

the_duke wrote: post #130
duaneb wrote: post #52

Earlier quoted context omitted.

Memory management is difficult, extremely difficult, to get correct in the way rust does. I don't think I've seen a leak or bad dereference in years. The only way it really manages this is by tying references into what amounts to a proof assistant. Every simpler method of which I can think either sacrifices capability (e.g. no references at all; only raii + copy on write) or it becomes a GC with all its wonderful tra…

I think you meant -> 'extreymely difficult to get INcorrect in the way rust does'

Unless this is a joke, its meaning is correct, i.e. "proven correct like Rust".

Re: Crystal: Fast as C, Slick as Ruby

#139

Post by Ygg2 »

m_mueller wrote: post #73
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…

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

Reference counting is GC. Simple, but GC.
Post reply on HN