Crystal: Fast as C, Slick as Ruby • Hacker News Board

Re: Crystal: Fast as C, Slick as Ruby

#221

Post by wbl » Thu, Aug 04, 2016, 2:03 PM UTC

CyberDildonics wrote: post #190

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…

If you write programs with a gc there is always a level which you can't get your hands on to change. If you want to create a piece of a puzzle that is tiny, does one thing, and does it right, like a shared library, a command, a linkable object, or any tiny standalone binary, the gc is always a thorn. Anything where memory or interactivity needs to be tightly controlled is problematic with a gc. Not only that, but a g…

Except that garbage collected languages generally use per-thread nurseries, so the fast path is a small number of instructions. Having a GC also makes lock-free programming easier.

Re: Crystal: Fast as C, Slick as Ruby

#222

Post by exDM69 » Thu, Aug 04, 2016, 2:04 PM UTC

pathsjs wrote: post #193

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…

Nim fits everything you ask, except for "can target GPUs via LLVM or SPIR-V". Even that may eventually be fixed by having OpenCL C as a compilation target. Also, I am not sure what you mean by "first class SIMD structures", but you can definitely have a single definition for sin4f and sin8f if they are line by line equal except types, by using union types.

Nim is definitely on my short list of languages to learn, however...

Targetting GPUs is a deal-breaker. I'm sure the Nim compiler would be pretty easy to retarget to GPUs via SPIR-V (the new binary IR for Vulkan/OpenCL shaders and kernels) or OpenCL/CUDA C. But I don't think that would work for Nim's runtime system or existing Nim libraries (including any standard libs it has).

Also Nim's pauseless low latency automatic memory management (I guess you can call it a "GC") is very interesting but it's not what I'm after.

> Also, I am not sure what you mean by "first class SIMD structures",

I mean this:

    def multiply_and_add(a : , b : , c : ) :  {
        return (a*b) + c;
        // TODO: figure out how to use "madd" from FMA4 or NEON instruction set
    }

The trivial piece of code above should be "generic" so that it can be called with any width of vector.

Now the example above is very trivial but more complex examples might have challenges for correct implementation of the type checker. In particular, doing vector shuffles (ie. equivalent __builtin_shufflevector in GCC/Clang vector extensions) would need to have a strange type. Shader languages typically use a syntax like `myvector.wxzy`, which might work.

This might perhaps be possible with an ungodly mess of C++ templates and explicit template specialization for each vector type (and hoping that the compiler is aggressive enough in inlining). But I'm not really a fan of template-heavy C++.

In fact, the kind of solution I've been thinking about would be semantically similar to what I'd do with C++ templates.

> but you can definitely have a single definition for sin4f and sin8f if they are line by line equal except types, by using union types.

I'm not familiar enough with Nim's union types to be sure, but my guess is that this would not compile to efficient low level code apart from the most trivial of circumstances. This is my (not very) educated guess based on other high level languages with some concept of union types.

Anyway, Nim is a very cool language that I will check out sometime in the near future. It just isn't what I'm looking for my very specific use case.

Re: Crystal: Fast as C, Slick as Ruby

#223

Post by ericfrederich » Thu, Aug 04, 2016, 2:04 PM UTC

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…

wow... have never heard of that partial case sensitivity before.

I think this goes beyond syntactic sugar. Holding the hand of the developer too much?

Personally, as a Python programmer I like interfacing with C++ code like Qt via PyQt. If I see a camelCase method I know where it came from, but if I see a PEP-8 style name or method I know it's our own code, not from Qt.

Re: Crystal: Fast as C, Slick as Ruby

#224

Post by _uhtu » Thu, Aug 04, 2016, 2:05 PM UTC

sdogruyol wrote: post #77

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

These are really nice questions / concerns. - Firstly, we are a Ruby shop and most of the time the errors are pretty self descriptive that we can easily solve. Also the IRC/Gitter room is full of helpful people that you can get instant feedback about any issue (even a compiler bug). Note that we're not afraid of writing code :) - I've updated our application once in the last 6 months. It's only a minor change for add…

Thanks for answering!

I feel like Crystal is one of the best projects out there but it's not getting much attention. What do you think it will take to get people to start writing projects and contributing?

IMO the number one thing will be to start getting as many articles like this out as possible, and go beyond that. TodoMVC/Yelp Clone tutorials would go a LONG way I think, especially since a lot of people will just fork those projects to mess around in them.

Re: Crystal: Fast as C, Slick as Ruby

#225

Post by paulddraper » Thu, Aug 04, 2016, 2:06 PM UTC

ynniv wrote: post #218

paulddraper wrote: post #213

Earlier quoted context omitted.

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.

And you can do it because someone found that it was necessary to do.

It's crazy I can't tell Java and NodeJS "use the memory you need". Instead I have to specify max memory sizes (and then watch as they inevitably consume all of it).

Re: Crystal: Fast as C, Slick as Ruby

#226

Post by _uhtu » Thu, Aug 04, 2016, 2:07 PM UTC

RX14 wrote: post #172

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

Just to add on that breaking changes are always compile errors, with a nice description of what you need to do to fix it, which makes the breaking changes a lot more manageable.

That's good! It's always frustrating trying to find a breaking change in an interpreted language, so I can imagine it would be much easier in Crystal.

Re: Crystal: Fast as C, Slick as Ruby

#227

Post by _uhtu » Thu, Aug 04, 2016, 2:09 PM UTC

sdogruyol wrote: post #160

jalopy wrote: post #155

Great stuff. I love Ruby. Any idea when this will be production worthy, or at least stable enough to trust on internal projects? Will the language change much going forward?

Actually it's been stable for the last 6 months. No more expected major syntax e.g changes upwards. (apart from parallelism and gc which will be at compiler)

They should really mention that on the website for crystal. I think a lot of people are scared off by seeing the words alpha and breaking changes. Changing those to "beta" and "stable" on the site would help a lot IMO. At the very least calling it stable would be huge.

Re: Crystal: Fast as C, Slick as Ruby

#228

Post by vosper » Thu, Aug 04, 2016, 2:11 PM UTC

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

Sometimes GCs require a lot of tuning, but I'd bet that 90% of software written in GC'd languages works just fine, without touching the GC settings.

In my limited experience writing performance-critical Python code the improvements always came from choosing better libraries (eg for faster serializations) or improving our own code. The GC never showed up in profiling as an issue for us.

Re: Crystal: Fast as C, Slick as Ruby

#229

Post by rogerdpack » Thu, Aug 04, 2016, 2:11 PM UTC

JohnStrange wrote: post #185

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…

I have no problem with GC, but I want to see reasonably complicated benchmarks that actually show that it's "fast as C". Because I don't believe that at all.

Are you saying the GC is as fast as C? I bet it's not. That being said, the programs I've built in crystal "feel" very fast, here are a few random performance tests, if you're asking about overall performance:

https://groups.google.com/forum/?fromgroups#!topic/crystal-l...

https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html

Re: Crystal: Fast as C, Slick as Ruby

#230

Post by untothebreach » Thu, Aug 04, 2016, 2:13 PM UTC

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…

I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.