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

241–250 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#241

Post by mshenfield »

twblalock wrote: post #133
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.

My intuition is also that a Crystal REPL is technically possible. But FTR, the two languages implement subtly different type restrictions.

Scala has type inference, Crystal has optional typing. In Scala, there are certain situations when the type is discernible by the compiler, and can be omitted. For example

  val x = 1 + 2 + 3
the compiler infers that x is an Integer. However, omitting type information in Scala is the exception not the rule. Methods and functions, for example, must have type annotations.

In practice, Crystal also infers type. But in Crystal you can omit almost any type annotation, including method and function definition. This probably poses a different challenge for the compiler authors. The Type Restrictions sections provides some more examples https://crystal-lang.org/docs/syntax_and_semantics/type_rest...

Re: Crystal: Fast as C, Slick as Ruby

#242

Post by rogerdpack »

makufiru wrote: post #98
dx034 wrote: post #97

Earlier quoted context omitted.

This is not what I experienced so far. I use Golang on both Linux and Windows (50/50) and I didn't have any problems. What are you referring to exactly?

As I said, YMMV but the biggest standout that I remember was trying to play sounds using the windows API. There weren't any packages our team could find that really did it correctly, the one that everyone pointed to leaked memory like crazy and it was hard for us to track down since it relied on bouncing back and forth between C and Go so frequently (making malloc/free lifetimes difficult to follow because C can't kn…

sounds more like the ecosystem for windows support is slow. Or were there some stdlib's useful for it in go on linux?

Re: Crystal: Fast as C, Slick as Ruby

#243

Post by rogerdpack »

z3t4 wrote: post #89

scoped includes are a deal breaker for me when looking at new programming languages. ex: non-scoped (everything in foo is added to the global scope) inport foo { bar.do() } ex: scoped (everything in foo is added to the local scope, and assigned a name-space) { bar = inport foo bar.do() } I find it much easier to manage programs where there are no "hidden" global variables. It's especially hard when the included files…

bring it up on the mailing list, seems like an interesting feature to me :)

Re: Crystal: Fast as C, Slick as Ruby

#246

Post by CyberDildonics »

exDM69 wrote: post #214
CyberDildonics wrote: post #205

Earlier quoted context omitted.

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 explici…

How would you use specific instructions yet have widths abstracted?

ISPC actually has some preliminary support for targeting Nvidia PTX btw. It compiles using LLVM.

Re: Crystal: Fast as C, Slick as Ruby

#247

Post by rogerdpack »

wtbob wrote: post #180

> Have you ever dreamed of a programming language as beautiful as Ruby but as fast as C? Yeah, I discovered Common Lisp back in 2006 and have been using it ever since … I discovered Go back in 2009 and have been using it ever since, too. What does Crystal get me that these two don't?

ruby like syntax that I miss when using go :|

Re: Crystal: Fast as C, Slick as Ruby

#248

Post by [deleted] »

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…

[deleted]

Re: Crystal: Fast as C, Slick as Ruby

#249

Post by p0nce »

jjnoakes wrote: post #207
p0nce wrote: post #191

Earlier quoted context omitted.

> On the theoretical side, not reasoning about ownership means sharing data betweent threads is done with copies (slower) or locking (slower and error prone); if you know about ownership you can share references to data while it can't be mutated for free. I don't think it follows and it's rather the reverse: it what I share has a global owner (ie. the GC), I don't have to lock or copy by definition: once it stops bei…

> if what I share has a global owner (ie. the GC), I don't have to lock or copy by definition Then how you do avoid data races? Two shared references which can mutate your shared data requires either a copy, a lock, immutability, or a single writer.

I use "parallel foreach", sometimes worker queues, implicit single writer... like in C++. It sounds like you think only Rust-style ownership can avoid data-races. Sure, if you want the type system to do it. For me discipline is enough and I've seen it work in teams too. Not seeing such a problem really.

Re: Crystal: Fast as C, Slick as Ruby

#250

Post by ocean3 »

StavrosK wrote: post #169
rdtsc wrote: post #36

Earlier quoted context omitted.

> that if it wasn't FOSS I'd have decided it's being astroturfed. That's a good sign! You know why? Because it has a great community and is very friendly for new comers. Jose, Eric and the rest of the team made that a priority and it shows. It doesn't just mean being nice on IRC, it also means putting usability first, putting more effort in how example looks, how documentation looks and so on. If Google invented a la…

"Friendly for newcomers"? I tried to write something the other day, and had an Erlang developer friend to help me. The Elixir docs section just says "buy one of these books to get started", which is completely unacceptable, and we (mostly my friend, as I had no idea what anything is) spent an hour trying to figure out how to run a node, with Google not providing any useful answers. That's as hostile to newcomers as i…

Elixir has good starting guide. I was able to easily pick up reading from it. Book are further resources to learn.
Post reply on HN