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

211–220 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#211

Post by kminehart »

krzat wrote: post #112
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…

People want non-GC language because everyone already has GC language that their are comfortable with. So basically C/C++ replacement is the only niche that is left to fill. It would be even better if new language could replace even GC-languages, so I can can write fast low level libraries or websites in single language, without sacrificing productivity. That would be the Holy Grail I guess.

On the other hand, Go has an excellent garbage collector, and really seems to fill the niche for low-level libraries and programs.

It's also quite a joy to program in, and I'm a JavaScript developer, so I'm coming from the other side of the spectrum.

Re: Crystal: Fast as C, Slick as Ruby

#212

Post by paxcoder »

exDM69 wrote: post #168
welder wrote: post #79

Stopped reading when I saw the `end` keyword... the most annoying part of Ruby. Edit: I'm getting hella downvoted but I'm leaving this here. Ruby fanboys can't silence me!!! ;)

The syntax of a language is about the least interesting thing about them. I don't care about curly braces, end keywords or semicolons as long as it is consistent (and fairly easy to parse, so there can be good tooling). The interesting parts are in the semantics, type systems and runtime features. Choosing a programming language based on the syntax is like choosing your significant other based on looks alone. You're…

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.

Re: Crystal: Fast as C, Slick as Ruby

#213

Post by paulddraper »

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…

GCs are complex and require lots of end-user tuning -- just look at the performance articles on Java.

Beyond that, however, there are many uses for ownership beyond controlling memory resources. Closing a TCP connection, releasing a OpenGL texture...there are lots of applications of having life cycles built in to the code rather than the runtime.

EDIT: fixed typo

Re: Crystal: Fast as C, Slick as Ruby

#214

Post by exDM69 »

CyberDildonics wrote: post #205
exDM69 wrote: post #164

Earlier quoted context omitted.

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've almost described ISPC verbatim. If you don't already know about it you might want to check it out. http://ispc.github.io/index.html It doesn't compile to a native executable, but since it produces .o files you should be able to just set your entry point and go from there.

> You've almost described ISPC verbatim.

Thanks, I've read about it before, but haven't spent too much time looking at it.

However, this "single program, multiple data" isn't exactly what I'm looking for (it would solve the sin4f vs. sin8f issue mentioned above, though). I need explicit, low level access to SIMD, coupled with genericity over vector widths. This means doing almost assembly-style SIMD code with explicit shuffles, blending, etc as well as access to intrinsics where needed.

I also need portability (ispc is from Intel, it probably doesn't support ARM NEON) and targetting GPUs.

I'm very well aware that my needs are very specific. I need to do math stuff for 3d graphics and physics applications.

All I need is for a lot of free time to appear from out of nowhere and I can write a prototype compiler for this myself :)

Re: Crystal: Fast as C, Slick as Ruby

#215

Post by xutopia »

lmm wrote: post #149
clessg wrote: post #4

Looks very nice. I hope it gains momentum. For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked more over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum. If you want some idea of…

Is Elixir actually any more mainstream/momentum-having than Crystal? I'd be more inclined to point people to e.g. OCaml.

Crystal aims to replace Ruby but at Railsconf and Ruby meetups I go to Elixir/Pheonix is mentioned 100x more than Crystal is.

Re: Crystal: Fast as C, Slick as Ruby

#216

Post by valarauca1 »

def- wrote: post #119
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…

> 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

Re: Crystal: Fast as C, Slick as Ruby

#217

Post by pjmlp »

exDM69 wrote: post #182
pjmlp wrote: post #175

Earlier quoted context omitted.

It is very hard to have a general purpose GC library, because the best GC algorithms require a tight cooperation between compiler, GC and language semantics. For me, the only viable alternative to GC are substructural type systems like in Rust's case.

You're definitely right and it's not an easy task. However, I think there's a sweet spot where you could implement a fairly nice boilerplate/framework that would be an 80% solution to the problem which would be a vast improvement over the current state. The missing 20% would be language specifics and that would be either solved by forking the boilerplate code or writing some kind of callbacks for discovering referenc…

You should check projects like the The Mu Micro Virtual Machine and Eclipse OMR

http://microvm.github.io/

http://projects.eclipse.org/projects/technology.omr

The guys behind The Mu Micro Virtual Machine were the ones that did the L4 OS formal verification.

Eclipse OMR is based on IBM's J9, they are making it language agnostic to support PHP, Python, Ruby and whatever else one can think of.

However they aren't LLVM based and the caveats of a generic GC do still apply.

I also agree with you, the problem is how much those 20% actually are in terms of effort.

EDIT: typo where => were, on => one

Re: Crystal: Fast as C, Slick as Ruby

#218

Post by ynniv »

paulddraper wrote: post #213
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…

GCs are complex and require lots of end-user tuning -- just look at the performance articles on Java. Beyond that, however, there are many uses for ownership beyond controlling memory resources. Closing a TCP connection, releasing a OpenGL texture...there are lots of applications of having life cycles built in to the code rather than the runtime. EDIT: fixed typo

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.

Re: Crystal: Fast as C, Slick as Ruby

#219

Post by _uhtu »

djur wrote: post #94
_uhtu wrote: post #65

Earlier quoted context omitted.

i actually think it's a good example for just that reason. Ruby will automatically use those big number types on production applications as well as the fibonacci application, so it's demonstrating that difference and the effect that it has.

This isn't true. Ruby uses native integers when possible and then switches to bignums when the integer gets big enough.

Yeah and that behavior of automatically switching has overhead, and should be taken into account when comparing languages.

Re: Crystal: Fast as C, Slick as Ruby

#220

Post by _uhtu »

ricardobeat wrote: post #129
_uhtu wrote: post #69

Earlier quoted context omitted.

My biggest concern if i were to try to use Crystal in production would be the lack of "googleability". I'm guessing your team is very familiar with the language, so it's not as much of a problem that you can't Google a problem when it happens. Do you feel that this is a major roadblock for people new to crystal, or are the majority of errors very intuitive? the second thing is that according to the site crystal is in…

Chiming in re. "googleability", go has the same problem (despite coming from Google :D). What you do is always search for 'crystal lang xxx'. It will get better as adoption increases.

I was more just talking about how as language popularity goes up so does your likelihood of finding the solution to any given problem on the internet.
Post reply on HN