No more Ruby support in NetBeans – the feature was little used, says Oracle

Oracle has announced the discontinuation of Ruby support in the NetBeans IDE. The reason? First, to free resources for JDK 7 support; but second (and more significant) – hardly anyone was using it.

There is hardly a shortage of Ruby IDEs. Ones that come to mind are the Eclipse-based Aptana, JetBrains RubyMine, the Visual Studio based Ruby in Steel, and Embarcardero’s 3rd Rail. Further, some Ruby developers prefer to work without an IDE.

I also suspect that Ruby has not quite hit the mainstream in the way it seemed that it might a few years back. Its influence has been huge, but in practice many developers still fall back to PHP, Java and C#.

VN:F [1.9.18_1163]
Rate this post
Rating: 0.0/10 (0 votes cast)

Related posts:

  1. Top languages on Github: JavaScript reigns, Ruby and Python next
  2. Ruby interpreter flaws make the case for JRuby?
  3. CodeGear’s Ruby on Rails IDE is released
  4. Microsoft Ruby
  5. Ruby on Rails on .NET

7 comments to No more Ruby support in NetBeans – the feature was little used, says Oracle

  • soren

    “There is hardly a shortage of Ruby IDEs”

    Um, yeah there is… Netbeans was by far the best free Ruby IDE…

  • 3rd Rail isn’t officially dead, but it seems to be sleeping.

  • tim

    @soren thanks, sounds like Ruby in NetBeans will be missed. What do you make of the claimed little use?

    Tim

  • Just like most dynamic languages it becomes really difficult as the programs get either
    * larger
    * more than 4 developers

    There is just a whole class of bugs that static typing shields you from and it isn’t completely feasible to have 100% code coverage automated testing. The boost in less constraints quickly gets overshadowed by the complexity less constraints brings as things grew.

    The loose grammar of ruby lends itself exceptionally well for creating DSL easily though.

    I find it a bit sad though, because the ruby IDEs in eclipse really aren’t working and netbeans was tracking for something good.

    But I suppose it isn’t really strange, MS dropped(more or less) ruby from .Net some time ago, actually they mostly dropped dynamic languages as the dynamic features that are actually useful can be brought into the static world. They likely did this because ruby isn’t that used out there, in a comercial sense.

  • Jonathan O'Connor

    The writing was on the wall when Tor Norbye left Oracle.

    Having been a Java developer for too long, I miss the quality of the code completion offered by statically typed languages. In this regard, the version of Aptana I tried out a year ago was the weakest, Netbeans was better, and JetBrains RubyMine was the best. However, given the proliferation of metaprogramming in the language, I am not surprised to see lots of developers using VIM or TextMate.

  • Ruby In Steel is still going and we are shortly going to release Ruby In Steel 2.0. Obviously, I am distinctly of the opinion that an IDE is superior to an editor. In my view, there is no substitute for a first rate debugger (the Visual Studio version in our case) and really good analytical IntelliSense (not just arbitrary ‘code completion’). Plus, these days I can’t face anything that’s not Visual Studio. ;-)

  • @Niclas
    The experience of the developers I see (and work with) who have switched from statically typed languages to dynamically typed languages is exactly the opposite of yours. The additional layers of architecture required by the type constraints of static languages make developing larger projects much more painful and introduces unnecessary complexity to workaround the constraints. More importantly statically typed languages are substantially harder to test (dependency injection and inversion of control containers are *architectural changes* developers introduce often just to make their applications testable in the first place!). The larger the project the more important testing *should* be, and the more savings in effort there are to be had from using dynamic languages.