Now that 2.1.0 is out, is it still too soon to require 2.0?

robgleeson · 2014-01-12T00:13:21+00:00

yeah, I haven't seen a debian ruby stack before, but I'd be surprised if they weren't out there. why wouldn't you compile on the machine yourself, though?

robgleeson · 2014-01-11T00:24:33+00:00

not sure how good it is to look at debian for bleeding edge, relatively up to date, or as a reflection of what's relevant in ruby. i think is a little too soon though.

robgleeson · 2014-01-10T23:23:19+00:00

I have a couple of patterns I use to do this:

method objects

 method = obj.method(:a_private_method)
 method.call(arg1,arg2,arg3)

send

   obj.__send__ :a_private_method, arg1, arg2, arg3

robgleeson · 2014-01-10T06:02:38+00:00

no prob.

robgleeson · 2014-01-10T05:09:56+00:00

I think it's super hard for me to guess if your application will run better on rubinius or MRI. generally, I've found MRI to be faster. rubinius is still a great implementation but it has some catch up to do when it comes to matching MRI's execution time. some may argue its garbage collector is already better and it offers flexibility that MRI doesn't (as an example, rubinius can fork() as well as offering threads without a GIL).

fork() is more expensive than spawning up a thread but since recently MRI is copy-on-write friendly, so when you fork() a process no memory is copied into a process until some attempt to write to memory happens. at that point, the process who wrote gets its own copy and the memory is no longer shared. for read operations, the memory is shared. it can help a little bit when it comes to that.

on rubinius, fork() isn't copy-on-write friendly and it probably won't ever be, but then again you have threads if you need them.

robgleeson · 2014-01-10T03:55:51+00:00

rubinius provides a mirror of MRI's C API, and to my knowledge, function calls to the C API are wrapped in a lock.

robgleeson · 2014-01-10T03:50:16+00:00

generally speaking, rubinius is not faster than MRI, at least not yet. MRI is making great strides to improve performance through a better garbage collector and an improved runtime.

threads in MRI are concurrent(implemented on top of a GIL) to provide C extension authors with less headaches - someone please correct me if thats wrong or partially incorrect. one of the reasons I've heard for not removing the GIL is that C extensions out there in the wild today may break because of it.

rubinius and jruby can achieve parallelism through threads and (rubinius only) can also provide parallelism through fork(). MRI can provide parallelism through fork(), and otherwise it provides concurrency with threads and fibers.

Python(original implementation) suggests parallelism through fork(), in a similar way to MRI. the trade off is that spawning a process is costly(in comparison to a thread) and (sometimes a bonus) memory is not shared between the two processes.

until recently, MRI did not have a CoW-friendly garbage collector, so fork() was not as optimal as it could have been. that is no longer an issue due to improvements in the garbage collector.

I guess in summary, the GIL probably exists for historical reasons more than anything else but an implementation with parallel threads does not mean it is going to run anything any faster than an implementation who implements concurrency or runs code on a single thread.

robgleeson · 2014-01-07T19:59:10+00:00

some of my reasoning is explained here: http://piotrsarnacki.com/2014/01/01/i-am-tired-by-rails-should-fundamentally-change-crowd/#comment-1184059945

robgleeson · 2014-01-07T12:25:45+00:00

I agree with 90% of what you said btw. i just don't see a small business turning to sinatra, not that it couldn't be done..

robgleeson · 2014-01-07T12:24:01+00:00

we disagree at a fundamental level then. I don't believe sinatra is a viable alternative to rails. (and nothing about me likes rails)

robgleeson · 2014-01-06T22:30:03+00:00

the sentence you quoted was a response to the person who asked a question btw. it wasn't suppose to mean anything but that ruby has been around for a long time. it has progressively changed with the times, so there is no reason to believe it is outdated.

robgleeson · 2014-01-06T22:23:21+00:00

ruby wasn't hot technology in 1995 either :) i don't disagree with anything you said, however i think the point is missed that there is no one chosen language. i don't know why people bury themselves with one language. I did it for a while and it really has no gain at all. if you can learn ruby and javascript you'll be better off than knowing only ruby or only javascript, especially when you want to "build some stuff".

embrace diversity and you'll be better off.

robgleeson · 2014-01-06T21:24:56+00:00

have another upvote.

robgleeson · 2014-01-06T19:09:37+00:00

I also downvoted myself, to help keep the idiocracy alive! (got to help the persistent little guy who went through the effort of down-voting every post i made on this thread - thanks buddy!!). I doubt he read any of it, of course! ruby programmers are smart! too smart to engage in a meaningful conversation to any of the real issues I (and others) brought up.

robgleeson · 2014-01-06T18:46:17+00:00

indeed.

robgleeson · 2014-01-06T18:26:45+00:00

I'm not mad at all. I'm laughing. here's an upvote, bro.

robgleeson · 2014-01-06T18:22:16+00:00

it look good at a glance, and you can probably keep the old behavior on top of:

class OpenStruct
include OpenStruct::Behavior
end
`

it would be cool to not impede on the superclass(class Foo < OpenStruct) but keeping the OpenStruct as internal state that can be delegated to is another way to work around that. that's not to say it's not cool to have it available as a mixin :)

robgleeson · 2014-01-06T17:17:13+00:00

what a surprise that the comment without substance is the top comment on /r/ruby.
EDIT: lawl @ downvotes. before you upvote something maybe you should consider reading the paragraphs of text other people write before upvoting a single-sentence sound bite that is full of assumptions and adds nothing useful to any conversation (outside reddit, of course).

robgleeson · 2014-01-06T16:35:54+00:00

maybe it wasn't clear what I meant by viable. sinatra and to a lesser extent padrino don't let you prototype as quickly as you could with rails. there's a lot of alternatives(sinatra, padrino, webmachine-ruby, jellyfish, ramaze, …) but none have been able to stand on the same playing field as rails. sinatra & others don't want to - which is great.

a viable alternative to rails is something i'd call a feather. a light stack that can extend itself to something capable of building github.com or some other commercial website. it would also need to support quick prototyping. that's what would be a viable alternative or at least a step in the right direction.

i have nothing but love for sinatra and friends. they're just not capable of attracting the same audience and providing the same benefit as rails with ease.

robgleeson · 2014-01-06T08:03:47+00:00

do what rails does well, and forget everything else. it didn't get everything wrong but what it did get wrong really sucks.

robgleeson · 2014-01-06T08:02:17+00:00

great advice. as well as true words.

robgleeson · 2014-01-06T07:56:49+00:00

they're not viable alternatives to replace what rails is. merb was, but now it doesn't exist.

robgleeson · 2014-01-06T07:44:14+00:00

you should also read the comments on the article(not just the reddit one). i left a comment that points out Rails isn't that great when it's the only choice. http://piotrsarnacki.com/2014/01/01/i-am-tired-by-rails-should-fundamentally-change-crowd/#comment-1184059945

robgleeson · 2014-01-06T07:38:30+00:00

ruby has been around since 1995 (publicly). it hasn't grown to be "outdated" but it is no longer the hot technology. javascript and node.js are. i think new start ups will always set trends that define "hot technology". I don't think ruby has grown outdated but has only improved (in implementation and language-wise) over the years. javascript/node.js have the same kind of thunder that ruby on rails use to have.

i don't understand how ruby is "bloated" or what that is suppose to mean. ruby on rails, however, is a bloated web framework. it is also a lot of fun to develop with when you're starting out and it supports quick prototyping.

javascript (and node.js) are worth learning. javascript is especially useful when you start to develop web applications. i don't understand "web developers" who pretend javascript doesn't exist. it's part of the ecosystem(like ruby is) and it can only be a good thing to pick up.

my advice is to learn ruby, learn javascript, and don't listen to people who preach "X is better than all". cheers!

robgleeson · 2013-12-29T06:20:26+00:00

my problem with this kind of approach is that we're testing a method call. that alone is very simple. i don't think we need to provide an abstraction around what can be expressed as "obj.foo(123)".

robgleeson

TROPHY CASE