Hacker Newsnew | comments | show | ask | jobs | submit | sams99's comments login

for example, my redis container (samsaffron/redis) is 20mb, the official(tm) redis container is based on ubuntu is 100mb


Yes, Aman and Koichi work very closely, the main point of difference at the moment is the method cache patches, Koichi is working on getting something similar implemented in MRI


Why something similar but not the same?


That is a very good question, and I also I'm curious to find out


As if the Ruby Community has more then enough resources to improve on TWO Compiler / Interpreter at the same time. Isn't it better to work together then to reinvent the wheel?

Speaking of compiler, the JIT for Ruby development has been very quiet for months.


The thing I find depressing and frustrating about this kind of discussion is the fatalism and non-constructiveness.

I really wish it was:

"I set up a server that runs ruby spec on ruby-head daily and automatically reports spec failures to ruby-bugs"

So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better.


it's unreasonable to expect the dev who has already put a ton of work into developing and maintaining rubyspec and making it work nicely with all the ruby implementations and versions he could to have to put in the additional work to do this as well. I don't blame him for getting discouraged at having to chase a moving target on top of all that - I agree with him that having the MRI devs contribute to rubyspec was a reasonable thing to expect.


Why is it unreasonable to expect the RubySpec dev to do additional work, but reasonable to expect additional work from the MRI devs to comply with RubySpec?

I get that "the implementation is the standard" is frustrating for people who want to make an alternate implementation, but why should that obligate the original developers to accept some third party's definition of what their project should be?


They don't have to accept it. I don't have an opinion one way or another about the rubyspec being some kind of a standard. But if it exists and shows a sigsegv scenario and nobody bothered to run it before a release... that's a failure of developers. It's not even additional work.


It's not a third-party definition, it's their definition, should they want to contribute to it. By writing Ruby specs you're defining Ruby.


> By writing Ruby specs you're defining Ruby.

And presumably the MRI devs would say that by coding MRI you're defining Ruby. What gives RubySpecs the authority to say they are the canonical definition of Ruby and everyone should follow it, when the people who created Ruby disagree?


If that's their attitude, then frankly there's every reason to complain about that. Defining a language by implementation is absolutely horrible practice.


You can't call code a spec. Saying you're defining Ruby by coding it just means you don't have a spec.


In my experience, executable specs are much more useful than their non-executable brethren. They prove their own correctness, and can't gloss over important details.


> They prove their own correctness, and can't gloss over important details.

They most certainly don't, do either of those things. You can still have incorrect, incomplete specs even with an executable test suite. You only get those properties through constant work.

The idea behind TDD is to do that as you develop the application, but even then you're not automatically saved from incorrectness and incompleteness.

The only way to really do it is the way RubySpecs intended, create a third place for the specification of the language to live, that any implementation can use to measure its compliance against. If anyone running any implementation on any platform finds a problem and traces it to the implementation, then a new test case can get written and all implementations can then fix the bug assuming it's present. Code quality goes up for everyone.

Most other applications don't need to do it this way, they're intended for an install base of one. But since Ruby has multiple implementations intended to be able to run under multiple platforms on multiple architectures, a living collection of specs that ensures that each combination still has the same behavior would seem to be absolutely essential for one's sanity if one cares about the quality of the language. Each implementation then only has to maintain platform-specific test suites. It's ultimately less work.

But just like TDD/BDD, it requires organizational buy-in to really get the benefits. Everyone working on Ruby needs to be involved in maintaining the test suite or there's no way you can consider the suite canonical. If you can't consider the suite canonical, there's no point in having it.

I develop on MRI at present, but at some point I'm going to switch to either JRuby or Rubinius. If Brian actually follows through on his goals to implement even better ways of specifying Ruby than a test suite, I'll probably switch to Rubinius.


It's interesting reading your comment that purports to disagree with mine, while feeling that it instead agrees... I think perhaps the confusion is that I misread your comment that I replied to as suggesting that you can't have an executable spec, rather than (as I now think you meant) as merely claiming that an implementation can't be its own spec, which I definitely agree with.

I think something like RubySpec is fantastic, and that it's really too bad that, perhaps only because of personality conflicts with the maintainer, it hasn't been successful at standardizing behavior across ruby implementations.


I suspect from this reply that you're confused about what rubyspec is. Rubyspec is an executable spec. It is thousands of unit tests defined against the official ruby implementation (MRI).


They dont define anything, they are tautological.


A program can't prove its own correctness in any useful way. Especially for a system that is under continual development.


Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest?

It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.


> can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system

Heroku does sponsor Matz, Nobu, and Koichi. We hired them and give them a full time salary to work on Ruby.We don't tell them what to work on (i.e. we don't dictate what features or projects get shipped in what versions) it's more like corporate sponsorship. GitHub hired tmm1. Beyond that CRuby has a host of other non-sponsored contributors that contribute code and doc patches as well as set up tooling. You don't need corporate sponsorship for that, you need a passion and some time. You, in fact, could be the very person that sets up this automated system.

I find the attitude of '<company x> should sponsor <thing y>' a bit misguided. While I agree that companies who profit from a OSS should give forwards to OSS, individual contributors are ultimately they only way progress gets made. If you or someone reading this works for a company making money off of Ruby do that thing! Tell your boss you can't deploy on friday afternoon and have to fix a bug in the Ruby codebase. Ship the project on company time, and then boom...your company just sponsored that thing. It's like magic!

Anywhoo, yes finding out what things are blocking the MRI team from adopting a tool/technology and working around them can be extremely valuable. For example Matz has agreed to move the codebase development to github. This would make contributions a bit easier, however there is a blocker. There are a ton of SVN bots and tooling written around the current workflow. Right now the Ruby core team wants to spend time focusing on pumping out C code to fix bugs, improve performance, and progress the language forwards. They don't want to go off into the woods on tooling. These types of projects could be hugely impactful to the team and don't require C knowledge so most Ruby devs may be able to help. I encourage you and others to reach out to the core team to ask them what tooling projects they need and how we can help them. Understanding why someone isn't using a tool/technology is a really good start.

tldr; Good idea, let's talk to the core team about ways to help with tooling.


The point is that it's not sufficient to run the current 20k tests against head daily; there are so many unplanned variations and 'emergent' design that there's a full time job just in keeping up with the changes to MRI ruby.

And even if there wasn't, @brixen has repeatedly pointed out how the MRI authors have chosen to ignore the RubySpec project entirely. That's really sad.


The Ruby devs attitudes in the discussions linked FTA makes me question the longevity of Ruby as a serious Enterprise language.


I suspect this isn't a goal of those Ruby devs. It almost seems that "Ruby" is more like an ideology rather than a language, at least from comments like "Continuous changes is Ruby."

Note that I'm not trying to criticize this position, rather, I'm pointing out that the core Ruby team seems to have different goals than, say, the community around Java or C#.


When did it become a serious Enterprise™ language? Not being flippant or denigrating Ruby, but when I do work for established enterprises, it's never in Ruby. Java, .NET, PHP, and occasionally Python. Just because startups use it to get off the ground quickly, or to build the front end of their website doesn't make it enterprise.


Ruby (MRI/JRuby) are gaining traction in automated testing at large enterprises. Ruby is easy to learn and integrates well with java.

Cucumber provides better reporting than JUnit/TestNG. For web testing you have watir. For SOAP services you have savon which IMO is much easier than SOAPUI. For RESTful web services you just make direct calls. Then there is sikuli for ad hoc GUIs.


How do you define enterprise? I've been using ruby in projects I wouldn't call 'startup' for the last several years... including with teams up to 80 people (i.e. real enterprise)


yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enormously widespread acceptance of Spring (JavaEE is even re-gaining some traction).

Long story short (and hope my facts are right! not swearing by this, was just some googling...), I had to optimize some old code for an RoR client I freelance for and wanted to add in some more advanced ORM (still fairly simple though, mapping entity results from a stored procedure query). All the solutions I saw for this involved kindof hacking the db connector to execute some raw queries. I was curious as to why such a basic feature wouldn't be natively supported, so eventually I found some forum posts asking why it isnt (it may be by now) and all the responses were in the vein of: "That is not the Rails way and therefore the core team chooses not to support those types of features".

I know people think Java is too bulky & sprawling but after 6 months with JPA, SpringData, Spring JDBC etc. I was kindof left with the feeling "Man, there is a bit of a learning curve to pick up the overarching concepts of the Java ecosystem and its design paradigms at first, but once you are over that hump you can do more, easier with any ORM lib than with ActiveRecord". I know there is another Ruby ORM gaining traction (DataMapper) but it just seems that the opinionated nature of Ruby/Rails core dev teams makes it doomed & dangerous for enterprise use (and indeed maybe its not even their goal).

The Java approach is bulky and design-by-committee for sure but their userbase seems to demand that the fullest possible spectrum of features be supported, and then the library developers try to provide their recommended approach for new projects. Also the specs expand pretty quickly... had to use JPA 2.0 for some projects and found myself constantly frustrated because in the advancement to 2.1 there seemed to be a landslide of awesomeness added to support missing advanced database features.

I guess its one of those things where now it feels like a breath of fresh air thinking "I have more power in my pinky than....". It's a shame too cuz I still get calls from companies in a lurch desperate for RoR devs but philosophically I just can't bring myself to go back in that direction after seeing how unscary & mind-bogglingly powerful the enterprise langs have become. In part thanks to RoR, I'm sure! Wouldn't mind using it for front-end but all that stuff is so interchangeable, the syntax diffs are barely noticed in the development process. I think really the only front-end techs with noticeable differences in feel are the ones with advanced data-binding/component libraries.

Maybe there are some mind-blowing gems out there now though? Who knows....


The main benefit of Ruby seems to be the ability to catch method names and treat them as an argument. I bought "Metaprogramming in Ruby", and the author seems delighted that you can do "mycvsrow.columnname". Several other people have confirmed to me that it is really just being able to drop off quotes around what would otherwise be strings in other languages. I don't get it, at all. Maybe it's a knee-jerk reaction to verbose languages like Java. But I fail to see what Ruby offers over a Haskell or F#-like.

I got excited by seeing how passionate and excited people like patio11 were about Rails. But then seeing how Rails prefers insecure defaults and had exploits because they were essentially eval'ing user posted data really hampered my enthusiasm.

Seeing articles like this reinforces the idea that Ruby is cowboy programming, just making stuff up as they go along. Like PHP but with class.


Although I agree with what you are saying, this is hardly new. (And still disappointing IMO).

Developers in the RoR community have a tendency to say that "Rails is very good for one set of problems (Basecamp), and using it for anything else is problematic". This has been the answer for every attempt that tried to introduce some worthwhile idea to the Ruby community, be it OO design, TDD or something more "enterprisey" like hexagonal architecture. It's not the Rails Way™, move on.

I've heard developers whom I respect (ie. Avdi Grimm, Sandi Metz) shrug this inherent limitation of Rails off, and I find it really weird. It's akin to Stockholm syndrome really.


You are ignoring a decade of history in declaring Rails to be "dangerous for enterprise use". The reality is that Rails apps are used in thousands of enterprises around the world, as well as in "web-scale" businesses like Github, Airbnb, and Groupon.

However, Rails (and specifically ActiveRecord) has a very specific design philosophy (see http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) which does not include support for stored procedures (because business logic belongs in the app, not the database).

Of course, there are ways to make stored procedures work with Rails (see https://github.com/leopoldodonnell/uses-stored-procedures ) but they are likely to end in tears, since you are working against the grain of the framework.

The basic argument for Rails is not about support for or against any specific underlying technology (if you can reach Facebook-scale on PHP, then you can make anything work), it is that using a mature and well-crafted framework maximizes developer productivity.

For most startups, as well as most enterprises, that is the critical resource.


The "enterprise" I work at uses a dozen little RoR apps to put a quick and dirty UI on some DB tables so analysts/sales/support folks can interact with the data.

The main problem with Ruby in this kind of setting is that these internal tools are extremely hard to maintain because of backwards compatibility issues--which there are plenty due to lack of spec, organic language development etc. The effort to upgrade the Ruby version is much greater than doing incremental hacks to support some half-day feature, so the codebase stays pinned to the 2007 Ruby release, we can't use new gems, have to live with old bugs or missing features, etc. And with every new incremental change the project gets harder to upgrade.

The Java ecosystem has done a lot better in this regard. Scala is not very good either, we have had a couple Scala projects with version lock-in effect as well.


This is the longterm perspective thats rarely seen here, thank you.


hi dan,

i apologize, i must have been unclear because it seems that you (& some of the commenters below) are dissecting some of my statements quite literally whereas i put a lot of disclaimery type of statements to try to indicate that this is a combo of personal opinion / hazy memory (if the commenter below ever sees this he can also now receive my apology about mentioning datamapper as an ORM gaining traction, that must be a memory from years ago when i still did RoR). :D

I am aware that RoR has been successfully adopted many places, but i guess part of what i failed to explain here (that thankfully foobarian touches upon a bit) is that i believe that part of the power of "a spec" in a programming context is to maintain a solid core of functionality, that then also paves the way for expanded functionality in the future based on extensions of a similar style of syntax.

I know Ruby & Rails teams are not one and the same, I just have many memories of experiences in that community where library evolution is not incremental, does not expand functionality, deprecates as a rival lib rises in popularity.

In Java you see 2 things -- slow spec evolution & incremental expansion of features. It takes time (I know the fast-moving lang communities hate this) but I find it makes for much more robust codebases that survive upgrade processes with wayyyyyy less re-factoring/re-writing, and in type even some libraries that had their own syntax start to embrace/support the spec (Hibernate implements JPA now...).

So.... I suppose, yes, it is a personal matter perhaps. Some companies have used Rails successfully. But in freelance it has kindof bitten me (the overhead of dealing with security vulnerabilities / gem upgrades alone is astronomically more than I've dealt with in upgrading Java projects). I understand that a competent team can handle this & enterprises can pour money into making it work, but as a programmer who often works alone & hates forced unplanned maintenance, it is a tough pill to swallow.

Also, maybe it is because I am dealing with a lot of enterprise/legacy code at times. Sure, maybe business logic shouldn't go in the database. But if someone supplies me a library of highly complex Oracle functions & tells me i need to wrap these into services ASAP, am I really going to begin an immediate re-write? I would prefer that my framework is just able to wrap these functions until a re-write can be scheduled (if the codebase isn't retired before then...). Also in the enterprise community I don't find as much of a desire to have ALL logic in the app layer... often devs feel that as long as a stored procedure / view / whatever returns a meaningful coherent entity that is useful in the business logic layer, they don't really care where/how the query was aggregated.

I also understand anything can be made to scale & work for an enterprise... but it takes enterprise-level support!! I am more a champion of the rogue programmer trying to build an enterprise with a few lines of code a day. ;)

Best, john


DataMapper isn't gaining traction, sadly. v1 is abandonware, v2 forked off to become a different project called ROM (which explicitly "isn't an ORM"). I still use DataMapper v1 because I find it a thousand times nicer than ActiveRecord, but it's a minority taste.


That sounds like a philosophy of RoR, not Ruby. How would adopting RubySpec help with that?


The author claims that he is a professional developer, while bashing at a programming language (Ruby) because he wanted more abilities from an ORM (AR) of a web framework (Rails).

He thinks that DattaMapper is trending, when it's clearly not(!!) and doesn't know Sequel (another popular actively developed ruby ORM). Hence it's easy to deduce that he doesn't have a clue about the landscape he is talking about.

Yet he is bashing Ruby as if it's hard to write a module with a couple of complex, custom-made raw SQL queries.

... blah! ...


RS needs work contribution from each Ruby to make it sustainable.

It would also show leadership from MRI to encourage a semi-independent Ruby self-test framework that can run on any Rubyish interpreter. (Granted RS has RBX bias, but it would show leadership to coordinate common infrastructure.)

Since RS exists, seems like a good idea to go with that for full up integration testing, but each Ruby should still unit test it's own, low-level bits. (Is MRI doing that at least?)


> So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better. <

And why would/should they when there are quite literally dozens (or possibly hundreds or even thousands) of developers who will happily work on "making Ruby better" for no cost to said companies?

A large percentage of software developers will quite happily hack away at projects for nothing in return simply because they enjoy it (and would, quite incorrectly, claim that as compensation itself), in order to gain notoriety, boost their own ego, or any of a number of related reasons.


> reports spec failures to ruby-bugs

But why should the Ruby developers work to fix 'bugs' against an unsupported 3rd party specification?


It's essentially regression testing. Rubyspec specs out the behaviour of Ruby according to what MRI implements, so any failure is a change in behaviour from the initial implementation. Most of the time this is undesirable/unintentional.


> What tools do you need?

A better profiler, chrome flamechart is probably the best out there, it would be really nice to have the same for Firefox. Also allowing to operate in "count every call mode" and "sampling" (with control over sampling)


GitHub are running 2.1.2 GitHub edition Ruby so that is a non-issue for them.

2 -> 3 migration is VERY VERY hard. 3 -> 4 should be relatively easy in comparison.


also worth noting that you can still de-elavate the process in the container, discourse web runs under the discourse user in the container.


I don't use Docker, but this is just good peace-of-mind practice.


This article enrages me.

I totally agree with codinghorror that a blog without comments in not a blog, this is a prime example. No way to respond to the author without jumping through crazy hoops.

As to the issue.

1. NEVER use unicorn oobgc that ships with unicorn or the old one that ships with passenger. Use gctools on 2.1.1 https://github.com/tmm1/gctools or this on 2.0 http://samsaffron.com/archive/2013/11/22/demystifying-the-ru.... If you are disabling GC you are doing it wrong and creating rogue processes.

2. Expect memory doubling with Ruby 2.1.1. Not happy with that? You have 2 options. Tune it down by reducing RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR. At 1 your memory consumption will be on par with 2.0. It ships with the 2 default. Option 2, wait for a future release of Ruby, this will be fixed in 2.2 maybe even patched a bit more in 2.1.2 . See: https://bugs.ruby-lang.org/issues/9607 and http://vimeo.com/89491942 and https://speakerdeck.com/samsaffron/why-ruby-2-dot-1-excites-...

As for the, full-of-bait, title. Ruby's GC is ready for production and being used in production in plenty of places. Just don't go expecting rainbows if you disable it. And expect memory doubling with 2.1.1 if left untuned. You can choose how much you want the memory to increase from 2.0


OK, I'll bite.

First, sorry we don't have comments yet. I'm the author, so you no longer have to be enraged. Perhaps just annoyed.

Second, with Ruby 2.1, out of the box, this code:

   while true do 
    "a" * (1024 ** 2)
leads to infinite process growth. There should be no need for "memory doubling" to run this code -- you're generating throwaway strings of identical size. Similar code, in other languages, does not lead to out of control memory consumption.

Also, the problem isn't caused by disabling the GC. This happens in stock Ruby 2.1. Disabling the GC (and running it once per request) is the fix for the problem.


> There should be no need for "memory doubling" to run this code -- you're generating throwaway strings of identical size.

How do you know they are throwaway?

Your code involves two method calls. While it would be unlikely that someone has overridden them given that they are core String and Fixnum methods, it is perfectly possible. E.g:

  class String;

    alias :old :*

    def * right
      $store ||= []
      $store << self

  "foo" * 5
  "bar" * 3

  p $store
In other words, even with seemingly innocent calls like that, it takes extra work to be able to reuse that memory without a full GC pass. It's certainly not impossible, but it's not there yet.

So I agree with you in principle, but this is one of those areas where the malleability of Ruby objects makes it tricky to optimize.

(one possible example approach is to set aside a bit to indicate "has at least once been stored somewhere where it can escape" as "poor mans escape analysis" - if your object is only ever stored in local variables that have no been captured by a lambda, or passed as arguments, then it can't escape higher than where it was created, and so you can take shortcuts, otherwise you'd still need a full gc pass)


That sir, is a bug that should be reported on bugs.ruby-lang

   while true do 
    "a" * (1024 ** 2)
it is to do with the dynamic malloc limit growing too much, should be fairly trivial to patch in the next 2.1 release


Okay, about blogs without comments:

My blog doesn't have a comment section. It's because I sometimes post controversial opinions and I don't want the garbage that often pollutes comment sections ending up permanently attached to my writing. You can't delete overly negative comments without seeming like a fascist, so what do you do?

I prefer to submit my posts to HN or other sites where people can comment and not have their comments permanently attached.

As for Jeff Atwood's comparison of a blog without comments to a pulpit, that's ridiculous. Does he also hate books and essays? My blog is simply a collection of essays.


The bug, is not a "bug" its a feature missing to allow running with passenger. It works fine with unicorn.


"and part of it is the backend is really really really resource hungry."

hmmm ... we are serving our topic pages in 83ms median in 6 hours I can count 4 times it took us a second to serve a topic page. This is across MANY sites.

so I am sorry going to have to call bullshit on perf issues caused by server perf. Server perf is fine.

Client perf can improve and we are constantly working on improving it.

That said:


First view 3.255 Repeat view 2.075

Is pretty good, and it is actually faster than that when navigating between pages.


The comparison is vaguely obnoxious, but HN is in the browser rendering before the first byte is returned from Discourse:


I realize they are different systems with different goals (and different users and...), but the spare interface here does come with some benefits.


My blog runs Discourse as the backend


just sayin...


I thought the more interesting part of the comparison was as a point of reference for the qualitative evaluation of 'fast enough'. Discourse is a lot more feature rich than HN, so the actual difference in terms of numbers isn't real useful, but HN at 0.7 seconds or whatever still doesn't feel ultra snappy.


Sorry, yes. I was mixing up a few things in my head.


see my slides: https://speakerdeck.com/samsaffron/why-ruby-2-dot-1-excites-...

only perf related feature is: RUBY_GC_OLDOBJECT_LIMIT_FACTOR ... you can set it to 1.5 to heavily reduce RSS usage of 2.1



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact