Can someone comments the differences between Nim (old mimrod) and Crystal? Which one do you prefer and why. Thanks.
Crystal: Fast as C, Slick as Ruby
321–330 of 439 posts
Re: Crystal: Fast as C, Slick as Ruby
#322Earlier 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…
One of the largest areas of concern is for real-time systems (systems which fail if they do not respond within some small time threshold). Most GC involves stopping the world to perform the GC which can pause your program's execution for some number of milliseconds. If GC pauses exceed your real-time requirements, you're out of luck. Some languages, like erlang, do slightly better by garbage collecting erlang process…
For hard realtime systems it actually doesn't matter anymore. These are mostly implemented with a "don't allocate at all" strategy, since every allocation is not determistic. Therefore things are mostly statically allocated and bounded. And maybe there are some objects pools are around. You can do this in Go in the same way as in C. The only question there is if the GC will still run in the respective languages if no allocations happen through the user (e.g. because the runtime could do allocations in the background for it's housekeeping).
Re: Crystal: Fast as C, Slick as Ruby
#323Earlier 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…
The Erlang VM (modified) has supported over 2M concurrent connections: https://blog.whatsapp.com/196/1-million-is-so-2011 ? Furthermore, assuming each request is mapped to an Erlang process, each of them get their own VM -- no stop-the-world.
Correction: I meant to say each of them get their own GC, not VM.
Re: Crystal: Fast as C, Slick as Ruby
#324Earlier 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.
Java 10? I'm still waiting for Jigsaw (originally slated for 1.8, is it coming in 1.9???)
No need to wait.
Re: Crystal: Fast as C, Slick as Ruby
#325And 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.
Re: Crystal: Fast as C, Slick as Ruby
#326Earlier 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 -- just look at the performance articles on Java."
These articles are bullshit. Most settings are either obsolete or forcing the default. The rest is just useless.
I spent months doing performance tuning of applications stacks which were using Java (for app, database or both). Most of the settings are useless and barely change +-1% in performance.
The JVM has had good defaults for a while. The only thing one MUST configure is the -Xmn and -Xmx options to set the maximum amount of memory allocated to the java process (both settings to the same value).
Re: Crystal: Fast as C, Slick as Ruby
#327Earlier quoted context omitted.
> It's similar to Node in that regard. No it's not, it is very different from Node. Elixir/Erlang know how to take advantage of multiple CPU cores easily. Node by default doesn't.
Well it does, but it still doesn't do it efficiently. That was the only point I was making. But in general, yes, Elixir/Erlang will handle CPU bound tasks better than node whenever they can be effectively parallelized.
> Well it does, but it still doesn't do it efficiently.
Oh interesting. Does it run callbacks on multiple threads? That's new, I haven't followed it for a couple of years.
Re: Crystal: Fast as C, Slick as Ruby
#328Can someone comments the differences between Nim (old mimrod) and Crystal? Which one do you prefer and why. Thanks.
Googling: http://forum.nim-lang.org/t/1246
Python syntax with macros => Nim Ruby syntax => Crystal
Re: Crystal: Fast as C, Slick as Ruby
#329Earlier quoted context omitted.
Have you ever used a language with a decent type system though? I couldn't stand to use Javascript or Go at this point.
Of course. I've used C pretty extensively, Java enough to hate it, and C#. I consider myself a javascript developer because that's what I've done my best work in and that's what I enjoy the most.
He said decent type system, not static one.
Re: Crystal: Fast as C, Slick as Ruby
#330Earlier quoted context omitted.
> But most likely - you simply do not need a language without a GC. Absolutely. That doesn't mean I can't want predictable performance or deterministic destruction. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up (i.e. on the overhead of managed runtimes and GCs). Before, I'd have argued that it was just necessary. Having spent a bunch of time…
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.