Slashdot Mirror


Ruby 2.3.0 Released (ruby-lang.org)

An anonymous reader writes: Ruby developers have announced the official release of Ruby 2.3.0. This release introduces a frozen string literal pragma, which is "a new magic comment and command line option to freeze all string literals in the source files." It also adds a safe navigation operator &. similar to what exists in C#, Groovy, and Swift. Ruby 2.3.0 also has many performance improvements. For more details, see the news file and the full changelog.

45 comments

  1. Ruby is dead! by Anonymous Coward · · Score: 0

    Long live Ruby.

    Sound familiar?

  2. A frozen string literal pragma by Anonymous Coward · · Score: 0

    WTF!?

    1. Re:A frozen string literal pragma by istartedi · · Score: 3, Informative

      If some twit has code like "hello"[5]=0 and you wonder why all your code is going to hell, maybe this will prevent it.

      --
      For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    2. Re: A frozen string literal pragma by Anonymous Coward · · Score: 0

      My former co-worker (excuse me, "System Architect") has a Master's in computer science, and is a big Ruby fan, along with whatever else is popular today. He's living proof that you can have a college degree and design/write software that's just as shitty as someone with no formal training at all. "It's ready to ship!", he said, followed by six weeks of fixing bugs that shouldn't have ever made it out the door, along with fixes to rectify his lack of understanding of what the now-pissed-off customer actually needed.

    3. Re:A frozen string literal pragma by HiThere · · Score: 2

      Frozen strings are extremely useful when doing multi-threaded code. I take this as a sign that Ruby is getting ready for actual use of multi-core execution. (Ruby has an equivalent to Python's GIL which currently prevents multiple simultaneous execution in the same interpeter/virtual machine.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    4. Re:A frozen string literal pragma by Anonymous Coward · · Score: 0

      JRuby is multithreaded and has mutable strings.

    5. Re: A frozen string literal pragma by Anonymous Coward · · Score: 0

      Yeah - I mean those amateurs at GitHub are getting no traction at all.

      Yes - Ruby makes software development easier. Doesn't mean the language is bad. It means the code is bad.

      Or - it means, a man like me, who knows the insides of a kernel inside out, who is PhD (x2 - if they would award a second!) educated, to make software for FTSE 100 companies usable, multi-million pound e-com software quickly and agile-ey and have it launched in a month.

      Never confuse an easy learning curve for a bad language. Doesn't mean the pros can't still be great with it. This release just keeps that curve with more of a straightjacket for good software.

    6. Re: A frozen string literal pragma by Anonymous Coward · · Score: 0

      Bad arch, not bad language. I've seen the same happen with bad Tech Leads with C#.

    7. Re: A frozen string literal pragma by Anonymous Coward · · Score: 0

      And C++. And C. And every language. Ever.

    8. Re:A frozen string literal pragma by HiThere · · Score: 1

      I understand. Also, I believe, Rubinius. But that's not the Ruby we're talking about. We're talking about the one that just released a new version.

      Frozen strings are not required for multi-core execution, but they facilitate it.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  3. Re: This will make those... by Anonymous Coward · · Score: 0, Funny

    It is loved by programmers that don't like computers.

  4. Mangled title bar by Anonymous Coward · · Score: 1

    Anybody else seeing a weird mangled title bar on this submission?

    1. Re:Mangled title bar by Anonymous Coward · · Score: 0

      Yes.

    2. Re:Mangled title bar by Anonymous Coward · · Score: 1

      Confirmed - there appears to be an unnecessary line break or line wrapping going on.

  5. Re: Real rockstars use Erlang aka OTP by Billly+Gates · · Score: 2

    Outlaw Psycho Bitch is the shit man! You will have women watch you code at alternative coffee shops and groupies guaranteed!!

  6. Oh great! by Gravis+Zero · · Score: 1

    similar to what exists in C#, Groovy, and Swift

    So now it's more like the other languages that I don't like! ;)

    Ruby: consolidate your hate!

    --
    Anons need not reply. Questions end with a question mark.
    1. Re: Oh great! by Billly+Gates · · Score: 1

      Yeah why can't it be cool and hip like Erlang!

  7. 1st there was perl by Anonymous Coward · · Score: 1

    And it was awesome at the time. I still have a pile of one liners. But time matched on.
    Along came ruby. Chef, puppet, and cli but then came Rails to confuse most people into thinking ruby == rails. F*ck!
    Syntactically, ruby is the best language ever. It sucks to see it de-meaned.
    Its influence on c++/Python specially, where I spent years messing with template types, wishing for closures/Procs, is greatly appreciated. Now we have auto,decl,closures. So I take a deep bow to a Ruby.
    Wow, golang but wait c++ can do that shit now, so what's the point. So wait, now we have golang--> ru kidding me?! Somebody please...

    1. Re:1st there was perl by Anonymous Coward · · Score: 0

      From the viewpoint of a hardware guy all this high level language shit seems like re-inventing the wheel. Someone wasn't happy with Perl so they made Ruby and then Python. It all does the same shit in the end. What makes Python better than Perl?

    2. Re: 1st there was perl by Anonymous Coward · · Score: 0

      Both Perl and Python came after Perl, but they were started at roughly the same time and in different countries. As both became famous they both had their fans. Arguably we don't need both, but I prefer Python while others prefer Ruby, so we are going to have both whatever you or I think.

      Ruby carries forward the "sigils" from Perl, which IMHO are needless clutter. Again IMHO Python is a clean and regular language, and it makes me very productive.

      Ruby is slower than Python (and MUCH slower than PyPy), and Python has SciPy, so I think Python is "winning" right now vs Ruby. Ask a Ruby fan and you might get a different opinion.

    3. Re:1st there was perl by Anonymous Coward · · Score: 0

      Ruby actually came several years after Python. I'm still trying to figure out what the point of the language really is as it's slower than languages like Python and has a less consistant syntax, making it worse to work with.

      As to what makes Python better than Perl: readability. Python is generally very consistant, forces proper code structure and is very easy to pick up. Yes, Perl can be written well but there are too many ways of doing things and too many styles for doing it. This may suit some developers, but for large projects than run over many years, it's not worth the headache to try to keep Perl maintainable.

    4. Re:1st there was perl by Anonymous Coward · · Score: 0

      Python is readable. Part of the syntax of the language requires proper indenting. Perl is a write-only language. You come back to edit your one-liner in six months and basically have to rewrite the whole thing, The only use for perl is as a regex eval engine. And that's only true if you don't have sed or need to use some of the odder back-referencing stuff that sed doesn't support.

      As someone who has both a EE in digital systems and a CSC degree, yes, a large part of perl v ruby v python is just redundancy. Sometimes there exists a truly awesome bit of syntactical wankery that makes bad programmers less awful to deal with, but it's mostly a case of NIH.

    5. Re:1st there was perl by Anonymous Coward · · Score: 0

      Ruby has clean syntax, is pervasively object oriented, supports reflection, extending base classes and modules, mixins, etc., etc.
      It's a perfect prototype language, and makes me massively productive above all other languages I've used.

      It's too bad Rails gave it such a bad wrap, because the language, which really has nothing to do with Rails, is really really neat. In many ways, its syntax makes programming fun again, as the syntax and language doesn't get in your way of making what you want. ActiveRecord even makes a relational DB part of your code, so you've got everything in "one place", and boosts productivity by automating alot of DB operations/migrations.

      So if someone open minded reads this: Give Ruby a shot. It may make programming fun again for you too. It's really nothing like the mess Perl is.

      Myself, I should have a second look at Python though. Seems to be gaining in popularity all across the board.
      Then you have Go-lang, which again, may drastically change the game again. It's good times to be a programmer!
      Also tempted to check out Erlang as concurrency is getting more and more important these days.

      But where to get all the time for this while having a full-time job?

    6. Re:1st there was perl by Anonymous Coward · · Score: 0

      - the Ecosystem (libraries, contributors, general developer interest)
      - features/restrictions enforced on the language level

    7. Re:1st there was perl by Shados · · Score: 1

      It's too bad Rails gave it such a bad wrap

      Rails is terrible, but the Rails -community- is what is making me keep my distance from Ruby. I've worked at countless companies, in pretty much all mainstream programming languages and got involved in a lot of communities, but none made me step back so much as the Rails community. Freagin viruses taking every best practices and flipping them upside down then looking at you like you're an idiot for challenging them.

      Then when that falls apart they spread to other communities and try to push their Rails bullshit in every other language so everything can be Rails-like.

      The Ruby language takes the brunt of it.

    8. Re:1st there was perl by Anonymous Coward · · Score: 0

      From the viewpoint of a hardware guy all this high level language shit seems like re-inventing the wheel. Someone wasn't happy with Perl so they made Ruby and then Python. It all does the same shit in the end. What makes Python better than Perl?

      All of these languages do "the same shit in the end" as assembly language. Why bother with Perl?

      It's not a matter of re-inventing the wheel. Perl is a mess wrapped up in a disaster wrapped up in a nightmare, the king of cludge. Perl 6 isn't going to improve things. Larry was a novice and an amateur at programming language design, and he ignored a lot of lessons that were already well known at the time Perl was created, which didn't help matters.

      In most software development environments, a lot of time is spent on maintenance, documentation, and test. Far more time is spent on those three tasks then is spent on initially writing a piece of code. This places a priority on languages that are well suited to writing maintainable, well documented, easy to test code. Perl isn't well suited to any of those things in a team environment. In all too many cases, reading Perl code is simply not an efficient use of one's time.

      Software engineers have learned the hard way that letting their teams use Perl is a bad idea, unless one is writing something quite short (no more than 10 pages, preferably no more than 3 pages), and even then one must have a lot of experience writing maintainable code. The last is key: only a small number of people on a typical software team can do this well. The folks coming out of school generally can't, because the publish-or-perish system ensures that most professors won't give them the individual attention required (not to mention that most professor's lack the knowledge and experience needed to do that teaching: computer science PhDs are far better at math then they are at programming). Developing skill at writing maintainable code requires having the opportunity and willingness to learn from one's mistakes, and mentoring from more experienced people that have already been through the process (very few hardware engineers ever get the opportunity to go through this process) and who are also good at mentoring.

      As a hardware guy, you're probably writing Perl to test your hardware, and not working in a situation where other people have to work with your code. You're probably not creating regression suites to test that Perl code, there probably isn't much documentation, and you probably don't have anybody else reviewing either code or documentation. From a managerial perspective, this is a really bad situation. If you have to leave work for a period of time for any reason (perhaps medical, or a different job offer), the odds are extremely high that it's going to be really hard for anybody else to pick up your work. They'll probably end up deciding it's easier to start over than to mess with your Perl code.

      Another problem with Perl is the inability to run programs to check that Perl. Hardware designers working in VHDL or Verilog have lint tools to help with these. More modern languages tend to have even more sophisticated lint tools. But you can't write a useful lint tool for Perl, without spending enormous amounts of time on the task, because only Perl can parse Perl.

      In more general terms, think about the difference between wisdom and intelligence: people may have the intelligence to use Perl, but do they have the wisdom to not use Perl?

    9. Re:1st there was perl by Jane+Q.+Public · · Score: 2
      Ruby's syntax is actually considerably more consistent that Python's.

      You may be confused because Ruby has a plethora of alternate ways to do things. But they are not required and the underlying syntax is extremely consistent.

      The most inconsistent part of it was added to the language relatively recently. That is the "alternate" hash syntax. The standard syntax for a hash with symbols as keys is

      {:key1 => value1, :key2 => value2}

      and so on. But the alternate syntax is

      {key1: value1, key2: value2}

      much like JSON. I seldom use this alternate syntax precisely because while it can be simpler, it is inconsistent. Outside of the hash, you still have to use the standard notation :key1 and :key2for the symbols. So I prefer to put the colon at the beginning of all my symbols and maintain the original consistency.

    10. Re:1st there was perl by Anonymous Coward · · Score: 0

      Or, alternatively, a community that moves with the times.

      Everyone from Google to Facebook knows that we need to move to API backend with JS frontend. Rails 4 started the process, Rails 5 completes the move to JSON API.

      If the framework doesn't work for you, move on. Use another. If it does, embrace how it feels, because everyone working with the Rails 5 beta + Ember will tell you how easy the model has become.

      (Qualifier - over Xmas, developed 3 prototype APIs with Ember frontends, ported to mobile using client JS wrapper libraries. I know this may now be a dev strategy that works for your job, but for the biggest consultancy in the world, they are going to work for winning 3 bids on prototypes. I hope you hate this. The more that do, the more my day rate goes up.)

    11. Re:1st there was perl by Anonymous Coward · · Score: 0

      This comment is amusing as it starts by claiming more consistancy and then proves the opposite. I think perhaps you may be confused in what the term consistancy actually means.

    12. Re:1st there was perl by Anonymous Coward · · Score: 0

      "This language is very consistent but there's one exception."

      I fail to see how the "one exception" turns "very consistent" into "very inconsistent"?

    13. Re:1st there was perl by Anonymous Coward · · Score: 0

      Ruby has a few bizarre inconsistencies, though. For example, an until-modifier following a statement will check the conditional before every iteration including the first iteration, but when following a begin-end block will check the conditional before every iteration after the first iteration. That's the kind of annoyance which can introduce unexpected bugs during code maintenance. I had read somewhere that Matz himself has wanted to dispense with that particular behavior since before Ruby 2.x, yet still it persists (OK, I haven't looked at 2.3, but it was still there in 2.2). By now, changing it might break too much production code.

      - T

    14. Re:1st there was perl by Jane+Q.+Public · · Score: 1

      I didn't say it was an "exception". I said it is an alternate way to do things. The old, 100% consistent way to do it is still part of the language.

    15. Re:1st there was perl by Jane+Q.+Public · · Score: 1

      I won't try to argue with that. However, I think it is a rare use-case, and one can get around it by merely using the do- block syntax.

  8. Maybe it can help chef? by Anonymous Coward · · Score: 0

    I've been forced to deal with chef lately. The amount of really, really bad code with really, really bad models of how software works is scary as !@#$!@#. Anything that helps clean up the passing of strings to string processing to real, honest-to-god command lines would be welcome. It would be almost as welcome as throwing out the concept of a "LWRP", a "Lightweight Resource Protocol", that basically means the cookbook designer is too lazy to actually configure anything and leaves you to complete their half-baked job and assemble it into your own precious little mish-mosh of non-standard layouts that can never be set to default settings, and incompletely parameterized configuraitons.

    My god, it's almost as bad as CPAN published Perl and Maven published Java out there.

  9. Re: Ruby rockstar by Anonymous Coward · · Score: 0

    >Ruby 2.3.0 Released

    Has the cover art controversy already been settled?

  10. Stupid CSS by Anonymous Coward · · Score: 0

    .extlnk {
            display: inline-block;
            height: 14px;
            position: relative;
            width: 14px;
    }

    The span which the ruby-lang.org link is enclosed in is 14px wide, so gets wrapped along multiple lines.

  11. Haters gonna hate by BlackPignouf · · Score: 1

    Haters gonna hate.
    I work with Ruby everyday, and it feels fun everyday.
    Thanks for the hard work!