Can Ruby Survive Another 25 Years? (techradar.com) 195
TechRadar marked the 25th anniversary of the Ruby programming language by writing "there are still questions over whether it can survive another 25 years."
The popularity of the Ruby language has been bolstered for many years by the success of the Ruby on Rails (RoR) web application framework which dominated the web scene, particularly among startups who wanted something that deal with much of the heavy lifting... But RoR, although popular, isn't the superstar that it was and It has faced fierce competition as issues such as scaling have become a greater concern for web companies. The JavaScript framework Node.js, for instance, has become popular as it requires less memory to deal with numerous connections because of its callback functions...
To improve performance further Ruby is introducing JIT (Just-In-Time) technology, which is already used by JVM and other languages. "We've created a prototype of this JIT compiler so that this year, probably on Christmas Day, Ruby 2.6 will be released," Matz confirmed. You can try the initial implementation of the MJIT compiler in the 2.6 preview1... Probably the clearest overview explanation of how MJIT works is supplied by Shannon Skipper: "With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction.
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0," and TechRadar reports that it's obvious that Matsumoto "will do anything he can to enable Ruby to survive and thrive..."
And in addition, "he's thoroughly enjoying himself doing what he does... and his outlook is quite simple: Programming is fun, he's had fun for the last 25 years making Ruby, and at the age of 52 now, he hopes that he'll get to spend the next 25 years having as much fun working on the language he dreamt up and wrote down in -- a now lost -- notebook, at the age of 17."
"We want Ruby to be the language that is around for a long time and people still use," Matsumoto tells another interviewer, "not the one people used to use."
To improve performance further Ruby is introducing JIT (Just-In-Time) technology, which is already used by JVM and other languages. "We've created a prototype of this JIT compiler so that this year, probably on Christmas Day, Ruby 2.6 will be released," Matz confirmed. You can try the initial implementation of the MJIT compiler in the 2.6 preview1... Probably the clearest overview explanation of how MJIT works is supplied by Shannon Skipper: "With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction.
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0," and TechRadar reports that it's obvious that Matsumoto "will do anything he can to enable Ruby to survive and thrive..."
And in addition, "he's thoroughly enjoying himself doing what he does... and his outlook is quite simple: Programming is fun, he's had fun for the last 25 years making Ruby, and at the age of 52 now, he hopes that he'll get to spend the next 25 years having as much fun working on the language he dreamt up and wrote down in -- a now lost -- notebook, at the age of 17."
"We want Ruby to be the language that is around for a long time and people still use," Matsumoto tells another interviewer, "not the one people used to use."
Never thought I would hear about Legacy Ruby (Score:3)
But fads go in and out. Meanwhile COBOL I heard is still popular in older enterprises. Will node.js and Rust have the same fate 10 years from now? Java seems to be declining but still is active on older software projects.
Re:Never thought I would hear about Legacy Ruby (Score:5, Interesting)
I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL [wikipedia.org] for his whole career and only wanted to program in JOVIAL for the rest of his career. I guess my business didn't matter much to that recruiter.
Most of the really good programmers can learn a new language on the plane to their new gig.
Re: Never thought I would hear about Legacy Ruby (Score:5, Insightful)
They might learn the language on the plane, sort of, but ghe whole standard library of most modern languages? No way.
Re: (Score:3)
You don't need to. Nobody knows the whole standard library of any language now. Not even a simple one like C. You learn the parts you use, and google for more stuff as you need it. Occasionally it means you'll write an algorithm instead of using a built in, but the time lost is generally minimal. If it isn't, you'll probably think "I wonder if this already exists" before you finish.
Re: Never thought I would hear about Legacy Ruby (Score:5, Insightful)
You don't need to. Nobody knows the whole standard library of any language now.
I don't think he was implying you needed to memorize it all. But you need to be pretty familiar with large portions of it to be even reasonably productive, which can take weeks/months. Of course you won't know 100% of it and you'll learn more as you use it, but spending only a couple hours to learn the language you can't possibly know enough of the standard library to claim you "can program in X". That's more like "I'm still learning X".
Re: (Score:2)
I think the issue would be if you are very familiar with one particularly rich standard library (e.g. Java) you know there's something to look for in another language.
The things that can be missed are obscure realities of a language that tend to also be missed by veterans. In my experience, for example, even long time python developers are frequently unaware of memory views, bytearrays, and such that can speed up a large class of functions dramatically or make things a lot easier in general (I too often se
Re: (Score:2)
No, you don't. I've done it multiple times in my career- you learn the syntax and jump in, picking up the library as you go along. It just means you sometimes write a bit of extra code. I wouldn't put it at expert level on my resume, but you can be reasonably efficient and get tasks done. Remember we used to program with minimal libraries and still make progress in new languages. You just might write a bit of redundant code that gets cleaned up (or not) later.
Re: (Score:2)
Re: (Score:2)
I think he is describing an "80-20" rule or some-such: that coding common tasks using standard libraries can be accomplished in a few hours, especially drawing on decent example code. Yes, you can get stuff done that way in a reasonably productive way, especially if you have experience in similar languages (all languages draw on previously used syntaxes and paradigms).
But yes, you are only just learning the language.
Re: (Score:2)
Or maybe my definition has less to do with knowing every trick of the language, and more with getting tasks done. There's two major things here:
1)Actual coding is only 10-20% of programming. Architecture, debugging, organizational skills, etc are far more important, and are almost completely language agnostic. There were definitely subtle you would have trouble finding because they had to do with language tricks/oddities, but most bugs are logical bugs.
2) You can be reasonably efficient and not do everyt
Re: (Score:2)
I don't really even want to know what the tricks are, even using my main language!
If I was using Ruby and something was hard, I'd use C. If I was using C and something was too hard, I'd use ASM. If it requires a trick in ASM, it wasn't even a trick it was a processor feature.
My advice in Ruby is, use baby-Ruby. My advice in C is, use baby-C. My advice in ASM is, don't complain, upgrade until you can do it in C.
In Perl they have ideology that prevents that from being good advice. The good news, they have eno
Re: (Score:2)
That is why modern languages have strong IDE support.
That mostly eliminates the need to learn 'standard libraries' completely.
Re: (Score:2)
Of course, only if you know where to look. If you don't know a standard library function exists, you may waste time rolling your own, and probably not as good as the language runtime provides. No IDE is going to look at your function and recognize there's a standard library equivalent.
Re: (Score:2)
No IDE is going to look at your function and recognize there's a standard library equivalent.
Every IDE does that. Did you ever use one?
Re: (Score:2)
I have used several. If I write a function called copydata that takes two filenames and then does an open on both of them and manually reads from one and writes to another, I have not met an IDE that will say "hmm, the way that function works, you *sure* you shouldn't be using this standard library function?
Sure when you try to make one and shadow another, it will point this out. Completion may complete a function name that you were about to do and give insight. If you however do not get caught by one of
Re: (Score:3)
I will say I'd rather deal with the ramp up of a programmer as they fail to be aware of a standard library feature than someone who has more time in with the language I want but seems to lack good problem solving skills. Particularly with code reviews, you can recognize patterns that are bad.
Of course, if you have a blind leading the blind scenario, that can't be good. I once sat in with a java team and a developer with over a decade of java experience was asking me if I had any thoughts on why file copie
Re: (Score:2)
I personally keep the API documentation open while I'm coding anything serious, even if it is stuff I use frequently. It only takes a couple seconds to glance at a function signature, and surely I'll read more if I have doubts instead of just forging ahead and waiting for failed tests to save me.
I'm not going to learn a whole API on the plane, but why would ever need to know a whole API? I'll need to know a few functions at a time, and they'll change depending on what part of the code I'm in. The real probl
Re: Never thought I would hear about Legacy Ruby (Score:4, Interesting)
Re: (Score:3)
Re: Never thought I would hear about Legacy Ruby (Score:4, Insightful)
I came in to cleanup a project built by one of those guys. 2+ decades of experience and a Java architect. It was a PHP sure where he used factory factory factories to initialize the entire codebase.... completely ignoring that in PHP you get a new thread for every request. He left when he couldnâ(TM)t figure out why the web server had to be forcibly rebooted on a 45m cronjob.
The same site also used inline static JS to set the destination of top menu items:
Itâ(TM)s important to understand how a language behaves in context, not just be able to pick up languages fast.
Re: Never thought I would hear about Legacy Ruby (Score:2)
Most of the really good programmers can learn a new language on the plane to their new gig.
Not that extreme, but my assumptions are the same. I assume that a good programmer can pick up a language over the weekend and after two months of daily use, can become an expert at it.
But I find many candidates in the very old & very young buckets that appear to want to remain experts in their language of choice. The older group, I understand, they are basically retiring in 5+ years and just want the easy slide into it. Money isn't that important anymore and, with that out, there is plenty of opportu
Re: (Score:2)
Learning a new language is easy. Learning how to use it is difficult. Learning the system specific libraries can be a real pain. Even in the languages I'm most comfortable in, I still need to drop into looking up references whenever I want to use a library I haven't used frequently.
Re: (Score:2)
I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL [wikipedia.org] for his whole career and only wanted to program in JOVIAL for the rest of his career. I guess my business didn't matter much to that recruiter.
Most of the really good programmers can learn a new language on the plane to their new gig.
In the case of that candidate, it's probably not a good idea for him to try switching languages; he'd end up writing JOVIAL code in Java or Python, would look like a literal translation of German into English, or worse.
Re:Never thought I would hear about Legacy Ruby (Score:4, Insightful)
sdk's come and go..
look, nobody cares nowadays if I know symbian c++. they do care that I've been working for 15 years making apps for handsets.
people care even less that I could do vesa 2.0 programming for dos. they might care that I knew enough to download the few docs needed for accomplishing that back in the day.
and back in the day.. people would get jobs for symbian programming purely because they knew enough to compile something. now there is a market surely for jovial only programmers, but hey come on if you think about that, they never went an extra mile.
real reason for why someone would stay on that would probably be that nobody expects you to churn out code quickly in the usual gigs for that sort of a language.
there's plenty of older guys who have had the luxury of churning out just few hundred lines of code per year - or even less, being a resident programmer at whatever bigger company doing just one specific part of some huge budget thing. very few people from my generation ever had that sort of luxury. sure it would be nice. I would probably still enjoy trying to crunch down some mobile java to smaller kb size. nobody is going to pay for that though, not even those who should.
sometimes you know a sdk is going to be goneski in a year and the app you're making will never make it's money back on that platform.. but even then plenty of companies wanted to make windows phone apps.
Re: (Score:3)
Re: (Score:2)
It doesn't bother me if a language or tech dies because my skills
Re: (Score:2, Insightful)
C should never be used for complex systems. It promotes insecure code by design. It simply works everywhere and if you wanted to make a new C compiler and the Linux kernel wasn't your goal, it's easy.
Never confuse available with solid. Modern computing is a cesspool of shit code in dangerous places because of "We code everything in C!". Redox is th
Re: Never thought I would hear about Legacy Ruby (Score:2)
Re: (Score:2)
All this talk is acting like C's general behavior is broadly a security problem and you can't have a language that empowers the user and be secure, but we can get more specific.
The biggest one is no innate range checking. Understandable, as range checking in the optimal case would at least require a handful more operations per array access, and particularly decades ago that was not affordable. In terms of capability, this isn't a capability anyone needs. One could argue that it robs users of the ability
Re: (Score:2)
Re: (Score:2)
I find it is generally as simple as using one (1) high-level library for that stuff per application, such as apache apr https://en.wikipedia.org/wiki/... [wikipedia.org] or glib from Gtk.
In the case of embedded programming, I have to ensure security, tools that want to protect me from myself aren't even going to fit well and have access to all the IC features.
The problem with Ruby, for me personally, is that I can't fit it on small microcontrollers. It isn't enough to have an ARM with lots of features, you have to have a h
Re: (Score:2)
Re: (Score:2)
Nah. A samurai knife would be terrible for cutting cheese or buttering bread.
For cheese you want a wire or at least a knife with holes.
For bread you want a serrated knife.
Re: (Score:2)
I'm practically a cheesivor, and I disagree strongly. For firm cheeses, a chef's knife is ideal. For soft cheeses, a cheese knife or straight fruit knife.
For crusty breads with soft interior, you want a serrated knife. For non-crusty breads or breads with a firm interior, a chef's knife is much more effective.
And if you fancy yourself so well dressed that you have brioche for your bread, a serrated knife is going to send serious crumbs flying, to be sure.
A samurai's knife, or even his small sword, would be
Re: (Score:2)
For firm cheeses, the benefit of a wire or a knife with holes is that you can slice and release. Otherwise it just gets stuck to the knife. For soft cheeses, anything will do for cutting it.
I wasn't referring to cutting bread, but buttering it (which is what the post I was replying to mentioned). A serrated knife is best there because you can angle the knife to control the spread, as it alters the gap between the bread and the scallops in the knife. The teeth of a serrated blade also help spread butter
Re: Never thought I would hear about Legacy Ruby (Score:2)
As a former COBOLcoder I swear to god Iâ(TM)ll quit the industry if that god forsaken language ever gets resurrected by the hipsters. Lifeâ(TM)s too short and Iâ(TM)m alread half of the way thru it so no cobol bad
Re:Ruby, Python, Perl.... yawn (Score:5, Informative)
I rather suspect that you are a long-time Windows-based programmer.
Of course C is more performant. It's not a high-level language. It is intermediate-level at best. That's why C++, for one example, is higherl-level and therefore easier to use but slower. And interpreted languages will always be to some degree slower, because of their very nature. But they are also capable of doing more with less programming effort, and that is THEIR forte.
Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.
As for C libraries, that's partly what scripting languages are FOR: tying together low-level efficient libraries into higher-level finished products.
You say "for the real work, people will always turn to native code" but that's plain BS. People and companies do not have time or budget to low-level-code everything they do. A smart programmer will use the language appropriate to the task, and that often means tying that "native code" together using higher-level languages.
Your opinion of Python, for example, is just wrong. Python, despite its language inconsistencies and weird significant-white-space formatting, has been adopted by the scientific community as probably the go-to language of choice. It may not be used commercially as much as some others, but it is going to be around a long time.
The long and short of it is: each language has its particular strengths and weaknesses. Industry watchdogs predicted the imminent demise of Ruby over 10 years ago. That hasn't happened. In fact only 2 years ago, experienced Ruby programmers in the US commanded the highest salary of any language. I haven't checked more recently. But the market is a good place to look when one is making such "predictions".
While Ruby is 25 years old, it did not gain wide attention in the United States until nearly 10 years later. So as a practical matter, in the US, it is 15 years old.
It is approximately as performant as Python, and has a more consistent structure and syntax, so I suspect the scientific community will eventually shift over to Ruby over Python, unless it skips that step altogether and goes into functional programming.
As for Ruby "scalability issues", that is a myth that has weirdly persisted for at least a decade, in the face of abundant contrary evidence. Here are companies that have had no trouble at all scaling Ruby: AirBnB, Fiverr, Github, Goodreads, Groupon, Hulu, Indiegogo, Kickstarter, MyFitnessPal, Pixlr, Scribd, Shopify, Square, Strava, Twitch, UrbanDictionary, WhitePages, and ZenDesk.
There are many more, of course, but those are just some names that people might recognize.
Re: (Score:2, Insightful)
C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.
As for python being the scientific language of choice- that's just wrong. Its still C and Fortran. Serious scientific computing requires performance, nobody would dream of doing that shit in python.
Re: (Score:3)
C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.
As for python being the scientific language of choice- that's just wrong. Its still C and Fortran. Serious scientific computing requires performance, nobody would dream of doing that shit in python.
Not anymore. These days a high level language is one that doesn't have a preditable mapping to instructions and memory access, C still has that, and C++ can have that if you use it right.
Re: Ruby, Python, Perl.... yawn (Score:2)
It depends on what you mean by scientific computing. My partnerâ"a machine learning researcherâ"has to do things in C, Python and Matlab. All three are common in the community. It's surprising how many people doing machine learning research are using things like Python.
But that's because for small networks, performance isn't actually a concern. Not everything is AlphaGo.
A friend of mine went from his Masters in Biology into a CS PhD. And he's mostly done things and continues to do things in Python
Re: (Score:3, Insightful)
C is abstracting away only two things: the names and amount of registers, and the way how you call functions/use the stack. ... that is up to you. But might lead to strange eyes when you get a bad grade in a test ..
It is considered by academics not to be a high level language
Of course you could disagree
Re: (Score:2)
C is not a high level language.
It is neither you nor JQP who makes those definitions, it is the professors in he universities giving CS courses.
You could nitpick that ANSI C has evolved far from old school K&R C, however K&R C was just a portable assembler, it was designed to be that.
There are people arguing that only languages like Lisp, Prolog, Haskel, OCml, SQL etc. are *really* high level languages. In other words: not even Pascal, C++, Java, C# are high level languages.
Re: (Score:2)
And according to them, anything that's machine independent is high level language. If you want a term for something more than that, come up with a new term and a new definition. Until then, stop muddying the existing ones.
Re: (Score:2)
Citation please ;)
Or care to read this and shut up? https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3)
C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.
Who's definition are you using? I consider C to be a high level language (albeit at the very bottom of them) because it's machine independent, so it allows abstraction of the underlying system implementation. I'm just curious how we define these things because I can't find a clear definition from anyone I trust.
Re: (Score:3)
In sceinftific computing, your developers are largely not programmers, but scientists. This is why Fortran has enjoyed more relevance in that field than everywhere else, it maps more closely to how they express and learn math.
It is also the case that when it comes to intensive operations, they are generally merely supervising standard modules. specifically, python scripts can supervise numpy code, and that implementation is what matters not the text the scientist is typing.
Essentially, they need a "glue"
Re:Ruby, Python, Perl.... yawn (Score:5, Insightful)
I suspect the scientific community will eventually shift over to Ruby over Python
Unlikely. The reason the scientific community is using Python is that Python has SciPy, a rich and powerful collection of libraries. The heavy lifting in SciPy is done by compiled Fortran library code. Right now a Python program using SciPy is nearly as fast as the same program written in Fortran, and Python is dramatically easier to use. And it probably doesn't hurt that Python added a matrix multiply operator (infix @), just for the benefit of SciPy users.
In science and engineering, Python is now benefiting from network effect, where everyone uses Python because everyone else already uses Python. For Ruby to steal these users it would have to do something dramatically better and to date Ruby hasn't even matched Python. And if Ruby did get an edge on Python I predict that Python would implement something similar and keep its position as the language for science and engineering.
Re: (Score:2)
That said, I use C a lot, C++ when writing drivers for sensors a
Re:Ruby, Python, Perl.... yawn (Score:4, Interesting)
Great post generally, and I agree that Ruby is unlikely to 'get an edge' in scientific computing. That said, the difference in the languages tickles just beyond the reach of that last phrase -- I'm pretty sure the aspects of Ruby that resemble Lisp can't be bolted onto Python. Especially the blurring of code and data (a la Lisp) -- a 'bolt a feature on' response is nigh-on-impossible expressly because that vast range of python libraries won't work lisp-like code/data ambiguity.
Python's great, and as a scientist/data geek, I love working with SciPy. As a hacker, I love working with Ruby. The synapses they tickle are so far apart, they're not even orthogonal.
I've also noted a steady growth in Lisp-mindedness. Over Lisp's 60ish years, cLisp, Clojure, Ruby etc seem to be growing mindshare. Slowly, and in fits and starts, but growing. Lisp's ability to craft parsers and DSLs have gotten us to where DSLs like like LUA are mainstream. There are skunkwork Lisp-like languages in some top tech firms. Fun stuff, fun times.
Re: (Score:3)
Of course C is more performant. It's not a high-level language. It is intermediate-level at best. That's why C++, for one example, is higherl-level and therefore easier to use but slower.
That's flat out not true. Bad C++ is slower than good C and bad C is slower than good C++. The only thing that makes C faster than C++ is the restrict keyword, which all major compilers support for C++ as an extension.
Idiomatic C++ is often faster than idiomatic C, compare for exampe std::sort to qsort.
Re: (Score:2)
That's why C++, for one example, is higher-level and therefore easier to use but slower
Both of your statements are the opposite of the truth. Well, apart from the one about it being higher-level, which might be true. It's not easier to use than C, and it's not slower.
Re: (Score:2)
Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.
A few conveniences like performance. I changed which build servers were running part of our monolithic process recently because it took 45m to run a step in JRuby that could be done with a native Ruby gem in about 10m.
Next up, replacing that Ruby gem with a NodeJS plugin that can do it in under 2 minutes... on the same hardware.
Re: Ruby, Python, Perl.... yawn (Score:2)
Replace âseriousâ(TM) with âhigh-performanceâ(TM). 99% of the code in a video editor does not need absolute screaming performance (it is waiting for mouse events in any case).and 1% is the part that actually does the video transformation.
Most low latency GUI stuff runs directly on the video card in any case.
Event-driven I/O doesn't require Node (Score:5, Insightful)
Event-driven I/O is a good idea. It happens that Node already has a good one because it's a web standard, and it inherits it from Chrome along with the rest of Javascript. However, event-driven I/O is easily done in C, Ruby, Python, Java, anything that supports coroutines. Many of these languages also support lambdas, anonymous blocks, and closures. Yes, even C++ has lambdas and will have futures (like closures) in the next standard. The syntax for them is sort of clunky next to Ruby.
C programmers haven't just learned about select() and poll(), they've had them for a long time. These allow them event semantics on the existing Unix I/O primitives and you can build an event I/O library on top of them.
Javascript doesn't really offer all of the desirable features of modern programming languages. After all, the goal was for it to look like C. We'll end up with a nicer language with a first-class event-driven I/O library and no native I/O.
Re: (Score:3)
I wonder about people who find Nawmal videos entertaining. To give you some background on that, I hate having meetings on text chat servers because everyone else types really slowly. Similarly, watching two CG talking heads go through a dialogue, and in a monotone, is incredibly tedious for me because I could read the same dialogue much more quickly and I expect more inflection in speech. And probably because I worked at Pixar and its predecessor for 19 years, I have much higher standards for CG entertainme
Re: (Score:3)
Because non-relational databases do not have data relations, yet most data you want to use is INHERENTLY relational, then that "screaming fast" database is offset by the custom programming (and programming time, and cost) required to create those relationships yourself.
It might be fast, but it only does what you tell it to do, and you want to know that customer ID 3894567025 made purchases 36021, 42573, 56819, etc.
In non-relational databases, you have t
Re: (Score:2)
Non relational databases of can have 'relations'.
Or how do you think graph based databases work?
Or in memory databases like Java's 'prevailer'?
Re: (Score:3)
Non-relational databases have field occurrences. Fields in a document are associated with other data in the same document. Those associates may contain values that occur in other documents' fields. You may have to do multiple queries to pull data from multiple documents (if it's a large data set), but the individual queries are fast.
No, you cannot do fast ad hoc queries in a non-relational document store. No, you don't have anything like normalization in non-relational databases. Yes, managing duplication
Re: (Score:2)
Because non-relational databases do not have data relations, yet most data you want to use is INHERENTLY relational
But they are not webscale.
Re: (Score:2)
Re: (Score:2)
apache lets you choose between a wide variety of IO systems, and has since the 90s. That is simple sauce.
Re: (Score:3)
Because I am one of those boring, pedantic people who insist on actually reading all of the way to the third sentence of the story, which said this:
Re: Event-driven I/O doesn't require Node (Score:4, Interesting)
Why are you talking so much about JavaScript when the story is about ruby? I love Perl and believe perl will always be the best so now Iâ(TM)ve posted the same as you.
Because the point of the video was about the cool kids who discovered non blocking I/O async event driven do not understand threading or code quality. Yes you can do something simple VERY fast ... but in actually node.js developers develop their own OS with threading and end up with call back after call back loop spaghetti.
What Ruby 3.0 is attempting to do is just this. It makes more sense to use threads and let the OS deal with assigning them to CPU's and ultilizing which set of code to execute next.
Re: (Score:3)
I would definitely use Node if I was serving WebRTC. There aren't that many other solutions.
I wonder how many of those folks understand that they're actually programming a state machine. Which we have had forever.
Re: (Score:2)
Everything in computing is about state machines. OOP -> state machine, functional programming -> state machine, raw assembly code -> state machine, neural network -> state machine, ...
Re: (Score:2)
but in actually node.js developers develop their own OS with threading and end up with call back after call back loop spaghetti.
It kind of sounds like you're not aware of the language features introduced in ES6 (3 major node versions ago).
It makes more sense to use threads and let the OS deal with assigning them to CPU's and ultilizing which set of code to execute next.
OK so you're saying that threads are a better concurrency model than promises on certain OSes? Let's hear why you think that.
Re: (Score:3, Interesting)
We should start with the point that not everything that should have promises does, and it will take another couple iterations of the Javascript standard to get there.
Javascript I/O programming creates a hidden state machine. Threading makes it obvious what the states are and what their order is. Implementing a state machine in a switch statement generally does this too, although it's
Re: Event-driven I/O doesn't require Node (Score:2)
It's weird to have an entire discussion thread about ease of promise/callback programming without once mentioning async-await, the only thing that makes it humane. (or is that the syntax you were referring to?)
Re: (Score:2)
Re: (Score:2)
Bruce; you would do well to actually read a bit about javascript before just guessing. Async/await is just synactic sugar over promises. Promises are just an easy to grok syntax for async FSMs.
Threading has been thoroughly trounced by async programming. It took a long time for people to realize it, but those of us who have been 100% async in C for decades know exactly why node.js is booming: because it does not offer threading or blocking so it forces people to write somewhat performant code. My biggest gri
Re: (Score:2)
Re: Event-driven I/O doesn't require Node (Score:3)
Re: (Score:3)
That sounds like engineering, not hacking. Can't have that.
Re: Event-driven I/O doesn't require Node (Score:3)
Why not? COBOL is still around (Score:2)
There is even an object-oriented version these days.
https://supportline.microfocus... [microfocus.com]
Re: (Score:2)
There is even an object-oriented version these days.
I thought that was called Java?
Survive? Likely. Thrive? Likely Not (Score:5, Insightful)
Code lasts a log time, so there will be users here and there. But, I highly doubt it will thrive. Python is gaining and has an advantage of very good interoperability with C libraries and improving overall performance thanks to projects like NumPy and the like. It's use in data science and other projects as well as in CS education will continue to help the overall implementations, Python competes in the language space that Ruby is in, and I think it does it very well, even with the issues around the 2/3 versioning. Honestly, Ruby is behind Python, and that gap is increasing.
The original advantages of Rails are disappearing. More and more of the MVC work is moving to the client side, and the server side is increasingly oriented towards just providing REST services. The amount of server generated HTML, a big part of Rails initially, is very rapidly decreasing. And while Rails is evolving, that legacy still exists. And other stacks have caught up. NoSQL make the ActiveRecord pattern much less needed for example. So, if you want raw speed in terms of time to implement, Node and the MEAN stack are really more competitive. Of course, that speed comes at a real cost and NodeJS has it own problems.
All in all, Buby faces enough challenges that will take too long to fix via language and runtime changes for its future to be vibrant. I expect it will fade in the face of Node, Python and even the resurgence of strongly typed frameworks (Java, C#, Scala) alongside newly revived languages like Erlang (and it's modern cousin Elixir) that embrace patterns for scaling that serve the whole modern web well.
Re: (Score:2)
It's a security risk put too much of the app logic on the client side, let alone being tripped up on client-specific bugs. Then again, risk hasn't stopped a lot of questionable trends/fads.
Re: (Score:2)
Re:Survive? Likely. Thrive? Likely Not (Score:4, Interesting)
Ruby has a better syntax and probably a better object model. I'm sure there are all sorts of good things about Python's current popularity. Tell me though, can we even call this "2/3" morass a transition at this point, or are we just going to deal with these two separate-but-equal codebases forever? Popularity is not meaningless, but language fundamentals matter too.
Rails is certainly past its peak, but it actually works just fine as a set of REST endpoints. I don't know why you think that the framework is mostly about HTML generation. I'm also fairly concerned if you think that NoSQL is ascendant, dominant, or entirely a good idea. SQL as a query language is likely to be more enduringly popular than the relational datastore per se, but neither are exactly dying out. If as you seem to be suggesting, Node development offers a rapid path to buggy code, I am probably going to steer clear of that one, too.
Ruby is a pleasant and concise language. From my experiences in coding golf competitions, it's usually 30-50% shorter for the equivalent line of Python code. If it had a speed advantage, or seemed likely to obtain one, I would expect it to win out over Python in the long run. As things stand, I would expect that Ruby will continue to exist as a glue language, and as a common point between things like Crystal and Elixir. The syntax ideas and standard library functions of Ruby may end up being more durable than the language itself; Python on the other hand has had far less influence on the design of subsequent languages.
Re: (Score:2)
There's some good points here, but i would note that Python as a language has its fans as well and some would argue it is quite well designed overall. Personally, I find Ruby can be a bit too clever in places, but such things are a matter a taste.
I don't disagree that the adoption of NoSQL could be problematic, merely that those looking for speed of implementation are increasingly adopting it and it is displacing Rails. Fairly or unfairly, Ruby is often tied to Rails, and as interest in Rails subsides, it i
Smalltalk/X, anyone? (Score:3)
"With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction."
That sounds very much like Smalltalk/X to me. Will be interesting to see how well this works for Ruby. In Smalltalk/X, however, larger pieces of code were compiled ahead of time this way; the JIT compiler in Smalltalk/X to my understanding doesn't use the intermediate C route or generate .so files.
Can ruby survive? I hope not (Score:2)
Every once in a while Ruby crashes and burns when installing gems...on a system seemingly identical to another one that works fine.
Once the Ruby guys can fix that I'm sure Ruby will do fine.
Re: (Score:2)
Well, old languages, you know (Score:2)
Ctrl-f "RPG"
It's still doing a lot of commerce, so why shouldn't any other useful language?
Ruby versus Python (Score:3)
I think Ruby has been overshadowed by the huge success of Python. Recently I set out to learn a new high-level interpreted language, something for easy scripting and prototyping, somewhat like the role BASIC (at least in its more advanced variants) used to fill. I was drawn to Python and Ruby. They both made a similar sales pitch, they sounded good. But which would it be?
Well, I have a friend who is already a Pythonista, and it appears to have more mindshare all around.
In all my web searches about Ruby, I kept coming up with Rails, Rails, Rails. Ruby on Rails is great for web development! Ruby is a great language for web development! (In case you all haven't guessed, web development is something I have no interest in.) And, oh yeah, Ruby can supposedly, theoretically, be used to create stand-alone applications, though we don't really talk much about that.
The other thing that irked me was Ruby pushing OOP in my face, hard. In Ruby everything is an object! EVERYTHING!! (This seems to be true in Python as well, but they don't harp on it like this.) Then I look at the Ruby tutorials, and they immediately launch into discussion of classes and objects, before even basic stuff like flow control. Well, I'm one of those crazy geezers who thinks that OOP is oversold. Sometimes useful, yes, nice to have built into a language, sure, but there's no point in messing with it just to dash off a quick script or simple little application. If I just want to say Hello World, I shouldn't have to begin by defining classes. Didn't we go through that madness already with Java? Was no lesson learned? So, I got a tutorial book on Python. Classes are covered in chapter 22, not in chapter 1. To me, that's a lot more sensible. And if I merely want to use my classes as a slightly fancier counterpart of C structs, Python doesn't judge me.
By comparison, the only really dumb thing I've encountered with Python is its ridiculous use of white space. I guess I can learn to live with that.
Re:Ruby versus Python (Score:5, Insightful)
I've used both Python and Ruby for years.
Personally I think Rails killed (or is still killing) Ruby. Largely because Rail apps scale poorly and beyond a very basic level become hopelessly unmaintainable.
I agree that Python is quickly becoming dominant in the scripting language space. Largely because of libraries like scikit. And bluntly, this isn't the 1980's anymore. Back in the day you coded in C except where you had to jump into assembly for a bit of speed. But these days I think the right design slice is to do the performance-critical parts in C (or maybe C++ or something similar) and use a scripting language as the glue code.
There are a lot of things about Ruby that I think are awesome and much better than comparable languages (my favorites is how the pattern-matching operator ties into switch/case statements and exception handling). But the world is moving on and sadly, Ruby is likely to be left behind.
Re: (Score:2)
You are wildly off-base with respect to Ruby, and in respect to OOP, "crazy geezer" is the kindest characterization. Ruby and Python are extremely similar as scripting languages. I don't know what you read about either language, but this is an offensively stupid post.
Re: (Score:2)
It's "offensively stupid" to simply relate what I have observed? I didn't make any of this stuff up.
Re: (Score:2)
You did not invent any experiences. You're were sufficiently outraged by the idea of object orientation, because of your own inadequacies, that you stopped reading something that mentioned the subject. In doing so, you somehow missed that Ruby's "hello world" is shorter than Python's, and that in general the only difference in scripting is that Ruby has less required syntax. Not understanding such basic logical abstractions as classes is also completely absurd, but if you can say such things and remain empl
Re: (Score:2)
I think it was a detriment for a while. As somebody who was interested in learning Python, it was a bit confusing and off-putting to me. However, I do get the feeling that Python 3 is over that hump now and the language can move forward again.
What does it offer others don't? (Score:2)
Ruby to Crystal lang or Python to Cython. (Score:3, Interesting)
On Friday a fellow engineer asked me what I thought about Crystal lang. Crystal lang is a Ruby like language that compiles down to machine code. Intrigued I took a look. That language is similar to Ruby but it has static typing which has a performance advantage. I wrote some test code. It was fast. The language itself is a little different from Ruby. What makes Ruby, in addition to syntactic sugar, are gems. Crystal's analogue are Shards. I noticed that the style of Shards is more procedural and less object oriented. This is my first impression of the language. It left me wondering what I would lose if I migrated from Ruby to Crystal lang.
I love Ruby. I love the syntax. The performance can be an issue sometimes but there are workarounds. Let's be honest, Python won the war. Python solved many problems with it's built-in types, language simplicity, and good performance. For all Ruby's syntactic sugar Python grew and dominated. There are extremely helpful Python modules that have made entire industries. Performance matters.
When I tested Crystal lang I asked myself if there was an analogue in Python. Quickly I thought of Cython. I never had a reason to use it but I was looking for compiled self contained binaries that I could use on some of my weirder systems where installing dependences is difficult. I work in the docker space so Go seemed like a good choice. With in less that an hour I was producing statically linked binaries. My code was simple so I did not have to tackled the more complicated bits but it was a good first go.
Python in Cython is still Python. Crystal lang is like Ruby with completely different modules. What Cython is doing is different from what Crystal is doing. Cython is taking Python code converting it to C which and running it in an embedded Python interpreter. Crystal is producing machine code without an interpreter which theoretically has performance advantage. The advantages of Crystal may not out weigh the advantages of Python and Cython.
I applaud what the folks at Crystal lang are doing. I may not use Crystal because it doesn't fit what I'm doing but I would love to see them grow and develop. If I need something compiled from a scripting language I would use Cython over Crystal. Win 1 for Python.
Does Ruby have an optimization keyword now? (Score:2)
I'm given to understand that Ruby is slow in part because all objects can be "monkey patched" at run time. I've always taken it as the language where you can serve web pages from an integer if you like. 3X faster than old Ruby is still not fast, right? All the JIT in the world can't help you if there's no clean mapping from the language's objects to the machine's objects. You'd need some kind of "lock" optimization keyword in the language, and perhaps other fundamental changes.
Other posters have mention
Version 3, three-times faster? (Score:3)
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0,"
Yukihiro. You know that's not really how version number work - riight?
Re: (Score:2, Troll)
Re: (Score:2)
Why are comments and documentation so discouraged?
The idea is that documentation is just a band-aid for unclear code, and it will in the end become out of sync with the code, causing further confusion.
Of course, for this to work you have to code very neatly, with a clear and obvious program structure, and functions that do just one thing and are named properly. That way, the names of the functions act as a way of safer documentation, as if you were coding in natural language, sort of. That's of course a lot more work than dropping a comment here and there,
Re: (Score:3)
This is pretty much the blessing and the curse of Ruby - its philosophy works excellently for the best programmers (who are able to write clean and DRY code etc.), but is not really a good fit for mediocre ones, unlike Python or JS. And since there are always only so many best programmers, and majority is always average or worse, Ruby is sort of destined to be niche'y, which may ultimately spell its failure, or it may not. Personally I am enjoying coding in it, even though I am far from the "best programmer
Re: (Score:2)
AMD64 ancient? Guess I AM getting old :(
Re: (Score:2)
Last I looked at Crystal it was pretty immature, but that may be a year ago now. How does it do with multiprocessing? Will it support guilds? (For that matter, with Ruby? And if so, when?)
To me guilds made me consider switching back to Ruby, but I haven't seen anything new about them, like, say, a working implementation, even if it had bugs or was slow, in the last year. I'm less interested in the faster execution (though that would be good) than in the easy, seamless, multiprocessing.