61–70 of 133 posts
In case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... and http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... . I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%). See here for more information abou…
In case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... and http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... . I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%). See here for more information abou…
What I got from this is how fast Crystal is :).
In case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... and http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... . I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%). See here for more information abou…
15% is a decent speedup.
I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…
Ruby might have some qualities but overall it's less polished than python Just as a small example, Edit: .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list Also the optionality of parentheses sounds like a good idea but it actually makes things more confusing and less parseable
This seems like an odd complaint: Both languages use hash maps to look up methods/attributes, which aren't inherently sorted. Looking at the implementation `dir` in python does an explicit sort, which just seems like arbitrary behaviour.
Earlier quoted context omitted.
Totally. Another thing is that outside of scientific data applications, ordinary data processing apps at scale have been map-reduce for a long time. That's an inherently functional paradigm that's closer to Python. Having parallelized heavily OO Ruby code across machines by unrolling it into functions that could be sent data payloads... that's not a fun thing to sell in an OO culture. In Python you're kind of already…
I don't think that would really be too bad, TBH. Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project. All you really have to do to translate map and reduce into an OO paradigm is have the map and reduce operations take objects that implement specific interfaces instead of functions that have a certain signature.
Yeah, but that required everybody learning a different style of programming that wasn't OO ;-).
The problem is for "map", you have to get rid of shared state and the interleaving of state and time. Interleaving state and time is basically the only thing objects do beyond providing a namespace and polymorphism. There's also an inherent 1-ary behavior in most OO code. If you've got a complicated object graph, making something a bulk N-ary operation is non-trivial. A lot of ORMs have this problem when trying to optimize queries. When you're passing a vector of "state" to a function, it's much easier to make things bulk. (Anyone who's had to make legacy code provide a bulk API with an efficient DB insert operation knows what I'm talking about).
What you usually get in Ruby is a bunch of code that's like Duck.quack() and a complex set of things below that interface. What you need for data processing is something like quack(ducks[]). The way of parallelizing real-deal objects keeping them objects is with actors, and then you need to worry about distributed state a lot more.
Anyhoo, that's a long way of saying that the much-derided procedural or functional style of Python avoids this problem from the get-go. You can just slap the "map" step onto a stream processing system without cutting your graph into pieces that don't share state.
Anecdotally, since I got away from Ruby, working on software became way more productive and tolerable. Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd. Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a…
Did you have a look at https://crystal-lang.org/?
This seemed sparse on JIT updates, I read the linked NEWS page and while it had some feature updates, I'm curious how this is going. I believe JIT went from "likely to speed up most applications significantly" to "may sometimes speed things up, default is off and needs more work." Anyone know the status of using JIT in something like a rails app?
Anecdotally, since I got away from Ruby, working on software became way more productive and tolerable. Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd. Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a…
Earlier quoted context omitted.
I concur. The dynamic inheritance part of Ruby is still core even in a non-Rails ecosystem. That does make optimizing performance more difficult. But on a much simpler level, a lot of Pythonic data code is just functions + values, without them being complected in an object. That makes a lot of stuff like wrapping numerical libraries in C very easy in Python. I think you'd still have a bit of a culture shock writing p…
I'm inclined to agree. One of Python's strengths in this space is that it's a procedural language with just enough in the way of object-oriented facilities. That makes it possible to write reasonably object-oriented libraries with easy-to-learn interfaces, while still sticking to procedural idioms for the actual data hacking. Which, in turn, means makes it a comfortable environment and interfacing mechanism for both…
Python has the full program with multiple inheritance, metaclasses, abstract classes, slots, attributes, properties and decorators.
One can go wizard level with Python's OOP facilities.
Earlier quoted context omitted.
Ruby might have some qualities but overall it's less polished than python Just as a small example, Edit: .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list Also the optionality of parentheses sounds like a good idea but it actually makes things more confusing and less parseable
> .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list This seems like an odd complaint: Both languages use hash maps to look up methods/attributes, which aren't inherently sorted. Looking at the implementation `dir` in python does an explicit sort, which just seems like arbitrary behaviour.
Especially when dir() is more used in interactive applications (and sure, sometimes programatically like in plugin architectures, etc)