121 ms·
Ruby 3.0.0 RC1
- ryanong 6y agoLove the move to gemify standard library. This is a perfect mix of batteries included but also makes it easy to upgrade bits of the standard library over time between releases. Great way to prevent stagnation.
- contingencies 6y agoprevent stagnation Or irritate a long term user base? PHP has been very successful long term, largely I would argue because of maintaining almost complete backwards compatibility.
- sudhirj 6y agoPreventing stagnation and maintaining backwards compatibility aren’t the same thing. Go has a very strong backwards compatibility guarantee, and since they made the guarantee the entire compiler has been rewritten and there have been plenty of additions to stdlib.
- contingencies 6y agoYes, it's possible just not usual to replace everything without effecting interfaces.
- riffraff 6y agobut gems in stdlib work fine even for that: if the next version of the gem breaks compatibility the next version of ruby is free to import it, and you can keep using the old interface with new ruby by locking the dependency to the old gem version.
- dragonwriter 6y ago> Or irritate a long term user base? How? > PHP has been very successful long term, largely I would argue because of maintaining almost complete backwards compatibility. Gemification of the standard library has very little impact on backwards compatibility; moving out of stdlib into default gems. Moving to bundled gems is transparent to code but has to be taken account of in build infra, moving out past bundled gems is where it would become visible to consuming code, equivalent to being evicted from stdlib before gemification.
- jfacoustic 6y agoAwesome early Christmas surprise!
- sudhirj 6y agoJust to clarify for those who might not get it, a new major-ish version of Ruby releases every Christmas.
- pas 6y agoCould someone familiar with the Fiber/Async thing explain how does this differ from Python's (or Node's)? How come Python (and Node) needs explicit awaits but Ruby seems to "just work"?
- burlesona 6y agoNot an implementer but I would say those are just blocking method calls, like Thread.join. No magic happening.
- __s 6y agoPython Zen: Explicit is better than implicit There's a python library gevent which experimented with a more implicit design. Or more, this is about green threads vs async/await It can also be a bit confusing when you don't allow separating await from the call: how do you implement Promise.all? For official rationale see https://www.python.org/dev/peps/pep-0492/#why-async-and-await-keywords https://www.python.org/dev/peps/pep-0492/#why-async-and-awai...
- ioquatix 6y agoasync/await is a huge anti-pattern IMHO.
- grncdr 6y agoFrom an implementation perspective this has much more in common with Go than either Python or Node. In Go, you simply write a blocking IO call, and the scheduler in the Go runtime pauses your current lightweight thread ("parks the go routine" in their terminology) until the IO operation has some results to read. While waiting, the runtime is free to run any other go routine(s) on any number of OS threads. What is coming to Ruby is a similar system, but where a library can provide this scheduler functionality. So when a lightweight thread (a "Fiber" in Rubys terms) calls a blocking operation, the runtime is notified, and can manage the IO operation while running other fibers. As another commenter mentioned, there was a similar thing named gevent implemented for Python some years ago, but it didn't become "the way" to do things. I feel there are three main reasons it didn't catch on: 1. A lot of Python programs had blocking IO being performed inside native extensions (e.g. bindings to C/C++ database drivers). If you depended on such a library, the benefits of gevent were severely limited because it's runtime couldn't intercept the IO operations. 2. It was never part of the stdlib, so there was not a huge amount of incentive for the aforementioned driver authors to support it explicitly. 3. There were not that many examples of successful implementation of this model at the time. Go was around but pre 1.0 and not nearly as popular as it is now. Lua was also around, but again, not extremely well known. I expect that Ruby will also suffer a bit from #1, but hopefully, by providing this concept as part of the language and standard library, problem #2 will be mitigated. #3 is IMO a thing of the past, while I'm not a huge Go fan, it does serve as a compelling argument for an implementation of runtime-managed lightweight threads. Edit: I should mention I'm in no way involved in this, just interested in what will come of it over the next few years.
- Wonnk13 6y agoI've been writing Python for close to a decade off and on. I'm just now dipping my toes into Ruby and have found it quite fun- excited to dig deeper into this and Rails :D
- burlesona 6y agoBe sure to check out Jeremy Evans on GitHub and his whole suite of tools: Rosa, Sequel, etc. Rails is good, but the ecosystem beyond Rails is better in many cases.
- hak8or 6y agoAh sequel. I did a stint of ruby on Rails work many years back, and remember seeing sequel for the first time. It's documentation web page is honestly probably the best "what is this" and "getting started" page I have ever seen for any library. I don't know if it's the library itself or the documentation contents or the documentation website theme, but it jives absurdly well for me. I also really like the simplicity+flexibility of the library itself, and have yet to find anything even close to it in the c# or c++ world.
- st1x7 6y agoDoes some of it feel kind of redundant? I suppose that people have different reasons for learning languages but as someone who knows Python, Ruby is one of the languages on my not-to-learn list since it would neither allow me to work on anything that I can't work on now or introduce some new and interesting language paradigm.
- richardwhiuk 6y agoLearning languages which are reasonably redundant is much faster, because there's a lot less to learn - mostly syntax, and keywords. So, yeah, although there's less gain, there's less cost, and you might come across patterns you can transfer.
- dragonwriter 6y ago> as someone who knows Python, Ruby is one of the languages on my not-to-learn list since it would neither allow me to work on anything that I can't work on now or introduce some new and interesting language paradigm. Python is a pervasively procedural (to the extent that it likes hiding OO features behind procedural interfaces), statement-oriented programming language with multiple-inheritance style OOP, and a structural aversion to functional idioms. Ruby is a pervasively OO, expression-oriented language, with single-inheritance + mixin OOP, and an affinity for functional idioms expressed through fluent OOP APIs. Ruby is very much not redundant with Python.
- burlesona 6y agoRC1 is a little bit late for a Christmas Day release (which is a long-running Ruby tradition). I wonder if they’ll make it, and if so, if 3.0.0 will be less stable than usual.
- lloeki 6y agoAnecdata: I’ve been running both previews daily (when I could, some gems need updating), and they seemed quite stable to me already, moreso than some other previews or even RCs.
- ksec 6y agoConsider Shopify and Github both have been testing on 3.0 and Rails Master. I say it is pretty good.
- bsmth 6y agoWell done to all contributors, looking forward to giving it a spin and learning about the additions. Has anyone had experience using RBS yet?
- atomicnumber3 6y agoI'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general purpose scripting language", I like it better. For example, I wish all the "big data" tooling was written in Ruby. But python is just the lingua franca. PySpark, Pandas, Airflow, etc are all python. I'm not really going anywhere with this, just lamenting I don't get to do more Ruby in my day job. I recently switched to writing python at home just because my productivity is so much better because I've memorized the standard library better from using it for years at work.
- abernard1 6y ago> I wish all the "big data" tooling was written in Ruby. On a practical note, Ruby's heavy use of reflection, inheritance and method_missing style dispatch currently makes performance for big data tasks less than ideal. Python is less expressive but its "one true way" makes things like vectorization and type specialization easier for data tasks. Sometimes you really just need a better Fortran.
- lloeki 6y agoI believe you’re confusing Ruby with Rails. While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic. As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.
- abernard1 6y agoI concur. The dynamic inheritance part of Ruby is still core even in a non-Rails ecosystem. That does make optimizing performance more difficult. But on a much simpler level, a lot of Pythonic data code is just functions + values, without them being complected in an object. That makes a lot of stuff like wrapping numerical libraries in C very easy in Python. I think you'd still have a bit of a culture shock writing procedural, return-by-value code in Ruby. That's pretty normal in Python and I think one of the (many) reasons it got picked up by STEM disciplines in academia. Looks over shoulder at awful code in Numerical Recipes in Fortran book. Different strokes for different folks and all that, I just think there are probably constraints (and cultural values) that Python has that make it more suited to data problems than Ruby.
- ethagnawl 6y agoI hadn't been following the proposals for and development of Ruby 3 very closely, so Ractors were a nice surprise when I finally did check in.
- izietto 6y agoI really dislike this: {b: 0, c: 1} => {b:} p b #=> 0 It is so weird that a variable named `b` is initialized after an hash-key-like symbol is referenced (`b:`). It's something you've never seen in Ruby before and that I hope I'll never encounter along my career as Ruby on Rails developer.
- speedgoose 6y agoIt's becoming quite common in JavaScript, but usually with a const/let keyword in front so it's easier for the brain to understand that you are reading a destructuring assignment.
- izietto 6y agoExactly that, I use it all the time in JS. I can't see why Ruby can't adopt something like: params = { a: 1, b: 2 } { a: a } = params p a #=> 1
- latortuga 6y agoI believe you are misunderstanding how this new feature works in Ruby. You've brought up destructuring assignment in javascript which flows right-side values by key to left-side variables. In Ruby, this new syntax is "rightward" assignment, values flowing from left to right: 3 => x # assigns 3 to x [4, 5] => [x, y] # assigns 4 to x, 5 to y
- speedgoose 6y agoIndeed. It's very different. Thanks for the clarification.
- spaced-out 6y agoDoes anyone know the reasoning for adding this? The link doesn't discuss that. As someone who worked primarily in Ruby ~5 years ago, it just seems like useless complexity to me.
- sandGorgon 6y agoI look at Ruby and I think of Dart. Not from language semantics perspective..but specialisation in a very narrow usecase and around DX. But really unbeatable in that usecase. all racehorses are one-trick really.
- bestinterest 6y agoI feel sort of similar for most languages, low level? Rust/C/C++ 'corporate' work? Java/C# Android? Kotlin iOS? Swift ML / Data statistics? Python
- pjmlp 6y agoWhich is why the best option is to be polyglot and not silo as "X Developer".
- mchusma 6y agoThis seemed sparse on JIT updates, I read the linked NEWS page and while it had some feature updates, I'm curious how this is going. I believe JIT went from "likely to speed up most applications significantly" to "may sometimes speed things up, default is off and needs more work." Anyone know the status of using JIT in something like a rails app?
- Rochus 6y agoI did some measurements based on the Are-we-fast-yet benchmark suite, see my post https://news.ycombinator.com/item?id=25495450 https://news.ycombinator.com/item?id=25495450
- Rochus 6y agoIn case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: http://software.rochus-keller.ch/are-we-fast-yet_crystal_ruby_lua_node_i386_results_2020-12-20.pdf http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... and http://software.rochus-keller.ch/are-we-fast-yet_crystal_ruby_lua_node_i386_results_2020-12-10.pdf http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub.... I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%). See here for more information about the benchmark suite: https://stefan-marr.de/papers/dls-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet/ https://stefan-marr.de/papers/dls-marr-et-al-cross-language-... and https://github.com/smarr/are-we-fast-yet https://github.com/smarr/are-we-fast-yet. In contrast to other benchmarks the focus is on ideomatic language use and representative results (i.e. not just some random micro benchmarks) suited for inter-language comparisons.
- desireco42 6y agoWhat I got from this is how fast Crystal is :).
- vinceguidry 6y agoIf you want to split the difference there's compiled mruby. http://mruby.org/docs/articles/executing-ruby-code-with-mruby.html http://mruby.org/docs/articles/executing-ruby-code-with-mrub...
- Rochus 6y agoCrystal is a very interesting technology indeed and with my 2020-12-10 and 2020-12-15 measurements I was mainly interested how fast the compiled binary and the compiler work in comparison. With the 2020-12-20 measurement though I was interested whether MRI Ruby 3.0 was indeed significantly faster than 2.7 which doesn't seem to be the case. It's also interesting to note that even if MRI Ruby was tree times faster it still would be half as fast as LuaJIT (considering that LuaJIT would be even faster if the tracing JIT would also support closures).
- oblio 6y ago
- what2build 6y agoAnecdotally, since I got away from Ruby, working on software became way more productive and tolerable. Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd. Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a dozen languages were involved. Insert Confused Jackie Chan meme.
- ritchiea 6y agoInteresting, I'd say the opposite. In a Rails app that was written consistently with the styles and APIs documented in the Rails docs I have never been more productive. In other micro-framework type environments, regardless of the language, Ruby/Sinatra, Python/Flask, Javascript/Express. Most codebases I've encountered are a mess of inconsistencies introduced by various developers over the years. With a lot of the mess, effectively re-writing the core features of Rails and it's most popular gems. Rails, if done correctly, is a remarkable tool to allow developers to focus on the business logic and UI of their app and forget about the "filler features" that pretty much every app needs implemented. On the other hand if you write Rails code without reading the docs and re-invent the wheel rather than doing things the Rails way, essentially running an app in the framework without using the framework methods, you can create yourself a monstrous unmaintainable codebase like no other.
- what2build 6y agoRails is not vanilla Ruby. And web apps are not the only software that needs to be written. I moved on from Ruby land right as AWS was blowing up, and admitted I have never worked in Rails.
- ritchiea 6y agoYou're correct, Rails is not Ruby. But in my experience 80%+ of the Ruby ecosystem is Rails. But now I'm even more curious what problems you encountered with Ruby because I find it to be an excellent scripting language, especially if performance is not a major concern.
- simias 6y agoI tried Ruby over 10 years ago and while I really enjoyed the language itself (vastly more than, say, Python for instance) I was completely put off by the insanely poor performance of the interpreter. I remember trying to get it to run on a rather slow FreeBSD box back then and just loading a simple script with a few dependencies would take literally seconds! Perl and Python were easily an order of magnitude faster. Have things improved on that side?
- DarkWiiPlayer 6y agoThere now is: - Fibers - Also fibers, but scheduled - Threads (Not what you'd normally calla thread, because GVL) - Ractors (what you'd normally call a thread) I wouldn't say this is a bad thing per se, but I imagine it will be quite confusing for people trying to learn the language.
- derefr 6y agoFirst pattern matching, and now type-hinting and message-passing actors. Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby? Not to say I’m not grateful! I’m mostly an Elixir dev, but since the Erlang Runtime System sucks at POSIX (bad at pipelines, bad at exit codes, bad at trapping signals, etc.) I personally switch to Ruby when I need a glue language. It’s nice to see the available paradigms in these (actually very different) languages “coming together”, in a way where I can spend less time mentally mode-switching, and just keep thinking in (functional, pattern-matching, concurrent-actor) terms. Just think how pleasant it will be to write a “show a spinner as you poll a resource in the background” code in Ruby, now that we’ve got actors. :)
- pmarreck 6y ago> Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby? One has to wonder. I don't think I'll go back. I found that I was coding almost exclusively in a functional style, in Ruby (because it was easier code to test and it seemed to produce less bugs/fewer mental-model problems), then realized I was still missing out on the guarantees that Elixir gives you, then I thought, what's the point in staying when I could get guarantees that eliminated entire classes of bugs for free? Having done Elixir for a few years now, I RARELY have to go into "debugging mode", I've never even had to fire up Elixir's version of "pry", and my tests have caught all but a few bugs. All my logic lives in sensible locations. It's pretty nice! At least for web dev.
- bestinterest 6y agoI see a lot of Elixir lovers but I just can't wrap my head around a lot of the idioms. Is it bad I much prefer loops to reduce? Also modelling complex domains things just flow better in my brain with OOP, whenever I go to draw things I put them in boxes with as little state as I can. I would love love love to see two people approach the same exact problem with OOP and FP and see the rewards of both. However I really love pattern matching from Elixir real game changer of a idea, excited to see it come to Java and Ruby soon and the lightweight threading models come to both of those languages also. I always preferred Brian Gotez's argument that you should be functional within objects. https://www.youtube.com/watch?v=8GWZE2Y2O9E https://www.youtube.com/watch?v=8GWZE2Y2O9E
- reyramon 6y agoD