Anybody Tried the Crystal Programming Language (Machine-Code Compiled Ruby)

Anybody tried the Crystal Programming Language (machine-code compiled Ruby)?

I'm the developer of crystal. Currently not everything is implemented from the bulleted point list. In fact classes were just started to be implemented.

I really like the idea of it though. But I need to think more about how to implement it. And I also need more time, hehe.

The second article has a completely different approach because it won't introduce a new language: it'll just try to compile a subset of Ruby, or maybe will be compiled to native code but still allow some dynamism with performance costs (I talked to the author of that article some months ago).

My feeling toward both approaches: I really with it could happen. We need a fast language with an elegant, readable, joy to use syntax and library (like what Ruby offers).

D Programming Language in the real world?

I'm using D for my research work in the area of computer graphics. I and others have had papers published in our fields based on work done using D. I think it's definitely ready for use on small to medium sized research projects where performance matters. It's a nice fit for research work because often you're starting from scratch anyway, so you don't have much legacy code to worry about integrating with.

Another popular area for use seems to be web services. Hopefully someone else can comment who's in this space, but there too I think the idea is that performance often really matters so you want a compiled-to-the-metal language. Services are often fairly small, self-contained processes, so interop with large amounts of legacy C++ code is not really necessary or useful. Thus D can get its foot in the door.

I think D will continue to gain grass-roots followers in this way -- on smaller projects that for whatever reason can afford to ditch the C++ legacy in order to gain a programming language that's much more enjoyable to use, and perhaps more productive too.

But until there's a huge number of grass-roots users there won't be much in the way of big corporate users I suspect.

Compile Ruby with its C API

A couple of good articles on this topic:

• http://whitequark.org/blog/2011/12/21/statically-compiled-ruby/
• a bit dated... http://macournoyer.com/blog/2008/12/09/orange/

Also have you heard of Crystal? While not truly Ruby, it looks interesting:

Crystal is a programming language with the following goals:

• Have the same syntax as Ruby, or at least as similar as possible.
• Never have to specify the type of a variable or method argument.
• Be able to call C code by writing bindings to it in Crystal.
• Have compile-time evaluation and generation of code, to avoid boilerplate code.
• Compile to efficient native code.

about it on SO: Anybody tried the Crystal Programming Language (machine-code compiled Ruby)?

And another (commercial) project with the same purposes but mainly targeted at embedded development: http://foundry-lang.org/

Why is C so fast, and why aren't other languages as fast or faster?

There isn't much that's special about C. That's one of the reasons why it's fast.

Newer languages which have support for garbage collection, dynamic typing and other facilities which make it easier for the programmer to write programs.

The catch is, there is additional processing overhead which will degrade the performance of the application. C doesn't have any of that, which means that there is no overhead, but that means that the programmer needs to be able to allocate memory and free them to prevent memory leaks, and must deal with static typing of variables.

That said, many languages and platforms, such as Java (with its Java Virtual Machine) and .NET (with its Common Language Runtime) have improved performance over the years with advents such as just-in-time compilation which produces native machine code from bytecode to achieve higher performance.

What is the worst programming language you ever worked with?

PHP (In no particular order)

• Inconsistent function names and argument orders
  
  • Because there are a zillion functions, each one of which seems to use a different naming convention and argument order. "Lets see... is it foo_bar or foobar or fooBar... and is it needle, haystack or haystack, needle?" The PHP string functions are a perfect example of this. Half of them use str_foo and the other half use strfoo.
• Non-standard date format characters
  
  • Take j for example
    
    
    • In UNIX (which, by the way, is what everyone else uses as a guide for date string formats) %j returns the day of the year with leading zeros.
    • In PHP's date function j returns the day of the month without leading zeros.
• Still No Support for Apache 2.0 MPM
  
  • It's not recommended.
  • Why isn't this supported? "When you make the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, feet of clay are introduced into PHP's system." Link So... it's not supported 'cause it makes things harder? 'Cause only the things that are easy are worth doing right? (To be fair, as Emil H pointed out, this is generally attributed to bad 3rd-party libs not being thread-safe, whereas the core of PHP is.)
• No native Unicode support
  
  • Native Unicode support is slated for PHP6
  • I'm sure glad that we haven't lived in a global environment where we might have need to speak to people in other languages for the past, oh 18 years. Oh wait. (To be fair, the fact that everything doesn't use Unicode in this day and age really annoys me. My point is I shouldn't have to do any extra work to make Unicode happen. This isn't only a PHP problem.)

I have other beefs with the language. These are just some.
Jeff Atwood has an old post about why PHP sucks. He also says it doesn't matter. I don't agree but there we are.

---

Related Topics