Happy Birthday, Ruby
github.com
github.com
It seems that, after Ruby borrowed from many previous languages, a lot of rubyisms went into Rust (the nice functional-style enumerations, the awesome package manager inspired by Bundler). And I'm thrilled the best of the Ruby world found its way into other languages.
A future where the elegance of the Ruby language is available both as an interpreted-scriptable tool (Ruby) or a compiled-statically-typed language (Rust) looks like a nice place to me.
There are tons of uses for non-Ruby languages. These days I'm primarily in TypeScript and Kotlin, even though I really, really like Ruby; as-is it doesn't scale, from the perspective of somebody who likes manageable code, as well as I'd like it to. But when I want a non-Ruby language, I am not tied to Ruby syntax (and I kind of think that Ruby's syntax works almost exclusively for Ruby? I think a lot of the expressivity of the Ruby language loses something when you don't have its dynamic approach to the world) in a way that makes Crystal, with its lack of libraries or maturity, not an appealing choice of tooling.
(I also feel similarly about Elixir, though in Elixir's case there are also some interesting things around BEAM that I might like to leverage. And I think that a typed Elixir would get my attention right quick.)
Elixir _is_ statically typed, it just uses strong type inference so you rarely have to explicitly type things out.
A key difference between Crystal and Elixir is that Crystal tries to replicate ruby syntax in a more performant language, whereas Elixir tries to apply the sensibilities of Ruby and the Ruby community to the Erlang VM.
https://elixir-lang.org/getting-started/typespecs-and-behavi...
Life changing. It's stopped me from pushing runtime errors probably about 20 times now, in the last few weeks that i've been using it. At this point I'd say that it's strong enough to close 95% of the difference between static and dynamic typing.
Elixir's (maybe going to be merged into the standard library) property checking semantics (ExUnitProperty and StreamData) are quite amazing and super easy[0], and will catch whole classes of things that your compiler won't so I would strongly suggest checking out Elixir now.
[0] today I implemented in an hour a property check that makes me confident that a mathematical algorithm that I implemented for a fuzzer is ok (my first attempt was wrong), and then a property check that demonstrated that that algorithm applied to a stateful set of events doesn't violate critical invariants.
Also, you will almost certainly never get a statically typed Elixir, because it makes a lot of things like hot updates hard or inelegant. Sending interprocess/internode messages is something could be extremely intolerant to a static type system, because, in a way you're breaching the purity of the functional paradigm (it's the BEAM language's "one big lie"). Go struggles with this a lot in its channel semantic, and it's why there is a ton of boilerplate in gRPC (and almost no boiler plate in erlang RPC).
Also gently breaching the type system is incredibly useful in mock tests - for example, in my current project I do about 60 high-load end-to-end tests in parallel with clones of my central scheduling algorithm - this is possible because my test suite reaches into the main body, dynamically creates a new scheduler, and appends that information into an HTTP request, which is passed into a "plain old map" and intercepted only in test environment. This not only greatly accelerates the end-to-end tests (I run the full suite as a matter of course before each commit) but it also gives me confidence that my system will run under a load that is greater than I can manually trigger.
I used to do a lot of programming in C# and Java, but I didn't miss static typing at all when I moved over to Ruby and Python. I'm sure others have differing opinions, but the absolutely last thing I worry about when selecting a language is whether or not it is statically typed.
It looks like a duck, but it does not quack like a duck. This is not a diss. Crystal is good.
This isn't the case at all. It has completely different semantics (for good reasons).
I like Crystal, but there are a few too many needless gotchas for it to be comfortable.
Why not use a language that targets many platforms? E.g. Kotlin targets the JVM, Android, and Javascript, as well as is natively compiled. Now that's the real future. Better than using, say Groovy, to target the JVM, then rewriting it all when you want it to run on Android.
Its syntax strongly favors cuteness over familiarity. Wherever Ruby can diverge from expectations to give you a pointless little tickle of whimsical inventiveness instead, it seems to do so.
Visually it looks like an unwanted love child of Pascal and Python. There's no clear rhyme or reason to the use of sigils and keywords.
The standard library and built-in types are acceptable for a mediocre '90s scripting language, I guess. The difference between symbols and strings as hashmap keys is a footgun that opens up endless bugs for the type of glue code that you'd often be writing in Ruby.
Probably the only thing that keeps Ruby afloat is Rails, an extremely resource-intensive web server framework built around assumptions of what web apps were like in 2003. Everything in Rails seems to happen by pooping magic keywords in your code or in file names according to mysterious conventions, so when something goes wrong, you'll have a hell of a time figuring out why Rails isn't calling your code or is generating broken SQL. OTOH it honors the Ruby tradition of doing lots of unexpected and useless cute things like pluralizing words in your database migrations [1].
[1] https://stackoverflow.com/questions/1185035/how-do-i-overrid...
Funny, I recently made a stack switch from Ruby to Python, and I had the exact opposite impression. Ruby coding style/syntax tends to favor convention over configuration (at least in terms of Rails setup), while Python to me seems less so.
Ruby also seems to me a bit more consistent across it's versions. One of the biggest gripes I've had about Python so far is how many things are broken across various versions of the language, and the odd way some issues have been handled (having two distinctly different types of strings with distinctly different syntax according to encoding for instance). Perhaps Ruby simply doesn't offer familiarity to you individually.
I'm more comfortable with Ruby as I used it much longer, so I may be biased, and I am not shitting on Python either. It has things I don't particularly dig, but that may be my own bias. Both languages have their pros and cons, and both are certainly viable as scripting languages in this particular epoch of programming.
You must be talking about Python 2, the deprecated version for 12 years now, with support ending next year.
Because last time I checked, current, modern Python only has one type of string.
Sure, I am picking out one particular use case, but it isn't uncommon to wrap C code in python scripts to mung data going in and out of it.
You are right though. String manipulation does appear to be easier than Python 2's implementation.
>>> type(b"foo")
<class 'bytes'>
>>> b'foo'[0]
102
>>> bytes([102, 111, 111])
b'foo'
>>> struct.unpack('I', b'\x01\x01\x00\x02')
(33554689, )
So it makes sense that Python is treating it has a raw bytes array (what you call "a byte string"): it has no way to know that it is UTF8 or CP850 if you don't tell it.
But because of c/c++ experience or habits from python 2, one tends to confuse the concept of text (represented with the type "str" in python) with some specific low level implementation (the raw bytes array).
Python explicitly avoid this problem, by defining that either you know what it is (utf8 text, big endian number, etc) or you don't (raw bytes array). Manipulating text as a raw byte sequence manually would be the equivalent of manipulating directly the IEEE 754 representation of a number: it's not what you want for a high level scripting language, and hence it's why Python 3 doesn't do that anymore.
"Note that this class handles bytes independently of the encoding used: If used to handle sequences of multi-byte or variable-length characters (such as UTF-8), all members of this class (such as length or size), as well as its iterators, will still operate in terms of bytes (not actual encoded characters)."
https://stackoverflow.com/questions/1010783/what-encoding-do...
Because that's exactly what it is? std::string is a bytes buffer, not actual text. There's no guarantee that the contents of std::string will be in any encoding, let alone a specific one.
And the reason you don't see that for ruby or node is because their community said "move or die". And many, many projects just died. I've seen the graveyard in the corporate world.
I was writing brand-new applications in it for my job as late as early last year
Why the defiant tone?
As I do a lot of Python for a living, and still work on both Python 2 and Python 3, I have talked a lot with people writing new P2 apps in the last few years.
My experience is, either you have very niche constraints, or somebody made an unwise/uneducated engineering decision. Unfortunatly, I meet way more of the second type, and of course, most of them pretend to be of the first.
I would, however, like to question this wisdom of always having to run the latest and greatest. Yes there are security considerations but properly hardened, old software and runtimes run fine. You need an actually security guru, though, and not some startup promising turn-key solutions.
On what planet was my comment you were replying to FUD? I simply pointed out a few things I'm not fond of in the language (with one point in particular stemming from my own ignorance of the language, which was corrected by folks). I was quite clear in stating that python is a language with pros and cons like any other. At which point did I claim anything to be objectively wrong with the language or spread any FUD whatsoever about using it?
You have trouble with the use of sigils in Ruby? That seems like an odd complaint. I would have expected you to complain more about MINWAN.
What does ActiveRecord consider the plural of "fish"?
it still, imo, adds some cognitive overhead, and other orms I've used (grails/gorm, for example), don't try to pluralize. you can pluralize by hand if you want to, but the default is just to name a table whatever the class name is.
How do you define regular? I use both Ruby and JS almost daily, and have previously used Java and python for several years. I find ruby a joy to use and have no issues with 'familiarity'
There's a tension in programming between being verbosity and ingenuity. More flexible languages and programmers general favor ingenuity, while rigid ones favor verbosity. When people complain about the "magic" in Rails, it's usually because it's a pattern that is new to them, and they would have preferred an older pattern even if it was a more verbose one. Which is fine, but it is a preference amidst a large spectrum of tradeoffs. Unfortunately, many people tend to not see most tradeoffs in software engineering and try to come up with as many reasons as possible for why their way is right and the other way is trivial, stupid, cute, or useless.
A personality difference then. Reading clever code does nothing for me. I'm much happier digging around hulking layered codebases that may look ugly but do something valuable for the user.
I agree that the cuteness of a programming language is just a matter of taste and habit. I'm not going to pretend my criticism was anything deeper than an expression of why I personally dislike having to work in Ruby.
Reading Ruby code always reminds me a bit of trying to understand how xmonad configs work.
E.g. the Sequel example:
require 'sequel'
DB = Sequel.sqlite # memory database, requires sqlite3
DB.create_table :items do
primary_key :id
String :name
Float :price
end
items = DB[:items] # Create a dataset
# Populate the table
items.insert(:name => 'abc', :price => rand * 100)
items.insert(:name => 'def', :price => rand * 100)
items.insert(:name => 'ghi', :price => rand * 100)
# Print out the number of records
puts "Item count: #{items.count}"
# Print out the average price
puts "The average price is: #{items.avg(:price)}"
The do...end bits are "blocks" and are the most powerful feature in Ruby, not just because of what they do but also because how they do it. Similarly for other comments.
When I first looked at Rust code it looked weird to me too but once you are familiar with the language a little bit it makes sense. The only thing special about Ruby here is that it allows you to be very terse.
I don't think these need to be at odds with each other. Just because code is useful doesn't mean it needs to be hard to read.
The point being that often the "hulking layered codebase" doesn't need to be.
Programming languages are different from normal languages because they have different goals, different users and different requirements. The result in of this forced unification in Rails is something that resembles English, if you squint really hard, but in order to do so, it uses a massive amount of non-intuitive assumptions (sorry: conventions) that I as a programmer somehow should know. This makes debugging unnecessary hard. Also, when developing new features I'm constant guessing whether I should this or that form. The only way to find out is trying things out. This is fun as a hobby, but irritating when you're on the clock.
The idea that a programing language can be unified with a normal language is offensive to me both as a programmer and as a writer. They only benefit is that people who are not programmers can dabble around and still make something useful. Which isn't nothing, but not for someone who programs professionally.
Sigils in Ruby actually do have strong and clear meanings. And the difference between symbols and strings is a useful distinction. And contrary to your statement, Ruby's stdlib is far more complete and more internally consistent than what you get from Perl or Python, so I'm not sure what your beef is with that.
It's fair not to like particular decisions a language has made, but from what you say, I'm not getting the sense that you understand the decisions Ruby has made well enough to criticize them effectively. Again, it seems like your experience was colored heavily by Rails, and fair enough if that's the case. But stick to criticizing the actual source of your problems.
Is there any reason to use Ruby outside Rails? Its niche seems to completely overlap with Python and modern JavaScript, and those have enormously more ecosystem support and everything that comes along with it: faster VMs, better tooling, large corporations on committees developing language features, etc.
I view Ruby as a sort of “COBOL of Web 2.0”. A generation of programmers learned the trade with it, and it powers important legacy apps, but I can’t imagine building anything new on it.
I enjoyed “Eloquent Ruby” when I needed to learn Ruby for my previous job. Highly recommend it.
Same reason you'd use any language I suppose. It works as a scripting language, etc. For example, docker-sync, which solves file syncing issues with Docker for Mac (and works on other platforms, but less of an issue there) is written as a Ruby gem.
With AWS recently adding Ruby support to Lambda, my presumption is there's a customer demand there.
Myself, I write a lot of Ruby code that isn't Rails.
[Sequel](https://github.com/jeremyevans/sequel) - Sequel is the best ORM I've ever used, in any language. Fast, stable, unbelievably well maintained, and offers great low-level access to the database when you need it.
[Roda](http://roda.jeremyevans.net) - This dynamic routing library is conceptually similar to React Router, in that there is no static list of routes; routing is a function call. But it's faster than React on the server, and has better support for HTTP verb support, database I/O, etc.
As for there being "better tooling" in modern JS, I'm not sure I agree. Babel and ES6 are impressive, and I love writing the code they make possible. But I appreciate being able to write Ruby and know that it will just run. Writing packages for node means choosing one of two incompatible module systems, or adding transpiler bloat.
Sure, I could also do the same stuff in perl or python, but personally I find ruby to be far more expressive.
Ruby is a perfectly good scripting language. I use it with love and passion to do the kind of stuff other people use Python, Perl or Bash for.
https://letstalkalgorithms.com/analysis-of-2018-hacker-news-...
As for Ruby outside Rails, have a look at Metasploit, Puppet, Chef, ROM, Rhoda and dry-rb to name just a few.
> Is there any reason to use Ruby outside Rails?
Personally I've disliked Rails for about as long as I've used Ruby (14 years). What appealed to me about Ruby then, and still does boils down to:
- Concise while being by far the most readable language I've worked with. The day something beats Ruby on that, I'll consider switching. If they don't beat it on that, they'll have to bring immense other advantages.
- The flexibility the blocks and meta-programming brings and general Smalltalk influence on the object model.
Ruby is in many ways basically a well supported Stalltalk with pretty syntax.
I'd turn it around: I don't see any reasons not to use Ruby for any of the type of work I do.
> faster VMs, better tooling,
The faster VMs would be nice, but Ruby performance is improving fast enough. In some niches it will matter, but you can call out from Ruby to other languages easily enough - you can run JS, C, Python code from Ruby if you need to, so both the performance and tooling is largely moot for my uses, while I can understand it's an issue for some.
The last time I saw a need to rewrite any code in C to speed it up was a decade ago. Of course that depends what you're doing, but for a lot of areas, it's just "fast enough" that there's little need to worry about speed. Premature optimisation and all that.
> large corporations on committees developing language features, etc.
Yeah, no thanks. That's a good reason for me to prefer Ruby as well.
I find that it encourages a bad kind of code golf that leads to hard to maintain code.
f(if x then y else z) does not parse.
f((if x then y else z)) does parse.
Recently, and because of this same we-don't-"do"-Rails sentiment, I was forced into using Java for a web application. So I prototyped a site with Spring and Angular 6, thinking this -- arguably -- represents the "state of the art" when doing a Java web app. Out of frustration, I also cranked up a prototype with Rails. What was taking me literally 160 lines of Java and JS, to build two related models and a form to edit the relationship, took me 3 lines with Rails. Nothing else I've found allows me to be as productive as Rails for writing web applications.
I can understand criticizing Ruby for being clever. There are still magic tricks you can do with it I've never even tried to understand. I can understand criticizing Rails for being obscure. I realize that it took me MANY years to be REALLY effective with it. But if you're telling me the alternative for web applications is ANYTHING related to Java, I'll call you crazy.
I've just inherited a Laravel-based PHP site, which is so old I can't download the version of the framework it uses. Yikes. I did PHP for about 10 years, 20 years ago. It doesn't feel like a lot has changed.
So, I'm honestly asking, as someone who hates Rails: What framework, out there, somewhere, allows me to be as productive as Rails, but which is are "better," somehow?
I use Pipenv currently, but only because it's the best of a bad lot and would jump in a heartbeat if a serious competitor came along. It has its own set of problems (slow, young and idiosyncratic) but offers me at least two things its predecessor didn't: separation of production/dev dependencies and seamless integration with different versions of Python, both of which have been available in Ruby since I started programming in it.
This is a perfect exemplifies my experience with both languages: I have found while Python might be better at a lot of things, the user experience is invariably superior with Ruby efforts and I wish the Python community would put more effort into this area.
By the way, Django's inflexible templating language kills productivity (templatetags, as with Java 15 years ago) and the ORM is (how to say it kindly?) lacking in elegance. Django's Model.objects.get(pk=1) vs Rail's Model.find(1) is the least of the problems but I'm short on time now. Because (sarcasm on) we might get confused if we omit objects, what could Model.get possibly mean? (sarcasm off)
Everything in Python seems over engineered as if only very large projects are going to use it, and Django makes no exception. Still, I'll take Python and Django all the times over Java and any of its web frameworks. My personal rankings are:
Ruby/Rails > Elixir/Phoenix > Python/Django >>>> Java/* > JavaScript/* which doesn't have any serious server side framework. I have little direct PHP experience but I'd put it between Python and Java (I managed the developers on medium sized Zend project years ago.)
For me personally, Rails is the best web framework I've seen — but in an age when static typing and other static guarantees are increasingly popular, Ruby as a language is not what people want. It's an artifact of the old Lisp and Smalltalk school of thought.
Rails is not like this. Rails is more like bridge where you have to learn the rules as well as this whole bidding system that fills a book before you can actually play the game.
There is no real magic in Rails, and once you learn the tricks yourself it becomes the most pleasant and productive ecosystem to work with that I've experienced. If you don't bother to learn though, it's going to be awful and slow and opaque.
By the way some of the good ideas in Ruby and Rails have made their way to PHP7 and recent versions of Laravel. So much has changed if your last PHP exposure was 12 years ago, it's not bad now.
For most parts of Rails, I agree. There is one very important one where I don't: ActiveRecord's internal behaviors are opaque enough at most levels where you care about your database to be fairly called "magic". Having to reverse-engineer ActiveRecord to make my database stop puking and to generate a make developers who know Rails but not databases not get upset that now the solution is insufficiently "Rails-y" (whether or not it is correct and whether or not it is faster than the "Rails-y" method that's causing them problems) is not great.
By the time you've gotten there though you've certainly more than figured out how method_missing and different filename based conventions work though, you've seen what Rails is and I'd be curious to find out what you like better!
I still use Ruby nontrivially for stuff like command line tools, though.
Ruby has the easiest data access tools, between ActiveRecord and Sequel (which I prefer), out there. I don't know too many folks who'd disagree with you about that. But where you're happy with Rails taking a few lines, I am as of late big on Kotlin (because I agree with you regarding Java) encouraging me to be correct. I'm building a new product using Spring Boot, Kotlin, and JDBI and while, yes, there's boilerplate - it's not the thing that slows me down. I liken it to touch typing; I don't worry if a programmer can't touch type because getting text onto a screen is never the slowest part of the process.
The thing that slows me down, as it does whenever I'm programming, is thinking, and I've learned over time that Ruby doesn't really help me with that. (A lot of other toolchains, both statically and dynamically typed--hello, TypeScript!--do.) I just don't worry about writing a query with a join - it forces me to understand my domain while I'm writing it, not when it runs and bombs out with an error because I mistyped something or got the relationship wrong in my head because my IntelliSense doesn't exist.
It depends on what you're prioritizing. I went back to the JVM for this project in part for perf, but also because I have a pretty high bar for correctness and I want to make sure my stuff works without writing in/out tests for something as simple as types.
Horses for courses.
(Also, I would submit that the frontend SOTA for "Java" is React, FWIW, same as almost anywhere else.)
I agree with you about the usefulness of a language that helps in thinking about a problem, but I feel like boilerplate is a kind of tech debt we tend to underrate.
Between that and Spring Boot (which is fairly batteries-included but makes it clear when you're going off the happy path in ways I can deal with), I feel remarkably good about my choices with this and similar recent projects.
Not true
I'd rather test a well-factored JVM or .NET application than I would any Ruby application I've ever seen in my life, to be frank. I've never, not once, had to write a mock (awful) for a test in a JVM or a .NET application, and the quality of my tests reflect that.
What would your state of the art be for starting something new with Rails? / suggestions to become quickly productive
Also, I'm still using RVM. I never made "the switch" to rbenv; I never saw the problem with RVM.
MySQL vs PostgreSQL doesn't matter to me. I've done a lot of both. And Oracle. And SQL Server. I've never seen a problem with using any database with ActiveRecord.
Starting a new project, I just install the latest, stable Ruby, install the bundler gem, then grab the latest, stable Rails, add the basic gems, bundle, and start letting rails generate the basics.
I'm bootstrapping my projects with Vue support, because I think that's the JS framework that fits most-nicely in Rails, and there's always a presentation-heavy page that needs that kind of treatment.
(I'm assuming a Mac or Linux here. I've done this on Windows for a time, but WSL has changed the game there, and I've not actually tried to use it in anger.)
I've found https://github.com/markets/awesome-ruby a really good resource.
One thing I feel stands out is the graphQL gem. It has an unpolished feel...but dang graphql+active record is a killer combo for rapid development!
I'm a former RoR developer (about 5 years) who's now been a full time Elixir developer for two years, so I'll make the obvious suggestion of Phoenix, which is very rails inspired.
It's a little more clunky in the basics, but it has that "magical" feel that hooked me on Rails back in the day, if you want websockets. And there's a new feature coming down the pike, called LiveView[0] that I think could be a total game changer the way Rails was.
For right now, I think of Phoenix as another rails, better in some ways worse in others, but not better enough for most people to switch. But if LiveView pans out the way I think, then it'll absolutely be the killer feature that will get new apps started in Phoenix, and it's only possible due to Elixir/Erlang's concurrency foundation.
Briefly, it takes the React data model – state at the top of the tree, render the tree based on the current state, change the state and the tree re-renders appropriately – and moves it to the server, using websockets to keep the client up to date. So every connected client has its state in a little elixir process, and interacting with the page transparently is calling functions on the server so you can update the DB or whatever with your normal server side code. And if you had a normal server-side rendered view with an `<%= if .... %>` in it, and that condition changed, then voila, that part of the page will change because Phoenix will re-render it, and send down the diff and the page will put in the new HTML.
On all the Rails apps I've worked on we've inevitably added a bit of React here or Angular there to make certain pages a little more dynamic, and then exposed an API for those to hit, and then had frontend and backend development to do. I think what LiveView will provide hits the sweet spot for most apps, so you can stay in your comfortable backend language and get a bit of dynamism for free.
[0] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
It uses websockets, and I think websockets are probably necessary to implement the feature well, but that's not what I'm excited about here.
Then I found Ruby, and people talked very highly of it. But it had all these "Gems", I couldn't figure out what a Gem was. I didn't know enough. I thought it was like a compiler plugin or something. I thought that just like there were different versions of Java, there were different versions of Ruby called Gems.
Then I found Python, it had "libraries", I knew what a library was, it was something you could download and use in your code. I learned Python and liked it a lot. If Ruby had "libraries" instead of "Gems" I would have learned Ruby instead since I was exposed to it first.
Comments about Ruby say:
- "the webpacker gem"
- "Simple to integrate gems"
- "supported via gems"
- "few dozen obscure gems"
- "the I18n gem"
- "the ruby-each-line gem"
- "vast amount of Ruby gems available"
- "working with so many gems"
- "packaged either as a Wheel or an Egg"
- "The numpy module is a wheel"
- "a wheel is specifically not a source distribution"
- "NumPy publishes a lot of wheels for a given release"
Rust inherited that characteristic, what is not great. It's not a big problem either, but it's there.
I didn't dislike Ruby, but I found Python much more intuitive, as you did, but I suspect that in great part was because it had a similar syntax and concepts as C++/Java.
It was like programming in C with a much cleaner syntax and writing 1/3 of the code, it really was an epiphany.
Every language out there has pros and cons with different set of tradeoffs , you can't point at a language and objectively say X is better than Y.
Ruby has its place and whilst you think Rails is "magic" the internet begs to differ. Of course any framework looks like "magic" if you don't bother digging into implementation details of it. That is the whole point!
The fact that so many successful companies are using rails in production and scaling it, just shows the complete opposite of what you claim: "an extremely resource-intensive web server framework built around assumptions of what web apps were like in 2003."
There has been plenty of times where i wondered how a piece of AR worked and popped over to the Rails github repo and quickly glanced over the details and had no problem understanding it.
You are entitled to your own opinion, but from the outside, it looks like you are just not familiar with ruby.
I think most people including many Rails proponents would agree that Rails has a huge emphasis on "magic" compared to other frameworks. It's a feature. Convention over Configuration implies magic and that is one of Rails' most famous tenets.
Love it or hate it, magic is Rails' modus operandi
There must be a reason that Ruby dropped few places on Github's Octoverse 2018.
While I was never against Ruby, every time has its tools, it was the culture of the Ruby community which I didn't like. Being a Rubyist was always a good excuse to not help on the frontend or help with some devops.
Now they escape into Elixir which is the next good academic excuse to not help with the frontend because React is so working class...
I get that you are new here, but this place isn't big on shitposting.
https://apidock.com/ruby/Hash/flatten
Which doesn't recursively flatten like Array#flatten, even when depth is specified. To me, most of these choices are arbitrary or done for performance reasons which get less compelling with each passing year.
I never know from one day to the next which new concept is going to be thrown at me, or how much I'm going to have to memorize. Whether it's Rails, or Rspec, or any other gem - each has its own ecosystem of technobabble that can't be derived from first principles.
In the end, I don't know what problems Ruby is trying to solve. I find it no faster to write than PHP or Javascript. I find that having multiple ways to specify blocks with begin/end and {} merely increases the permutations I must hold in my head as I'm trying to grok code. This is all very perl-like, which makes sense for a 90's language. But I wouldn't advise learning Ruby or using it in production today. Better to go with a more formal language such as Go/Rust/Swift/Kotlin, even though each of those has its own unique set of flaws and pain points.
P.S. If you are struggling with learning Ruby, I highly recommend learning PHP/Laravel first. It has most of the same concepts as Rails/.NET but builds on the existing context that C-style language programmers tend to be familiar with. Then from there you can create a virtual errata document in your mind to store any arbitrary conventions that Rails introduces.
And finally reached Sinatra, then Roda and love prevailed! Along the way, discovered and enjoyed working with so many gems both in Ruby as well as part of it's packages!
So, after 13 years now, I'm glad I chose the right language. A language which always asks, is there a simpler, more beautiful way to do the same thing?
So, Happy birthday, and thank you.
I’m certain my level of mastery contributes to my enjoyment. And it’s not that I don’t like learning new things, I do! But Ruby is just an absolute pleasure to write, and it’s hard to imagine spending 8+ hours a day living in any other ecosystem.
Huh, I sure think it is. I wonder what the author thinks the competition might be? Ruby has its issues for sure, but aesthetics ain't one of them - far and away my favourite out of any major language.
I think he meant beautiful in the conceptual sense (e.g. a beautiful algorithm) not the aesthetic sense.
Aesthetically speaking, Ruby would definitely be in my top 3 and possibly first. For me its main competition is ML-syntax languages, in particular Standard ML and F#.
Let's do a mini code challenge in the thread -- implement fizzbuzz in the most beautiful way you can, in the most beautiful language you know:
[1] https://codegolf.stackexchange.com
Off-topic, take a look at "Add a language to Polyglot" which was concluded at 194 languages, but people kept adding more: https://codegolf.stackexchange.com/questions/102370/add-a-la...
public static void main(String[] a) {
for(int n=0; n++<100;) System.out.println(new String[]{String.valueOf(n), "Fizz", "Buzz", "FizzBuzz"}[-n%3 >>> 31 ^1 | -n%5 >>> 30&2 ^ 2]);
} (defn fizz-buzz [n]
(map #(cond (= 0 (mod % 15)) "FizzBuzz"
(= 0 (mod % 5)) "Fizz"
(= 0 (mod % 3)) "Buzz"
:else %)
(range 1 n)))Edit: Here is a Racket equivalent
(define (fizz-buzz start finish)
(for-each (λ (i) (println
(cond ((= 0 (remainder i 15)) "FizzBuzz")
((= 0 (remainder i 5)) "Fizz")
((= 0 (remainder i 3)) "Buzz")
(else i))))
(range start finish)))
(fizz-buzz 1 101) (def fizzbuzz-nums (range 1 101))
(defn fizz? [n] (zero? (% n)))
(defn buzz? [n] (zero? (% n 5)))
(defn fizzbuzz? [n] (and (fizz? n) (buzz? n)))
(defn fizzbuzz [n]
(cond (fizzbuzz? n) "FizzBuzz"
(fizz? n) "Fizz"
(buzz? n) "Buzz"
:else n)))
(def fizzbuzz-list (map fizzbuzz fizzbuzz-nums))
(apply println fizzbuzz-list)But this brings up a debate I've been having with some folks. I have the memory of a gnat, so I can't keep a lot of context in my head. I prefer the previous two examples to this one, simply because with this one, I have to remember a lot more contextual vocabulary.
It's a pet-peeve of mine to pull up a source file, and then have to ping-pong around between 50 different function calls, when the entire thing could have been written linearly in fewer than 50 lines of code.
On the other hand, small functions like yours are easier to verify at a glance and move on. I haven't figured out what the right trade-off is.
Anyone else want to weigh in on this conundrum?
* Is a common idiom in the code base / same logic used in multiple places
* Has "sufficient" complexity
* Can be replaced with a good name that is generally clear with what it will achieve
For Slackwise's example, I think that the names used in the abstractions are exactly what I would use, but I also think that they're not really descriptive enough. If I wasn't the original author and thought I should refactor the names, I would probably try to choose divisible-by-3?, divisible-by-5?, and divisible-by-15? because what the hell is a fizz or a buzz anyway? Maybe you had already thought about all of this and wanted a deeper response; sorry to disappoint.
print(" ".join("FizzBuzz" if i % 15 == 0 \
else "Buzz" if i % 5 == 0 else "Fizz" if i % 3 == 0 \
else str(i) for i in range(1, 101)))
FizzBuzz in Python with nested conditional expressions and a generator expression:
https://jugad2.blogspot.com/2018/12/fizzbuzz-in-python-with-...
Not claiming its the best in any way, just a way that I thought of.
2. Why are you interpreting what he (or she) meant? Let them do it themselves.
3. I qualified my earlier comment as saying that it is not necessarily the best way - up front.
4. Beauty is in the eye of the beholder, and beholders vary a lot in their tastes, whether programmers or non-programmers. Like the "de gustibus" quote:
https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandu...
So chill, pal.
['fizz' unless i%3] + ['buzz' unless i%5] or i for i in [1..100] 1.upto(100) do |n|
puts [ ("Fizz" if a = (n % 3).zero?), ("Buzz" if b = (n % 5).zero?), ( n unless (a || b) )].join
end module FizzBuzz
def to_fb
s = ''
s << (self % 3 == 0 ? 'Fizz' : '')
s << (self % 5 == 0 ? 'Buzz' : '')
s << self.to_s if s.empty?
return s
end
end
Integer.include(FizzBuzz)
1.upto(100) { |i| puts i.to_fb }Edit to add: Actually, now that I think about it, using method_missing would have been even better!
But the edit window had passed by the time I changed it.
(1..100).map { |i| i.modulo(15).zero? && "FizzBuzz" || i.modulo(3).zero? && "Fizz" || i.modulo(5).zero? && "Buzz" || i } #!/usr/bin/env ruby
puts((1..100).map do |n|
"#{:Fizz if (n % 3).zero?}"\
"#{:Buzz if (n % 5).zero?}"
.then
.find { |s| !s.empty? } || n
end) (1..100).each do |n|
a = String.new
a << "Fizz" if n%3 == 0
a << "Buzz" if n%5 == 0
a << n.to_s if a.empty?
puts a
end
I changed it to a relatively KISS and IMO genuinely beautiful version in the parent, for others' benefits here's the version you were referring to in the above comment:
#!/usr/bin/env ruby
# frozen_string_literal: true
module FizzBuzz
Integer.include self
def self.array(enumerable = 1..100)
enumerable.map(&:to_fizzbuzz)
end
def to_fizzbuzz
"#{:Fizz if (self % 3).zero?}"\
"#{:Buzz if (self % 5).zero?}"
.then
.find { |s| !s.empty? } || to_s
end
end
puts FizzBuzz.arrayElixir (with static type analysis) - gets a bit of an edge, IMO, thanks to pipes, which are way prettier than .then:
defmodule FizzBuzz do
@spec fizzbuzz(integer)::String.t
def fizzbuzz(int) do
cond do
rem(int, 15) == 0 -> "FizzBuzz"
rem(int, 5) == 0 -> "Fizz"
rem(int, 3) == 0 -> "Buzz"
true -> inspect int
end
end
end
1..100
|> Enum.map(&FizzBuzz.fizzbuzz/1) #[0]
|> Enum.join("\n")
|> IO.puts
#[0] function variables are a very slightly "ugly
#syntax" part of the language due to erlang legacy
Compare from the official (but as a user you get these docs too):
https://ruby-doc.org/core-2.6/Array.html
https://hexdocs.pm/elixir/List.html#content
But again, it's only a bit prettier. Of course, if you try to browse both on mobile, Elixir wins handily. This is great for when you have to use the bathroom at the same time as you're in the middle of debugging and need to look up what a library module member function does, so there's some developer benefit edge too.
The IO.inspect(value, label: "label string") semantic is incredibly powerful. During debugging I often do this:
value
|> IO.inspect(label: "A")
|> do_something
|> IO.inspect(label: "B")
|> do_something_else
|> IO.inspect(label: "C")
...
# don't really know what IO.inspect is doing
# but guessing something like this?
def IO.inspect(value, label:)
puts "#{label}: #{value.inspect}"
value
end
value.pipe do
IO.inspect(label: "A")
do_something
IO.inspect(label: "B")
do_something_else
IO.inspect(label: "C")
end 1..100
|> Enum.map_join("\n", fn
int when rem(int, 15) == 0 -> "FizzBuzz"
int when rem(int, 5) == 0 -> "Fizz"
int when rem(int, 3) == 0 -> "Buzz"
int -> inspect int
end)
|> IO.puts (1..100).each { |n| { 15 => 'FizzBuzz', 3 => 'Fizz', 5 => 'Buzz' }.find { |d, s| n % d == 0 }.then { |_, s| puts s || n } } [case (n `rem` 3 == 0, n `rem` 5 == 0) of
(True, False) -> "Fizz"
(False, True) -> "Buzz"
(True, True) -> "FizzBuzz"
(False, False) -> (show n)
| n <- [1..100]
]"I came across Ruby in 1998 because I was an avid reader of comp.lang.misc (ask your parents). I downloaded it, compiled it, and fell in love. As with any time you fall in love, it’s difficult to explain why. It just worked the way I work, and it had enough depth to keep me interested.
"Fast forward 15 years. All that time I’d been looking for something new that gave me the same feeling. Then I came across Elixir, a language by José Valim, that puts a humane, Ruby-like syntax on the Erlang VM."
So while he loves Ruby he's mostly moved on to Elixir, which he loves partly because of how it builds on the ideas in Ruby.
By chance I had to do a programming class in college, and they had put me into the wrong one by accident - a final year software project in Ruby. I did really well at it, fell in love with the language and got into other programming languages from there.
I've been doing Ruby for 12 years now and it's my go-to language when I can choose. My entire programming career has Ruby to thank.
10 years later I was thoroughly sick of that, so started to look around and heard about this little language called Ruby - and it was love at first sight. Then this little software project called Rails started to gain momentum and there was no looking back. 13 or so years and counting.
And now funnily enough just when I feel like Ruby is lacking a few necessities in our always-connected world, along comes a project which is basically reworking Erlang to look a whole lot more like Ruby - Elixir. I'll always love Ruby but Elixir feels right for the next step, that kind of instant attraction I never felt for the likes of golang. Here's to the next 13 or more years of Ruby-like programming joy!
I never understood this argument. That "superficial" syntax is what I have to stare at, reading and writing, for 8 hours a day. That I actually enjoy doing so is therefore hugely important to me.
I mean, you can make the same argument against Elixir itself, and I've seen it done - Erlang old-timers arguing against the necessity of these "superficial" syntax improvements. Suffice to say that I profoundly disagree.
Matz himself said something similar about Emacs / Lisp [1]:
> Emacs made me realize anything can be changed by a programmer...Emacs taught me freedom for software...Emacs has changed my life
[1] http://ergoemacs.org/emacs/Matz_Ruby_how_emacs_changed_my_li...
Once I learned Ruby, the fog parted and everything started making sense. Compared to JS, Ruby was transparent. Everything was just a bunch of objects sending messages back and forth to one another. The simplicity of defining classes and methods made it easy to think about how a program could model aspects of the real world – domain modeling, abstraction, etc. One early experiment I recall was using Ruby's built-in Enumerable and Comparable modules to represent a deck of playing cards in code (complete with > and < methods which respected suit, royalty, etc) – this was a real "aha" moment in my learning process.
Reading code written by others was much more straightforward (making it easy to learn from the masters), and writing extensions/plugins to existing tools to add features that I needed suddenly became feasible. Books like David Black's "The Well Grounded Rubyist" and Sandi Metz' "Practical Object Oriented Programming in Ruby" were great, accessible introductions to the art of programming.
I don't write much Ruby any more, but I'm in total agreement with Dave Thomas here. Ruby for me was the "royal road" into learning how to program, and it continues to inform the way I think and write code in other languages. As a non-CS person, I can't think of a more accessible way to learn about software development.
> (OK, I just made that up)
I liked it :).
Dave Thomas's Programming Ruby was a fixture on my office desk for a decade. One of the best programming books I've ever read, with a fantastic reference section (built from Ruby's own excellent baked-in docs), my copy is well worn, and I still find reasons to dig it off the shelf from time to time.
I can't give enough Kudos to Matz, Dave, and the rest of the Ruby community for bringing this language into my life. The community they've built is truly amazing, and the language has endured even as it's grown with far fewer bumps and jolts as compared to other similar languages over the same time period.
In summary, quite simply amazing! Happy Birthday, Ruby!
love it.
After that, I moved to Groovy, which seemed like a nice middle ground between Ruby and Java, or as I called it at the time: Java as it should have been.
I don't hear much about Ruby and Groovy lately, and while I focused more on front-end development, my back-end work rolled back into Java, which, I admit, has gotten slightly less painful with Java 8. At least in some ways; in other ways, it's just become an even bigger mess where some parts are sensible while other parts are dragging the weight of decades of poor choices with them.
I hear Kotlin is nice, though.
My Ruby skills have gotten a bit stale, sadly. The last thing I did with it was in 2013 I think, when I ran into trouble with Ruby's handling of unicode.
They've been overtaken by Python and Kotlin, respectively, as developers' first choice of programming language. Kotlin even runs on Android and natively, whereas Apache Groovy is limited to the JVM.
> I ran into trouble with Ruby's handling of unicode
Ruby's developed mainly in Japan, and Japan's the last holdout in the world against the widespread use of Unicode.
Would love to have optional some kind of optional typing. Has anyone tried any of these? https://github.com/soutaro/steep https://github.com/plum-umd/rdl
Any other suggestions?
The routing system in Rails is definitely a DSL. You might say that defining model properties was a DSL. You can probably call an ORM query interface a DSL. The controller and view layers are going to look like just about any other framework. Rails is a full-featured framework, which can be configured with a minimum of fuss, bother, and actual code-writing. For toy apps I don't think there's anything else that's faster for development, and for real apps I'm pretty sure that all frameworks are roughly equivalent.
There are Ruby projects which do provide a "DSL for web apps", of which I believe Sinatra is the most popular. Rails incorporates some DSL-like features, and I would agree with anyone who said that it "is basically a DSL for web apps", but I would consider that a figure of speech.
On the other side of the world, Ruby has many adherents in the embedded development world. A large number of the Japanese talks are about mruby and that has motivated many of the last few years of the languages' improvements.
I think the focus on Python these days has more to do with the fact that it's often the language people learn first these days, and the fact that it has effectively supplanted Perl as the swiss army chainsaw of scripting languages. I think Javascript is popular due to the fact that it is essentially the native scripting/programming language of the modern web (or at least it will be until WebAssembly really catches on), and the ridiculous preponderance of decent frameworks that are out there now for that language.
I think Rails is the obvious choice for backend apis these days. It's robust, takes care of most of the hard stuff, saves you time and mistakes. Use whatever you want for frontend (React for me) in tandem with it. Many of the job postings I've seen have listed Rails + React.
It used to get accused of scaling poorly, but tell that to Github, Gitlab, and other large-scale sites with millions of users. It's true that bad Ruby is slower than bad Java, but the solution is to write cleaner code.
I know this was all about Rails. I use Ruby for scripting work as well, and it's enjoyable to use.
I've worked on one such large-scale enterprise-level web app, and it really does scale poorly in some areas, specifically database management. ActiveRecord tends to get extremely expensive when db's take on large amounts of records and complex relationships start forming between those large tables. You need VERY good software engineering practices and understanding of which choices will utterly kill you down the line in terms of performance when using this ORM, and it's hard to see those consequences at the outset due to the fact that Rails code is so easy to pick up and understand.
```
User.joins("left join ponies on ponies.user_id IN (select id from foobars where user_id=users.id").group("so_funny").count
or I could have a policy to avoid joins at all cost and reject any commit that uses a join and get fun things like:
```
users = User.all # all fucking hell
JSON.parse(HTTP.get("http://your-things.json"))['results'].select {|r|
users.detect {|u| u.id == r['user_id'] } # for realz??
}
[edit]: cause formatting
This is compounded by the fact that ActiveRecord obfuscates much of the sql code you posted above (not always, but in many cases). When a user new to Rails goes in and sees "Oh, all I have to do to set up foreign key relations is to just say this model belongs to this other one? NICE!", it isn't immediately clear what the implications of whats happening under the hood to accommodate that are, and all of the ways which this can quickly be misused to cause a huge performance bottleneck. That syntactic sugar smooths over some of the pitfalls of efficiently interacting with a relational DB.
It's important to note that these things do not make ActiveRecord a bad ORM in and of itself, as many users will not build projects large enough to have to worry about such bottlenecks, but it CAN and DOES cause problems when projects get larger and have to start taking on overhead from the resources allocated for all those records. That is what people are complaining about when they mention Rails doesn't scale well (or at least one of the reasons).
Yes, there are tools in ActiveRecord that can help mitigate some of the performance issues, but as I noted above, it's extremely easy to overlook such tools until you are too far down stream to really do much about it. The symptoms of not using such features may not show up until much later when the number of records swells, and some code someone wrote 2 years ago starts slowing down the whole shebang simply because they used a select rather than a pluck. This is ESPECIALLY true in large corporate web app environments where the number of records is large and the number of people with their fingers in the code base is equally sizable. And good luck convincing management to go back and fix old ORM tech debt until the whole thing starts falling apart at the seams.
Hell, pluck didn't even exist until 2012 with the release of 3.2.1.
What's a lot harder to deal with is AR callback hell, which can be very slow if you have enough nested callbacks, and can be really hard to fix without breaking everything. Using many AR callbacks is just a bad idea for a big app!
For a programming-community this is very very bad. Programming is not only about the language itself, but also the libs, frameworks, tools, and that's what most enytrys about python or javascript are. When the community of Ruby on a nerd-meltingpot already is so low that they hardly share any content, then how much less recognition will they receive in more mundane and conservative communities?
Now less recognition will mean less new users, less new libs/frameworks/tools&support. Over time the existing users will move away or just die, which means the decline has started.
>The first public release of Ruby 0.95 was announced on Japanese domestic newsgroups on December 21, 1995
Have you looked at the array_* methods in PHP?