TruffleRuby is supposed to have a full release by the end of the year, with speeds up to 7x faster than MRI...

TruffleRuby is supposed to have a full release by the end of the year, with speeds up to 7x faster than MRI, Ruby's reference implementation.

Why aren't you using Ruby yet, Sup Forums? If you want to use a dynamic language, you might as well use one with advanced metaprogramming, awesome first-class functions support, and the best OO model since Smalltalk.

Other urls found in this thread:

jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil
twitter.com/NSFWRedditVideo

I like my apps to launch before i get back from my coffee break

because it's a god awful language with god awful, unintelligable grammars.

virtually anything that made it useful can pretty much be done in javascript, or god forbid, python.

Python doesn't have OO that works nearly as well as Ruby, and neither does JavaScript. JavaScript also can't do many of the meta programming things that Ruby can—or, at least, not as easily.

The grammar is not unintelligible when used sensibly. In fact, the syntax for passing a function to another function is some of the nicest I've seen in any programming language. Some people prefer code without "do" and "end" everywhere, but I think it's just as readable as braces, if not more so.

TruffleRuby is supposed to have a really quick startup time as well, actually. They're doing some weird AOT compilation stuff to make it work like that.

If I wanted performance I'd rather use Crystal...

Sounds pretty interesting. But why is it better than JRuby?

I'm also curious about Ruby3, which will be there in 2018 or 2019..

if ruby would have had a bigger scientific community this would have made it very appealing wrt to python

>1000x slower than native code before.
>Now only 120x slower than native code.

Seriously though, same issue as with rubinius et al - extensions cant be ported from MRI.

Same situation with Python and PypPy, half the shit does not work and you use it only when absolutely desperate.

Python doesn't have OO that works nearly as well as Ruby
How, exactly? Be specific.

He probably means muh :attr_accessor meme. Ruby takes purist OO approach - objects have only methods, which encourages more encapsulation.

Doing this in js or python by nuking the wildcard getters/setters is rather awkward.

>Python doesn't have OO that works nearly as well as Ruby

Not him, but apparently the object modell of Ruby is pretty cool. It's based on Smalltalk: everything is an object, even classes. And everthing has an return value. This simple fact makes things extremely convenient. Another thing are the extremely powerfull iterators of Ruby.

For example 1+2 translates to 1.+(2). You simple call the method +() at the object 1 (or rather the object :1, since there can be only one object called 1).

How is this usefull? Think about this code:
(1..100).reduce(:+)


1. You create a Range
2. You use one of Ruby's iterators, the "reduce" method. Note that it automatically checks the type of the objects (integers) and assumes you want to reduce something of the same type.
3. Instead of sending a block (a code snippet what the iterator should do exactly) you can directly throw the "+()" method at the iterator. It therefore creates a new object and tries to calls the +() method with every parameter as argument.


OK, this sounds pretty complicated, but it really isn't. Once you undestood that you can call every object and it will return something (or say "I don't know how to deal with that call") things are very easy.

You can also "redirect" method call, for example some object A uses an array, and when you ask: "A.length" A looks up it's methods, realizes it can't answer that and passes the call to it's array. So the array returns it's length and everybody is happy.


It's hard to describe that stuff without coding examples..

TruffleRuby uses the Graal framework to run much faster than vanilla JRuby. Graal is an oracle-developed compiler framework that makes languages on the JVM.

SciRuby is actually pretty good, if not widely used. TruffleRuby is likely to be much faster than Python, and it will likely eventually work with C extensions, so it is my hope that it eventually gains enough popularity.

In Ruby, you send messages, instead of calling functions. describes that.

Ruby also works well because it has singleton classes. Each object has its own "copy" of its class, and you can monkey-patch specific instances at runtime, which can be useful in some contexts. It's also easy to monkey-patch core objects, which can be used for great good as well as great evil.

Elixir > Ruby

>SciRuby is actually pretty good,
Between numpy, scipy and matplotlib so many corner cases are now covered that its very difficult not to find some accelerated methods for what you need. Thats what TruffleRuby will have to compete with, not regular ol Python.

In addition, engineering effort on sciruby and nyaplot are not comparable. Latest commits are 9 and 24 months ago respectively.

I'm the author of several Ruby gems with over a million of downloads each. Ask me anything.

I like Erlang and I also think Elixir was a good idea. But Ruby is just super smooth, it's a "just werks" language.

Elixir can be pretty tricky sometimes and some things are way more complicated, just for the functional paradigm alone. I think Elixir deserves a bigger audience, but for me it will rather be a "special purpose" language when I need a powerhorse.

[heresy]

I think Scala looks a lot like Ruby (for example "everything is an object" - unlike in Java) and also uses Erlangs/Elixirs actor modell, even with the same syntax. Of course the Erlang virtual machine is great and much better for concurrency than the JVM, but Scala's syntax is much sexier IMHO.

[/heresy]

Web frameworks?

1. 7x faster than slow as shit is still slow as shit
2. Likely has backwards compatibility problems
3. No static types means its hard to grow projects past a certain size. Needs an outrageous amount of tests to scale
4. Too much magic built into the language and frameworks so you never know how your code actually executes. All of the metaprogramming and monkey patching also inhibits scalability
5. Did I mention it's slow as shit and every package("gem") is built by hipster ruby webdevs. Who also have the same mentality of "performance is free, I dont have to think about how my code actually executes"
6. Inherently single threaded

Performance isn't free and neither is abstraction. Once you web devs grow up you'll realize that and program in Go.

I don't see how this is significantly different from Python. Everything in Python is also an object, including classes. All functions in python have a return value even if it's explicitly None.

Your specific example doesn't work quite the same in Python because by convention integers aren't allowed to be object names, but you can certainly invoke the __add__ method on the int class directly.
This does not work,
1.__add__(2)
But this does:
int(1).__add__(2)
or
n = 1
n.__add__(2)
It's messy, but you can also do a similar reduce:
from functools import reduce
reduce(lambda x, y:x.__add__(y), range(1, 101))
>5050

Of course that's silly and in python you shouldn't invoke __add__ directly unless you have a good reason to. The pythonic way of doing that would be:
sum(range(1,101))

That's not to say there aren't differences between the languages, but I've yet to see anything to back up the claim that Ruby's OO approach is vastly better than Python.

>TruffleRuby is likely to be much faster than Python

Yeah, which Python implementation? There are many, just like Ruby. Specify one when comparing.

>it will likely eventually work with C extensions

Wow yet another totally irrelevant Ruby implementation. Impressive.

This single statement makes it pointless since it will necessarily include a global interpreter lock and therefore your Ruby code will never achieve anything close to real parallelism.

Besides, a proper FFI is built into the language, into the very JIT of the implementation. You don't build fucking shared objects that get loaded by the runtime. You ask the runtime to JIT compile your calls into the appropriate library using the appropriate calling convention.

This isn't Ruby's only pitfall though.

>Each object has its own "copy" of its class

It's not a copy, it's just a completely normal, every day class.

Ruby inserts it between the object and the real class behind your back. Implementation code skips it when iterating over the look up chain so you don't see the singleton class. The singleton_class method was introduced relatively recently.

Since classes are objects, this is also how "class methods" work. They're instance methods of the class's singleton class. Kinda mind bending how Object is an instance of itself.

No, Unix utilities and developer tools I wrote for myself and shared as a gem. They're largely unmaintained now since I've moved on from Ruby but the code is there if anyone wants to continue for whatever reason.

Better is subjective. Python object/class/prototype semantics (or javascript for that matter) are insanely complex. On the other hand, Ruby has a veneer of elegant self-consistency.

Although Python's meta mechanism is more powerful, people often shoot themselves in the foot with it, so it is rarely used, and people use the only way prescribed in manual - no mixins, metaclasses, no fancy meta-accessors.

In this regard Lua is far "better" than python and ruby with its "OO" as it is truly minimal and can achieve everything python can do in far more compact manner.

Ironically, this creates even more mess in Lua - theres so many ways to do OO in there people can't agree on one. This is why Java is better than C++. This is why Ruby is better OO than Python.

>Too much magic built into the language and frameworks so you never know how your code actually executes. All of the metaprogramming and monkey patching also inhibits scalability

Just shut up instead of parroting whatever it is you heard.

What I dislike most about Python is how inconsistent the language is. They can't decide whether something is a function or a method. Sometimes they're somehow both, like a len(x) function that just calls x.len() or something equally stupid. What's the point?

Sadly Python is too useful to ignore.

>neither does JavaScript

Javascript is the most object-oriented language I know. Just because it uses prototypes rather than classes doesn't make it not OO. The language is made objectively worse by these ridiculous attempts to add classes to it.

It won't need a GIL with C extensions, unless the C extensions require it.

It loads C extensions as LLVM bytecode and interprets them. So the C part will be slightly slower, but the speed of the rest of the code will make up for it.

Maybe I didn't exmplain it very well or picked the wrong example. Also Python3 got much more "ruby-like" than Python2.

But python's object modell is differnt, the simple fact that every object has an return value changes a lot.

Strawman. I've used ruby before and this is my experience. It's slow and bugs are deeply hidden underneath the towers of abstractions. Even compared to another dynamic scripting language like python. I think it's syntactically nicer, it has a better object model, it has a much more well thought out standard lib, its more pleasant to program in.

But if you're going to be programming on a single project for multiple years then ruby is not going to do you any favors. It's going to be slow, it's going to be hard to debug, it's going to be hard to add new features, it's going to require a shitload of cacheing(which is hard to do right). I just think it's short sighted.

If you are a contractor who shits out standard web apps for companies in a few months then go nuts. That's what it was built for (DHH was a contractor).

>Wow yet another totally irrelevant Ruby implementation. Impressive.

About 25% of all ruby gems use C extensions, it's important to include them.

>..since it will necessarily include a global interpreter lock and therefore your Ruby code will never achieve anything close to real parallelism.

This is a complicated topic.

I recommend:
>jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil

why not just use Crystal?

Achcktually, pretty much all dynamic languages in wide use are prototype based, the distinction is kinda tardy.

Just because assigning self.__class__ in python isn't recommended doesn't mean it's forbidden. For that matter, assigning __proto__ in js isn't recommended either, so I suppose js is class-based now.

1. Ruby is a tad faster than python.
2. RSpec is great.
3. Python is way more complicated.
4. GitHub, GitLab, ...

1. Proof? If you're going to use a non standard interpreter for the benchmark then compare it to pypy. Also, python and ruby as a whole are too slow in general. Being slightly faster than python is not an accomplishment, it's essentially the slowest mainstream programming language in use.
2. A highly abstracted testing framework to test your highly abstracted web server framework to abstract your highly abstracted code is great. Even if it's well designed, you still need to write a shitload of tests instead of just writing types and testing application logic.
3. Ruby is more consistent, but I dont think it's less complicated.
4. Plenty of companies making millions of shit languages like FORTRAN/COBOL/Visual Basic. It doesn't validate your choice of language. Also github is slow as shit, just look at the text editor they made. Not exactly a shining star example.

Shit gc, shit win32. Still probably the best hope for ruby land. Ruby people seem to be physically not capable of writing fast interpreters/JIT, with their biannual "yet another shitty interpreter", but did a reasonable job with a compiler. Who'd have thunk it!

>It won't need a GIL with C extensions

Bold words. I remember the developers of YARV saying they only kept the GIL because of C extension compatibility. I'd say it's a pretty good bet most interesting extensions require it since they release the GIL before doing work.

You're talking about Rails as if it was Ruby. That's about as stupid as you sound.

>About 25% of all ruby gems use C extensions, it's important to include them.

I know. The point isn't to disparage the C extensions. It's to show they lead to unfortunate implementation details that don't improve on the current state of affairs.

>I recommend:

There's nothing about the GIL that's hard to understand. Obviously, thread safety in Ruby depends on the implementation. JRuby and Rubinius don't have a GIL. Therefore you cannot assume thready safety in portable Ruby code. Similarly obvious is the fact that C code is not affected by the GIL. In fact, starting independent threads to do work in parallel is one of the many uses of a C extension.

That nifty last bit is why if you aim for C extension compatibility you must necessarily implement a GIL. Because C extensions target MRI and YARV, which have a GIL. They use the APIs which acquire and release the GIL, which you must provide to the C extensions. Therefore, your implementation is an irrelevant relic of the past, just like Ruby at this point.

This obviously doesn't apply to JRuby since there are no C extensions but Java extensions. The host is the JVM.

It's "not recommended" because it crushes V8's notion of an internal "class" that represents the object and optmizers member access. It triggers deoptmizations. That's why it's "not recommended". Because the implementation sucks at dealing with it.

Deep down, Javascript has no notion of "class", unlike Ruby, Python and company. It's just objects connected to other objects. Overall a much simpler abstraction.

Is Ruby used anywhere outside of web development or DSLs for Puppet/Chef?

No, so it's fair to compare them. Slow and unscalable apply to both to Ruby and Rails.

Least python has scientific computing to hold it up. Ruby/Rails is dying a long death since all the web hipsters don't find it so hip anymore when there's new toys around(Elixir,Pony,Rust,Node).

It's a dead lang. Deservedly

? I used it to make command line utilities. Ruby is really good at string processing, just like Perl. Can you literally not think of a use for a general purpose language?

Out of all those "new hipster languages" you cited, Rust is the only one that promises with its focus on systems programming. Node is undeniably where all the "Ruby hipsters" went after "the death of Rails", yet it's just as unscalable with its idiotic single-threaded event loop. Libuv and v8 are the real stars behind Node, yet their combination failed to amount to anything more than a thin frontend to libuv that stupidly executes unbounded computations in the event loop thread.

>it's fair to compare them

You literally have no idea what you're talking about. You're talking about frameworks when the subject is languages, you're talking about languages when the subject is implementations. Calling whatever comparison you're making "fair" is an insult

Ok then,

Well for command line utilities, ruby is not optimal either. In order to execute the code you need a ruby interpreter and whatever installed gems. So if you need to deploy these utilities to a server you have a bunch of drudge work compared to something like Go/Rust where you send over a fucking binary and it works out of the box.

Any fucking programming language is suitable for a few hundred line scripts. Also Walmart,Netflix,CBS,Linkedin,Paypal,Uber.... etc use Node. Not sure why you went ahead and ragged on it. If you're asking, I don't find Node very appealing unless im doing some basic socket connection work with an interactive frontend(like a web browser game).

Rails is the only reason we're talking about Ruby today, you and I both know this. So again, it's fair to compare them. Also you keep harping this point while conveniently ignoring everything else I've said. Maybe you don't have any argument?

>MRI

Surely you mean YARV?

>In order to execute the code you need a ruby interpreter and whatever installed gems

Why is this a problem? Do you not control the servers you own? Install the goddamn binary once and run it.

Keep in mind that shit like Perl is standardized by Linux Standard Base. Why not Ruby? Literally every distro has it. You can just use RVM, especially if you don't have root.

Also, statically-linked executables aren't that different an idea when compared to an executable script with the entire runtime bundled with them. Something that exists since the days of Common Lisp. Nowadays they aren't smaller in size either since the runtimes are pretty much always xbox hueg

>Maybe you don't have any argument?

Not everything you say is worth debating.

>Why is this a problem? Do you not control the servers you own? Install the goddamn binary once and run it.

I'm coming at this from the perspective of someone who gets paid to program professionally. So no, I don't own the servers I work on. In practice I'd need to talk to the devops team to get that shit installed, and then you run into issues where you install the wrong version of a fucking gem or something and something doesn't work right. Again, it's more ceremony for almost no gain when I can write the same thing, compile it, then run it anywhere.

If you're just a hobbyist fucking around then no big deal.

Because Python is better and more widely used.

>I'd need to talk to the devops team to get that shit installed

Can't even set it up in your own user account? Fuck.

>you run into issues where you install the wrong version of a fucking gem or something

Use exact version requirements.

They renamed it.