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

271–280 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#271

Post by adrusi »

valarauca1 wrote: post #216
def- wrote: post #119

Earlier quoted context omitted.

> 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

If you're consistent about how you space your infix operators, this will have no impact on your code.

If you put space around some operators and not around others, in a way that doesn't correspond to precedence, you're going to confuse anyone who reads your code, in any language.

Re: Crystal: Fast as C, Slick as Ruby

#272

Post by exDM69 »

CyberDildonics wrote: post #246
exDM69 wrote: post #214

Earlier quoted context omitted.

> 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.

See example above in this thread. In C + GCC vector extensions, I just use normal arithmetic operations (+, -, *, /).

However, when using specific intrinsics they are for a specific width. It might take some "library code" to take advantage of some instructions like dot products, etc.

Re: Crystal: Fast as C, Slick as Ruby

#273

Post by jbbarth »

jheriko wrote: post #199

cool. can you make it faster than C though please? (seriously) i think it might even happen by accident in some cases already though. the places where C can be beaten for performance are, in my experience, from design choices in the C standards, users not understanding or leveraging those things for performance and the architecture of the compilation-unit/link process. things like the struct layout rules - instead of…

Not the answer you would expect but still: it can also happen on large projects where the refactoring or the paradigm change is just too costly in C. The pure, raw ability to make C faster is nice, but if it takes you months of development you don't have, it's pretty useless.

One typical example of this was a few years ago (if I'm not mistaken) in the monitoring world, when Shinken released a Nagios-compatible engine in Python, and, basically the reactions in the Nagios community was that the modifications involved in Nagios (C) were just too important to be worth it.

Re: Crystal: Fast as C, Slick as Ruby

#274

Post by duaneb »

clouddrover wrote: post #131
duaneb wrote: post #57

Earlier quoted context omitted.

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

I actually had assumed it was cross platform but there was no reason to use it.

I certainly wouldn't invest my code anywhere near Apple unless that was also my market. Who knows what direction it's moving, aside from in Apple's interest. I'll stick with rust and go: between the two I get everything but easy objective c interop.

Plus, their design decisions with respect to null ability is... Interesting. It's gonna feel gimped by legacy needs for a long time.

Re: Crystal: Fast as C, Slick as Ruby

#275

Post by naviix »

kristianp wrote: post #54
Svenskunganka wrote: post #15

I'd like to put out there that Crystal is absolutely awesome. The language itself is Crystal clear, but the language documentation and API documentation - oh my! I had never worked with compiled languages before I tried Crystal, but had always had a huge interest in getting into that. When I wanted to learn the compiled ecosystem I looked at languages like Go and Rust, but the learning curve for those was a bit overw…

Maybe the makers of Crystal need to take a leaf out of Go's book. Despite the Go creators not being windows users (AFAIK), they support Windows as a primary target, to help adoption, I assume. Of course the Crystal people probably don't have the same number of developers working on it as Go did even early on. Edit: Go took a little while to support windows, not until around July 2010. See this question from November…

not to take away from the point you're trying to make, but i just installed it on windows 10 with the latest update that included bash. felt nice.

Re: Crystal: Fast as C, Slick as Ruby

#276

Post by pmelendez »

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

"GCs are complex and require lots of end-user tuning --"

And they tend to be very memory hungry. Often, the memory overhead is the difference between running a program or having a bunch of browser's tabs open.

Re: Crystal: Fast as C, Slick as Ruby

#277

Post by hetman »

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…

All the benchmarks you posted suggest that Rust is faster than Nim, not the other way around. Did you have something else in mind?

Re: Crystal: Fast as C, Slick as Ruby

#278

Post by RX14 »

pmelendez wrote: post #276
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

"GCs are complex and require lots of end-user tuning --" And they tend to be very memory hungry. Often, the memory overhead is the difference between running a program or having a bunch of browser's tabs open.

The GCs used in go or crystal tend not to eat memory more than 10% more than the peak memory of a c implementation. The perception of GC == hundreds of MBs of memory usage comes from java, where the GC aggressively preallocates, and has the memory baggage of a whole vm too. I rarely see crystal or go programs use excesses of memory.

Re: Crystal: Fast as C, Slick as Ruby

#279

Post by hetman »

wott wrote: post #184
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…

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

I'm curious where Rust fits in on your hierarchy with their emphasis on "zero cost abstractions". Of course that's more a lofty ideal than reality but it means that at least in some cases it does much better than C++. Is it a long program? Something that could be posted in a Github Gist maybe?

Re: Crystal: Fast as C, Slick as Ruby

#280

Post by tanlermin »

exDM69 wrote: post #164
bluetomcat wrote: post #136

Earlier quoted context omitted.

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

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…

Julia has all these things
Post reply on HN