Need advice about which tool to choose?Ask the StackShare community!
Racket vs Ruby: What are the differences?
- Syntax: Racket uses prefix notation which means the operator comes before the operands, while Ruby uses infix notation where the operator is placed between the operands. This difference in syntax can affect the readability and writing style of the code.
- Type System: Racket is a statically typed language, meaning variables are assigned data types at compile time and checked for type errors before execution. In contrast, Ruby is a dynamically typed language where variables are assigned data types at runtime, allowing for more flexibility but potentially leading to more runtime errors.
- Metaprogramming: Ruby has a strong focus on metaprogramming, allowing developers to write code that can modify itself or create new code at runtime. Racket, on the other hand, does not have as robust metaprogramming capabilities.
- Community and Ecosystem: Ruby has a larger and more active community compared to Racket, with a vast array of libraries and frameworks available for various tasks. Racket, while growing, has a smaller community and ecosystem.
- Concurrency: Racket provides built-in support for lightweight green threads, allowing for easy concurrency and parallelism. Ruby, on the other hand, relies on external libraries or tools for handling concurrency effectively.
- Purpose: Racket is primarily designed for academic and research purposes, with a focus on functional programming and language design. Ruby, on the other hand, is more suited for web development and is widely used in the industry for building web applications.
In Summary, Racket and Ruby differ in syntax, type system, metaprogramming capabilities, community size, concurrency support, and target purposes.
In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.
To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.
Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.
For us it came down to C#, JavaScript, and Ruby. At the time we owned our infrastructure, racks in cages, that were all loaded with Windows. We were also at a point that we were using that infrastructure to it's fullest and could not afford additional servers running Linux. That's a long way of saying we decided against Ruby as it doesn't play nice on Windows.
That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.
We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.
As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.
In December we successfully flipped around half a billion monthly API requests from our Ruby on Rails application to some new Python 3 applications. Our Head of Engineering has written a great article as to why we decided to transition from Ruby on Rails to Python 3! Read more about it in the link below.
When I was evaluating languages to write this app in, I considered either Python or JavaScript at the time. I find Ruby very pleasant to read and write, and the Ruby community has built out a wide variety of test tools and approaches, helping e deliver better software faster. Along with Rails, and the Ruby-first Heroku support, this was an easy decision.
Pros of Racket
- Meta-programming3
- Hygienic macros3
- Pattern matching2
- Module system2
- Beginner friendly2
- Fast2
- Gradual typing2
- Nanopass compiler2
- Extensible2
- Racket Macro system2
- Cross platform GUI2
- Macro Stepper2
- Built-in concurrency2
- Built-in parallelism2
- Functional Programming2
- Open source2
- Language-oriented programming2
- FFI2
- Great libraries2
- Beautiful code2
- Rapid development2
- Racketscript1
- Great community1
- Typed Racket1
- IDE1
- Good documentation1
Pros of Ruby
- Programme friendly605
- Quick to develop536
- Great community490
- Productivity468
- Simplicity432
- Open source273
- Meta-programming234
- Powerful207
- Blocks156
- Powerful one-liners139
- Flexible69
- Easy to learn58
- Easy to start51
- Maintainability42
- Lambdas37
- Procs30
- Fun to write21
- Diverse web frameworks19
- Reads like English13
- Makes me smarter and happier10
- Rails9
- Very Dynamic8
- Elegant syntax8
- Matz6
- Object Oriented5
- Programmer happiness5
- Elegant code4
- Generally fun but makes you wanna cry sometimes4
- Friendly4
- Fun and useful4
- Easy packaging and modules3
- There are so many ways to make it do what you want3
- Primitive types can be tampered with2
Sign up to add or upvote prosMake informed product decisions
Cons of Racket
- LISP BASED2
- No GitHub2
Cons of Ruby
- Memory hog7
- Really slow if you're not really careful7
- Nested Blocks can make code unreadable3
- Encouraging imperative programming2
- Ambiguous Syntax, such as function parentheses1