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

371–380 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#371

Post by Scarbutt »

eggy wrote: post #157
Scarbutt wrote: post #58

Earlier quoted context omitted.

I have seen Erlang VM handle 100k requests per second on a distributed cluster A single JVM server can do that load, scaling and providing fault tolerance for a server that just accepts requests is trivial these days, also, if your requests do computationally intensive stuff you are going to have a very bad time with Erlang. It all depends on the problem domain. Exactly, and the domain for Elixir/Erlang is way more n…

LFE (Lisp Flavored Erlang) is a great alternative to Elixir if you prefer Lisp over Ruby syntax. Pony lang is looking to enter the BEAM/OTP arena with its own implementation of supervisors and such. It is actor-based, OOP and is supposedly very fast in the distributed niche.

Since I haven't had use cases for the BEAM/OTP, LFE is definitely what's motivating me to finally dive into the whole erlang ecoystem.

Re: Crystal: Fast as C, Slick as Ruby

#372

Post by quotemstr »

m_mueller wrote: post #305
quotemstr wrote: post #301

Earlier quoted context omitted.

Reference counting also has an unbounded worst case: what if you drop the last reference to a very large graph of objects? Then you free the whole thing, which can take an arbitrarily large amount of time.

The main difference there is: You can control the timing of when to pay that penalty. With a full blown GC, if you run into performance issues because of it, you basically have to rearchtect the whole app (with something like memory pools, which you pay by needing more RAM than strictly necessary and with a vastly more complex code). With ARC I can track down a slow memory operation to a single line of code and deal…

> IMO a full GC is just the wrong level of abstraction for anything that's timing relevant, which includes all UI threads.

Hard real-time GC systems exist. In these systems, you can prove that pauses last no longer than a certain number of milliseconds. They're definitely applicable to programs with UI.

Can you prove that dropping a reference doesn't free an arbitrarily large number of objects? You can probably convince yourself in specific cases for specific programs that you don't see arbitrarily large refcount-release times, but any change you make to the code might invalidate this analysis.

A hard real-time GC stays hard real time.

Re: Crystal: Fast as C, Slick as Ruby

#373

Post by geodel »

rdtsc wrote: post #36
sundarurfriend wrote: post #25

Earlier quoted context omitted.

Elixir gets plugged so often in other-language threads - whether it's Julia or Ruby or, like here, Crystal - that if it wasn't FOSS I'd have decided it's being astroturfed. I guess it's a good thing that people like it so much, but it's really starting to feel marketing-y by now.

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

Yeah, I think Dart is failing and Go is succeeding because of Google backing.

Re: Crystal: Fast as C, Slick as Ruby

#374

Post by progman »

dom96 wrote: post #369
progman wrote: post #368

Earlier quoted context omitted.

I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly! Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim. All strange special features should be optional, not default.

What makes you think this is default? It most certainly is not and will be removed completely in the future. Edit: here is a source: http://nim-lang.org/docs/manual.html#syntax-strong-spaces ("... if the experimental parser directive #?strongSpaces is used..."). The last time this was discussed I said that it would be removed completely, and I still believe it will be. It's simply not a priority for us right now.

> What makes you think this is default?

Some of those features are default in Nim, some (strongspaces) are not. I say that all such weird features should be optional in general so that newcomers don't get scared off.

Also case and underscore should work like in C per default since Nim interoperates with C seamlessly anyway. Case insensitivity and ignoring underscore are ok if optional.

Re: Crystal: Fast as C, Slick as Ruby

#375

Post by jerven »

pjmlp wrote: post #324
bluejekyll wrote: post #307

Earlier quoted context omitted.

Java 10? I'm still waiting for Jigsaw (originally slated for 1.8, is it coming in 1.9???)

No need to wait. https://jdk9.java.net/download/

And Jigsaw has landed, build 116 if I recall (too lazy to look it up)

Re: Crystal: Fast as C, Slick as Ruby

#376

Post by nkurz »

StavrosK wrote: post #337
iamd3vil wrote: post #183

Earlier quoted context omitted.

Elixir has a very good getting started guide[0]. I don't know if you have seen this or not. Even in the learning section, it recommends going through the getting started guide. It mentions other books in other resources. I don't know why you think it's hostile to new comers. I learned Elixir totally from Getting started guide and then the documentation. Then for OTP, I have read an Erlang book to understand it well.…

Jesus... I saw that page. What I didn't see is the "next" link at the very bottom, right above the footer :( There's a whole bunch of stuff I haven't read! That page should be better designed... I think I also skipped the sentence below "running scripts", the one that says "chapter 2", because I skimmed later and it was just "here's where you can ask questions".

I have no involvement in Erlang, but I just looked at that page, and as an outsider I would agree that the navigation could certainly be improved. I think a lot of the problem for me is that there is no distinction between the numbers for "Chapters" and for "Sections", and this confused me as to where I was in the progression.

Maybe using numbers for chapters, letters for sections, and a 1.A notation for the headers? At the least, adding the chapter numbers to the header, so it says "1. Introduction"? Putting the chapter numbers in the URL would help too. So would adding some highlighting in the right column index to indicate the location of the current page.

It seems like fantastic introductory material, but only if people can find it. Usually, the first thing do when I encounter a paginated manual like that is to search for a "single page" or "print" or "PDF" link. Is there one there that I couldn't find? If not, adding one might be a simple (partial) fix.

Edit: If others have more (and better) suggestions, they can be added to the issue I filed here: https://github.com/elixir-lang/elixir-lang.github.com/issues...

Re: Crystal: Fast as C, Slick as Ruby

#377

Post by kbenson »

eridius wrote: post #61
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…

Rust already lost most of its interesting sigils. I'm curious which sigils that are left you think should go away?

I've never understood people's abhorrence of sigils. They are useful shorthand for very specific concepts. It's like hating apostrophes in English. You can do away with them entirely, but I don't think most people would consider that an improvement.

Now, the greater density of concepts shorthand notation can be abused, and too much of that often shifts the cost benefit ratio further to the cost side for all but the most expert in the language, but that's a problem of too much, not on inherent with their use at all.

Re: Crystal: Fast as C, Slick as Ruby

#378

Post by igouy »

Scarbutt wrote: post #51
rdtsc wrote: post #44

Earlier quoted context omitted.

It is hard to say how they measure and what they measure. According to their "multiple queries" benchmark, which I guess is the real world one? (Unless everyone expects all custumers to line up and send their requests one after another one). https://www.techempower.com/benchmarks/#section=data-r12&hw=... we should all be using Dart on the server coupled with MongoDB perhaps.

The Dart vm is pretty damn fast, way faster for any CPU bound stuff than the BEAM.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

as-in FAQ 1.4 "What sort of problems is Erlang not particularly suitable for? … The most common class of 'less suitable' problems is characterised by performance being a prime requirement and constant-factors having a large effect on performance. Typical examples are image processing, signal processing, sorting large volumes of data and low-level protocol termination."

Re: Crystal: Fast as C, Slick as Ruby

#379

Post by masukomi »

damagednoob wrote: post #70
sdogruyol wrote: post #43

Earlier quoted context omitted.

I'm the author of Kemal(kemalcr.com), a simple, fast and modern web framework for Crystal. We've been using Crystal in production(at Protel) for more than 6 months for some heavy load APIs (100-200 req/s). We've replaced our Rails API with 64 unicorns to just 1 Kemal process and it's not even breaking any sweat while consuming nearly 100x less resource and 30x less CPU. You can ask me about our experience.

1. Has the lack of multithreading been a problem in any way? 2. Do you do the standard deployment of putting nginx/haproxy in front of a load of processes? 3. Have you been able reuse any Ruby code (including gems) or do they have to be Crystal specific.

1. most ruby code can't be used in crystal, but is trivial to port. 2. Crystal doesn't use gems (because of 1). it uses shards.

Lack of multithreading is an issue for _ME_ because i'm working on an app that could really benefit from it. Just because Ruby is used almost exclusively for webapps doesn't mean Crystal is. Also, the "load another copy of the entire app into memory" that Rails people use is a really crappy way of doing "multithreading" .

Re: Crystal: Fast as C, Slick as Ruby

#380

Post by pjmlp »

bunderbunder wrote: post #358
dikaiosune wrote: post #300

Earlier quoted context omitted.

Re: deployments, I expect that would take some time for a transition to occur. The first post date on the ScyllaDB blog is from February 2015 ( http://www.scylladb.com/2015/02/20/seastar/ ), and it looks like it wasn't until September 2015 that they specifically started publishing benchmarks of the database itself as opposed to the network I/O library they built for it ( http://www.scylladb.com/2015/09/22/watching_sc…

From what I've seen, stack based value types are not necessarily the big performance win they're touted to be. The rule of thumb I've noticed is that, if the struct is much bigger than the size of a pointer, you start seeing a pattern where it's quicker to allocate in the first place but slower to pass around. I think this is because, on a platform like Java or .NET that uses generational garbage collection, the heap…

Kind of true, but you can minimize copies if the language supports ref types, which was already common in languages like Modula-3, D or even Eiffel.

Also a reason why C# 7 is getting them as return types in addition to ref/out parameters.

Post reply on HN