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

341–350 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#341

Post by StavrosK »

rdtsc wrote: post #260
StavrosK wrote: post #169

Earlier quoted context omitted.

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

Oh sorry to hear that Stavros. Sometimes Erlang knowledge doesn't translate directly to Elixir, there are just a few conventions to keep in mind. I've used these before when playing with it: * http://elixir-lang.org/getting-started/introduction.html * https://howistart.org/posts/elixir/1 * Asking on #elixir-lang on freenode IRC Here is a specific chapter on distribution and nodes: http://elixir-lang.org/getting-start…

Thanks, the problem was that I didn't notice the rest of the pages on the guide :( I thought there was only the "installation" page.

Re: Crystal: Fast as C, Slick as Ruby

#342

Post by bdcravens »

jboggan wrote: post #325
gtramont wrote: post #17

And it already got a port of Sidekiq: https://github.com/mperham/sidekiq.cr

Whaaat? That's awesome. Now I want to see how Crystal handles ETL pipelines.

I've found the bottleneck to be the database choking on too many INSERTs, not the code doing the writes (our Sidekiq job)

Re: Crystal: Fast as C, Slick as Ruby

#343

Post by asterite »

catnaroek wrote: post #319
asterite wrote: post #316

Earlier quoted context omitted.

I can't seem to reply to your reply to this, but the error message has nothing to do with where a class is defined. You can't compile a part of your application in crystal, there are no linked crystal libraries. You compile your whole app, will all class definitions. The compiler then will have all the type information to know if a method is missing in a subclass, when that method is used from a parent class.

Well, that's even worse. Whole-program compilation has positive aspects to it, like enabling more aggressive optimizations, but it should be strictly opt-in. For future reference: The easiest way to reply to a message that doesn't have a “reply” link below, is to click on the “X minutes ago” link above.

Thank you! I didn't know that easy way to reply.

The compiler does some incremental compilation for the generated object files, so compile times are kept relatively small. Other than that, I don't think it makes a big difference for a developer except saving compile times. On the other hand, in this way you can't have a compiled library conflict so you have to "clean and rebuild" when this happens.

For example in Ruby there's no such thing as pre-compiling a gem, and every time you run an app the whole app is "analyzed" (parsed and converted to VM instructions), and so you can think in Crystal it's the same (except that it's compiled to native code)

Re: Crystal: Fast as C, Slick as Ruby

#344

Post by paulddraper »

wtetzner wrote: post #315
paulddraper wrote: post #225

Earlier quoted context omitted.

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

Of course they will consume all of it. That's how GCs typically work. They won't invoke a collection until there's no space left to allocate. Just because they "use all of it" doesn't mean all of that memory is actually live. It just hasn't done a collection yet.

> Of course they will consume all of it. That's how GCs typically work.

Perfect agreement.

Re: Crystal: Fast as C, Slick as Ruby

#345

Post by roryokane »

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…

Zig (https://github.com/andrewrk/zig), "a system programming language intended to replace C", has a lot of those features.

Re: Crystal: Fast as C, Slick as Ruby

#346

Post by oldmanjay »

paulddraper wrote: post #344
wtetzner wrote: post #315

Earlier quoted context omitted.

Of course they will consume all of it. That's how GCs typically work. They won't invoke a collection until there's no space left to allocate. Just because they "use all of it" doesn't mean all of that memory is actually live. It just hasn't done a collection yet.

> Of course they will consume all of it. That's how GCs typically work. Perfect agreement.

The disagreement probably lies in your characterization of the GC behavior as "crazy" when it merely doesn't suit your tastes.

Re: Crystal: Fast as C, Slick as Ruby

#348

Post by pjmlp »

dikaiosune wrote: post #300
pjmlp wrote: post #290

Earlier quoted context omitted.

The C++ advantage will not be so much after Java 10 comes out and finally have the value types and reified generics the language should have had since beginning. Also I am yet to see any large scale production deployment of those Hadoop alternatives. But it might still be like 5 years from now, so who knows how it will evolve.

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…

Regarding C#, Microsoft hasn't invested too much on their JIT/AOT compilers optimization algorithms.

NGEN was just good enough for allowing quick application startup.

Also they didn't invest too much in optimizations in the old JIT.

Specially since .NET always had good interop to native code via C++/CLI, P/Invoke and RCW.

There were some improvements like multicore JIT in .NET 4.0 and PGO support in .NET 4.5, but not much in terms of optimization algorithms.

Hence why .NET 4.6 got a new revamped JIT called RyuJIT with SIMD support and lots of nice optimizations.

But this is only for the desktop.

.NET for the Windows Store is AOT compiled with the same backend that Visual C++ uses. In the Windows 8 and 8.1 they came up with MDIL from Singularity/Midori but with 10 they improved the workflow to what is nowadays known as .NET Native.

With the ongoing refactorings they plan to make C2 (Visual C++ backend) a kind of LLVM for their languages, similar to the Phoenix MSR project they did a few years ago.

If you watch the Build 2015 and 2016 talks, most of them are making use of C# with the new WinRT (COM based) APIs, leaving C++ just for the DX related ones.

So they are quite serious about taking their learnings from project Midori and improve the overall .NET performance.

Re: Crystal: Fast as C, Slick as Ruby

#349

Post by exDM69 »

welder wrote: post #281
paxcoder wrote: post #212

Earlier quoted context omitted.

I've heard this said numerous times, so I'm going to disagree on the record. I think syntax of a programming language is a very important characteristic. A language with a nice syntax is easier to learn, easier to read and understand, and delightful to write. Crystal's syntax is a great differentiator between it and its statically typed, garbage-collecting competition.

Exactly! I guess people used to the Ruby syntax are just desensitized or don't know how much of a joy programming can be without having to type 'end' everywhere.

The end keywords is just a minor detail and can be inserted by a smart editor anyway.

Things like list comprehensions and do notation are examples of nice syntactic sugar.

Sensitive whitespace like Python can be nice to write and read, but it's hard(er) to write a parser for it and that's why Python's tooling hasn't been great in the past.

That said, Ruby is even harder to parse and I don't like it aesthetically either.

Re: Crystal: Fast as C, Slick as Ruby

#350

Post by pjmlp »

whateveracct wrote: post #330
pjmlp wrote: post #290

Earlier quoted context omitted.

The C++ advantage will not be so much after Java 10 comes out and finally have the value types and reified generics the language should have had since beginning. Also I am yet to see any large scale production deployment of those Hadoop alternatives. But it might still be like 5 years from now, so who knows how it will evolve.

> value types and reified generics I think you mean specialized generics (i.e. no autoboxing of primitives when used in generics)? Reified generics implies carrying around all generic type information at runtime, which will not be the case and also has nothing to do with performance. Non-value generics will still be erased I thought.

Have you seen the status update?

https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3Ar...

They will change the constant pool to have some kind of template information that gets specialized (what they call type species) into a specific set of types.

The plan is even if Java cannot fully take advantage of all possibilities due to backwards compatibility with existing libraries in binary format, the JVM will support it for other languages not tied to Java semantics and backwards compatibility.

Post reply on HN