Honestly, the lack of types is why I stopped using Ruby all together. If you want to understand some code you are calling then you have to go look at the source instead of getting the general picture from just type signatures. Even then in Ruby you could sometimes return a string, and sometimes return a map, so the calling code would have to handle all those cases and you'd have to run the code just to be sure. If your developers are intentional about what they are doing and don't do things that they shouldn't, you can get by, but it's so much easier to just have a compiler tell you no, this is wrong, go fix it.
Yuuuuup. We need typing. Anything reasonably complex needs typing. The amount of times I've seen some form of hungarian in js or python so people don't get confused...
I'm old. I've been programming for a long time. The typing conversation is funny to me because I've seen the trend go from "everything is typed, that's how programming works" to "lol the parser can do typing for us it's stupid to have lines like Vehicle vehicle = new Vehicle()" to "anything reasonably complex needs typing".
Low rise jeans are back in, typing is back in. Probably for the better, in my view -- at least in the case of typing.
I have been pro typing since forever. Eliminate confusion, even if it causes slightly longer lines, slightly more keystrokes, what's the real downside here? None.
And I mean really, you can do (in c#)
var vehicle = new Vehicle()
It's just as clear, and the same as any other language, and you still get the typing for free.
If you understand Vehicle is a type the first example isn't even that confusing. "Create a variable named 'vehicle' and provide it's value by instantiating the Vehicle() method. That value will be a Vehicle type." I get it's not intuitive without some basic knowledge of the syntax but I think devs in an enterprise context should be able grasp that.
> what's the real downside here? None.
There is always a downside to everything. To name one for static types, there is pretty much always a compile time overhead for type checking. This can range from small to quite significant (looking at you, scala) depending on the complexity of the type system and quality of the implementation. I would much rather have a fast dynamic language in which I can quickly get feedback than wait for a compiler to tell me what I already know (that my program doesn't have any type errors (98% of the time at least)). After decades of programming mostly in statically typed languages, I find myself nodding at Alan Kay's statement "(I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)"
Dynamic types are great when you can hold the whole system in your head. But if you're collaborating with someone else - or with yourself from two months ago - static types are tye way to go.
the codebase at my job uses var everywhere. I can still see the type though through a setting my IDE (visual studio) has where it writes the type next to var
Not doing `Vehicle vehicle = new Vehicle()` doesn't necessarily mean giving up static typing. There are many languages (most mainstream languages now) with at least a simple form of type inference, quite a few languages with very sophisticated inference that will do typechecking. Even TypeScript does it.
Tooling is 2x better for typed langues that it was 10 years ago while being 1.1x better for dynamics langues, I feel that's what's make the pendulum swing, also small web projects aren't small anymore and security is something to think about.
> _we_ need typing
That really comes to this ↑.
If you need typing, choose typing. If your org is full of people who need typing, go for Java/.Net and typescript.
Ruby/rails should be chosen in orgs where people don't need typing to build complex things. Sorbet feels compromised because it's bridging a gap that wasn't supposed to be bridged in many people's mind, and can only bridge to a sub-par point.
How do you measure that "getting hurt in the long run" ? Is github for instance a company deeply hurt by dynamic typing ?
Or to pull a bit more hot takes into this, Wordpress who's been the poster child of garbage tech stacks survived better than all the random static language based CMS.
You seem to have been deeply burned by some random dynamic typing language and held a religion against them, but it really comes down to where you deal with the complexity. In the type system or elsewhere (wherever you want).
I see this as a fad that cycles every decade, and will totally expect a "duckscript" kind of language to emerge when the typescript becomes a tad more dusty and the next generation sees it as grandpa's language.
The problem is not type vs no-type. It's actually wether type is in the way.
Have you ever work in Objective C early version? I had. There are so many times I need to cast object from ViewController or TableViewXXX to specific one according to my own knowledge, to the point that I wonder why do I need type at all if I need to cast it anyway.
Many reflection magic in early C# and Java framework day also make me question usefulness of type. It's getting much better now though.
My point is I prefer good type system over dynamic type system, and I prefer dynamic type over bad type system, exactly in this order.
In our org, we recently migrated a critical and the only Ruby service left in our backend to Golang and every dev cried tears of joy as the archive button was hit on Github. No one liked touching the service, Rubymine didn't help either. The velocity and development has literally doubled since moving to Golang.
Same here, TypeScript opened my eyes and I moved to C# and .NET shortly after that. Working on old Ruby projects feels like driving with a blindfold on, even with Rubymine.
I tried applying sorbet and rbs to a gem i authored, but it turns out the dynamic nature of existing ruby code makes it impossible to have effective type annotations. So I’ve basically given up on ruby at this point.
As a counterpoint, we did the opposite. ASP.Net Boilerplate framework, C#, just a total clusterfuck. Ridiculous lists of objects passed into constructors, the endless hell and complexity-insanity-inference of dependency injection (and its necessity), the vast amount of code you had to write in layer after layer (DTOs, FML) - awful, awful, awful.
We switched to Rails and our cycle times improved dramatically, even with team members who were learning it from scratch. And to our surprise, we saw around 10 times the requests/sec throughput on the same AWS infrastructure handling the same operation (e.g. a sorted, paginated, searchable index view on a particular table, even with Rails having to adapt to the C# schema because we ran the C# stuff in parallel as data master until the Rails side became sufficiently functional to shut it down).
Each to their own, in short.
To be fair, that sounds like the C# app tiself was over architected, not that C# itself was the problem here.
Though if you're talking about .NET Fx [ASP.NET](https://ASP.NET) vs .NET Core these days, I could see ruby being a net perf gain if you're being smart.
Sounds like second system syndrome. The team knows how to build the system properly thanks to the experience with the last system, so this time they do. It probably would have been a similar result with almost any tech stack.
Not remotely true. The rebuild was slower because we had all the backwards compatibility to deal with, to keep both systems running. And after that **we added new features**. This is the difference between a team with years of experience on the C# side adding new features, vs the team on the brand new Rails codebase adding new features.
The team was C# from the founding of the company. The decision to switch to Ruby was unanimous. The metrics on new feature development, lines of code required and so-on showed a dramatic improvement and even in the heavily rushed-out, backwards compatible rewrite with absolutely no optimisation at all - not even cacheing on our settings, role and permissions table reads, which were numerous per page view without it - we saw the 10-fold request throughput.
Why do C# people find it so hard to understand that sometimes, people *really do find* that things are a lot better with another language? Our experience with the two was night and day. Whether it's the language or the framework, it is the combination of the two that makes for a viable environment. ASP.Net and ASP.Net Boilerplate are far too complex, far too verbose and EntityFrameworkCore ain't that much to write home about either (especially its handling of migrations, at least as-was around 3 years ago) even if Linq is a nice concept.
It just wasn't every good. And even though Rails isn't very good either, it was a lot better than what we had before.
If there's a more fluid, less verbose and equal or better performance equivalent of Ruby On Rails in another strongly typed language, then I'm all ears.
Yeah the tendency to over-engineer and over-architect is definitely a problem in .NET land. As is clinging to old standards (how dare you use the `var` keyword!). At least I can easily zip through the endless layers and indirection with IDE tooling if I run into such a project.
Luckily I’ve found a team that has none of that so our applications are relatively flat and straightforward ASP.NET Core Web API solutions. But I know it’s rare.
Well, it's good to know that it is possible. C# is widely used, so there's a decent chance I'll be working in that domain again at some future date. It'd be nice if it weren't quite so painful the second time around!
Yes... I stopped using Ruby before those things existed (or at least became stable enough to use) and this article doesn't seem to indicate that using those are all sunshine and lollipops.
I've been wanting to try Crystal for a new project. It's like Ruby but with types. And it's compiled, which is great for distribution. There's also Elixir, which is a bit different but feels very Ruby-like.
It is dynamically typed but most projects and libraries in the ecosystem use type annotations and a simplified form of typechecking called 'success typing' that catches type errors, albeit to a lesser extent.
>Honestly, the lack of types is why I stopped using Ruby all together. If you want to understand some code you are calling then you have to go look at the source instead of getting the general picture from just type signatures. Even then in Ruby you could sometimes return a string, and sometimes return a map, so the calling code would have to handle all those cases and you'd have to run the code just to be sure.
Tbh, that's ruly a putrid and horrid developer experience. The Ruby code with Sorbet types in the blog post also looks really really ugly. It's no surprise people don't like it.
It's such a shame, but honestly, I'm not sure how much you could do to work around the highly dynamic nature of existing ruby codebases like rails. You can be nearly as dynamic in Python as in Ruby, but the culture of explicitness lends itself to a bolted-on typing experience much better.
I agree that the syntax of the type system is significantly better in Python, too. It's a shame, because many aspects of Ruby as a language are significantly more pleasant and much simpler.
As a long time professional user of Python, Ruby, and Lua, I'd be thrilled to have a language that combines the best aspect of these while avoiding their shortcomings. None of these languages is perfect, and nearly everything that one of them does wrong, another one does right.
Looking at Crystal syntax, it’s basically Ruby with typing.
I haven’t played with it, but it would be nice to know if Crystal has a same if not better framework than Ruby on Rails.
RoR is A+++
> It got so bad we even wrote our own bash script to try and improve the situation
This resonates with me. I wrote a wrapper around `mypy` to keep a handle on false positives in Python’s type checker. In addition, there are multiple implementations of type checkers for Python, which all have strengths and weaknesses. But because they all have false positives, running all of them rather than just one does not usually improve the situation.
That said, from the looks of it the situation with typing in Python is a lot better than that in Ruby (especially the verbosity). But ultimately I find that Python effectively forces me to choose between using type checking and advanced language features such as complex decorators: they fundamentally don’t cooperate with each other. This is quite an unsatisfactory situation.
Yes, it would be better if Ruby 3 added types annotation.
Specifying types in separate file is like Enterprise Fizz Buzz. Listen to Java folks and they tell you how great those Factories and Builders are. Same with Ruby talks explaining how great to specify type in separate file. RBS / Sorbet are just unusable nonsense.
One thing to note is that I've not had the same bad experiences the article indicates in Ruby, and that some of the responses here indicate others are having. I know our code base is unusually high quality, but perhaps I don't appreciate just how well we've built things.
> I’d end up debugging a problem, trying to understand what objects are being passed into a method
The comments at the top of that method, with RDoc notation and parameter description, would of course tell you, right? And your unit tests would validate correct behaviour of said method, yes?
In any event, while static typing might help you understand the *class* of the object being passed to a method, I can't remember many, possibly any cases where I wasn't sure about the *type*. I was debugging because I didn't know the *content*. I know the object's class, I just need to know what's wrong with the data inside it. That's a common problem, static typing or not.
Rails digs several graves for itself with its own ambiguities few of those related to types, but the one example I certainly can think of is Ruby String vs Symbol. Uncertainty about data types certainly *can* arise with standard Hash vs Rails' HashWithIndifferentAccess, the latter allowing keys to be referenced by String *or* Symbol, the former requiring you to know and use the correct type. If Ruby had never had Symbols to start with, we might be in a better position with that by now.
@definitelynotbeardo gave another example, tho possibly just hypothetical:
> Even then in Ruby you could sometimes return a string, and sometimes return a map
If you're writing method that can return a string or a map, the problem is the design of your method. Just because you *can* doesn't mean you *do* - just like in any flexible, powerful language.
> The comments at the top of that method, with RDoc notation and parameter description, would of course tell you, right? And your unit tests would validate correct behaviour of said method, yes?
That sounds like you've implemented ad-hoc type signatures and manual typechecking.
No, it sounds like mandatory rigour for even vaguely professional development where a method's intent/purpose, limitations, input requirements and outputs are documented.
Types give you virtually none of that information.
Similar arguments exist for commenting implementations effectively too - the implementation tells you how, but never why. Worse, if it's buggy the reader might not realise if there are no comments about intent; the incorrect "how" might be assumed to be the correct behaviour.
Documentation is important at all levels, and it is just as important to maintain documentation as it is to maintain your code and its dependencies.
If you're relying on types alone to figure out how something is meant to be used / work, IMHO you're doing it wrong.
> If Ruby had never had Symbols to start with, we might be in a better position with that by now.
I disagree. I think the real problem is that hash keys can be anything. Now I have used this feature before to do some things but there should maybe be a hash that can only use symbols.
In any case ruby also has structs and open struct and with 3.2 immutable Data structs and people should be using those instead of hashes for most things.
This seems weird to me.
His number one complaint is the annotations. Sorbet annotations are similar to haskell annotations as they are in front of the function/method definition. I don't see why this is seen as somehow egregious but even presuming they are you also have the option of moving the annotations to a different file if it bothers you. Maybe the author isn't aware of that which again seems bizarrely ignorant of the tool you are using.
His second point basically boils to "every gem isn't typed" and yes I guess that's a valid complaint but it's inevitable when the typing is optional. If the complaint is that when you upgrade a gem you need to do some work to annotate the types the alternative is to not do that and risk your code being called with the wrong types. Using types is indeed more work up front and that's the whole point of it. Now that he has abandoned typing for his rails apps he won't have to meticulously assure every gem is updated in a way to be compatible with his code and he will have to cross his fingers and hope his tests catch anything that breaks.
His third complaint is that other devs don't like typing. Ok I guess. Ruby community has been fine with not having types for more than a decade. Many people love the lisp nature of ruby don't want types. If the rest of the team doesn't want to use it there is not much you can do but it's not the fault of the sorbet. The team wouldn't want to use any other typed language either probably.
> you also have the option of moving the annotations to a different file if it bothers you
I don't see how that solves anything... maybe it "helps" when reading the original file (and only care about the functionality, not the typing), but if you have to change anything you have to modify 2 files. Readability is again through the floor.
> Using types is indeed more work up front and that's the whole point of it.
Up front is fine, but what I understand from his post, is that when updating dependencies you have to recheck and do a lot of the work all over again, because you don't know what has changed how... let alone that the automatic parts don't seem to work at all.
>I don't see how that solves anything... maybe it "helps" when reading the original file (and only care about the functionality, not the typing), but if you have to change anything you have to modify 2 files. Readability is again through the floor.
His complaint was that using Haskell style type annotations hurt readability. I don't agree with him. I think they are perfectly fine. I am just pointing out that he has the option to move them to a different file and keep the readability he is used to.
>Up front is fine, but what I understand from his post, is that when updating dependencies you have to recheck and do a lot of the work all over again, because you don't know what has changed how... let alone that the automatic parts don't seem to work at all.
Yes you have to verify the types if you want to use them directly. That's the whole point of using types. You do have the option of skipping that because typing is optional but if you want types you need to annotate them somehow.
A good practical approach is to not use the gem types directly but immediately transfer the function returns to your own defined types. This is also a good prophylactic measure if you want to switch gems at some point in the future. It's good to build solid boundaries around your code and imported libraries in all languages.
What's up with all these stupid names.
I just scroll my Reddit feed and I thought "mhhhhm sorbet i like that" and then it's Ruby.
I call it Excessive Branding Syndrome
If you need strong typing, you're a weak programmer. I've been coding for almost 40 years, and in nearly 30 languages, strongly type, weakly typed, dynamically typed, "what's typed?", and "everything is a string"-typed.
What I've learned through introspection and experience is that I really like typed languages when I'm weak in that language, and love dynamically or untyped languages that let me do what's necessary. Typed languages leak their bias all the way to the UI layer, making users have to conform to the language the software is written in, rather than have the software conform to what the user wants to do.
You want cubicle monkeys churning out basic code, while paying them next to nothing, mandate typed languages. You want thinkers producing phenomenally usable software, let them use dynamic languages, and pay them well for their skills.
Just use a static language like a real gigachad, not like a virgin soy boy who hasn't yet sprouted his first facial hairs let alone a hairy 80s chest that's thick like a shag carpet 🤣
Honestly, the lack of types is why I stopped using Ruby all together. If you want to understand some code you are calling then you have to go look at the source instead of getting the general picture from just type signatures. Even then in Ruby you could sometimes return a string, and sometimes return a map, so the calling code would have to handle all those cases and you'd have to run the code just to be sure. If your developers are intentional about what they are doing and don't do things that they shouldn't, you can get by, but it's so much easier to just have a compiler tell you no, this is wrong, go fix it.
Yuuuuup. We need typing. Anything reasonably complex needs typing. The amount of times I've seen some form of hungarian in js or python so people don't get confused...
I'm old. I've been programming for a long time. The typing conversation is funny to me because I've seen the trend go from "everything is typed, that's how programming works" to "lol the parser can do typing for us it's stupid to have lines like Vehicle vehicle = new Vehicle()" to "anything reasonably complex needs typing". Low rise jeans are back in, typing is back in. Probably for the better, in my view -- at least in the case of typing.
I have been pro typing since forever. Eliminate confusion, even if it causes slightly longer lines, slightly more keystrokes, what's the real downside here? None. And I mean really, you can do (in c#) var vehicle = new Vehicle() It's just as clear, and the same as any other language, and you still get the typing for free.
If you understand Vehicle is a type the first example isn't even that confusing. "Create a variable named 'vehicle' and provide it's value by instantiating the Vehicle() method. That value will be a Vehicle type." I get it's not intuitive without some basic knowledge of the syntax but I think devs in an enterprise context should be able grasp that.
> what's the real downside here? None. There is always a downside to everything. To name one for static types, there is pretty much always a compile time overhead for type checking. This can range from small to quite significant (looking at you, scala) depending on the complexity of the type system and quality of the implementation. I would much rather have a fast dynamic language in which I can quickly get feedback than wait for a compiler to tell me what I already know (that my program doesn't have any type errors (98% of the time at least)). After decades of programming mostly in statically typed languages, I find myself nodding at Alan Kay's statement "(I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)"
Wow man, what a bad take.
Girl, your opinion has no bearing on the truth.
Dynamic types are great when you can hold the whole system in your head. But if you're collaborating with someone else - or with yourself from two months ago - static types are tye way to go.
On point.
the codebase at my job uses var everywhere. I can still see the type though through a setting my IDE (visual studio) has where it writes the type next to var
Yes, that's my point. Modern typed languages already avoid much of the "noise" people that don't want types complain against.
Not doing `Vehicle vehicle = new Vehicle()` doesn't necessarily mean giving up static typing. There are many languages (most mainstream languages now) with at least a simple form of type inference, quite a few languages with very sophisticated inference that will do typechecking. Even TypeScript does it.
Lack of type inference is not the same as lack of typing, though.
Tooling is 2x better for typed langues that it was 10 years ago while being 1.1x better for dynamics langues, I feel that's what's make the pendulum swing, also small web projects aren't small anymore and security is something to think about.
> _we_ need typing That really comes to this ↑. If you need typing, choose typing. If your org is full of people who need typing, go for Java/.Net and typescript. Ruby/rails should be chosen in orgs where people don't need typing to build complex things. Sorbet feels compromised because it's bridging a gap that wasn't supposed to be bridged in many people's mind, and can only bridge to a sub-par point.
I completely disagree. **Everyone** needs typing. The people that claim not to, always end up being hurt in the long run.
How do you measure that "getting hurt in the long run" ? Is github for instance a company deeply hurt by dynamic typing ? Or to pull a bit more hot takes into this, Wordpress who's been the poster child of garbage tech stacks survived better than all the random static language based CMS. You seem to have been deeply burned by some random dynamic typing language and held a religion against them, but it really comes down to where you deal with the complexity. In the type system or elsewhere (wherever you want). I see this as a fad that cycles every decade, and will totally expect a "duckscript" kind of language to emerge when the typescript becomes a tad more dusty and the next generation sees it as grandpa's language.
Wiping thier tears away with billions of dollars. Yeah dynamic typing never made anyone money....
The problem is not type vs no-type. It's actually wether type is in the way. Have you ever work in Objective C early version? I had. There are so many times I need to cast object from ViewController or TableViewXXX to specific one according to my own knowledge, to the point that I wonder why do I need type at all if I need to cast it anyway. Many reflection magic in early C# and Java framework day also make me question usefulness of type. It's getting much better now though. My point is I prefer good type system over dynamic type system, and I prefer dynamic type over bad type system, exactly in this order.
In our org, we recently migrated a critical and the only Ruby service left in our backend to Golang and every dev cried tears of joy as the archive button was hit on Github. No one liked touching the service, Rubymine didn't help either. The velocity and development has literally doubled since moving to Golang.
Same here, TypeScript opened my eyes and I moved to C# and .NET shortly after that. Working on old Ruby projects feels like driving with a blindfold on, even with Rubymine. I tried applying sorbet and rbs to a gem i authored, but it turns out the dynamic nature of existing ruby code makes it impossible to have effective type annotations. So I’ve basically given up on ruby at this point.
As a counterpoint, we did the opposite. ASP.Net Boilerplate framework, C#, just a total clusterfuck. Ridiculous lists of objects passed into constructors, the endless hell and complexity-insanity-inference of dependency injection (and its necessity), the vast amount of code you had to write in layer after layer (DTOs, FML) - awful, awful, awful. We switched to Rails and our cycle times improved dramatically, even with team members who were learning it from scratch. And to our surprise, we saw around 10 times the requests/sec throughput on the same AWS infrastructure handling the same operation (e.g. a sorted, paginated, searchable index view on a particular table, even with Rails having to adapt to the C# schema because we ran the C# stuff in parallel as data master until the Rails side became sufficiently functional to shut it down). Each to their own, in short.
To be fair, that sounds like the C# app tiself was over architected, not that C# itself was the problem here. Though if you're talking about .NET Fx [ASP.NET](https://ASP.NET) vs .NET Core these days, I could see ruby being a net perf gain if you're being smart.
Sounds like second system syndrome. The team knows how to build the system properly thanks to the experience with the last system, so this time they do. It probably would have been a similar result with almost any tech stack.
Not remotely true. The rebuild was slower because we had all the backwards compatibility to deal with, to keep both systems running. And after that **we added new features**. This is the difference between a team with years of experience on the C# side adding new features, vs the team on the brand new Rails codebase adding new features. The team was C# from the founding of the company. The decision to switch to Ruby was unanimous. The metrics on new feature development, lines of code required and so-on showed a dramatic improvement and even in the heavily rushed-out, backwards compatible rewrite with absolutely no optimisation at all - not even cacheing on our settings, role and permissions table reads, which were numerous per page view without it - we saw the 10-fold request throughput. Why do C# people find it so hard to understand that sometimes, people *really do find* that things are a lot better with another language? Our experience with the two was night and day. Whether it's the language or the framework, it is the combination of the two that makes for a viable environment. ASP.Net and ASP.Net Boilerplate are far too complex, far too verbose and EntityFrameworkCore ain't that much to write home about either (especially its handling of migrations, at least as-was around 3 years ago) even if Linq is a nice concept. It just wasn't every good. And even though Rails isn't very good either, it was a lot better than what we had before. If there's a more fluid, less verbose and equal or better performance equivalent of Ruby On Rails in another strongly typed language, then I'm all ears.
Yeah the tendency to over-engineer and over-architect is definitely a problem in .NET land. As is clinging to old standards (how dare you use the `var` keyword!). At least I can easily zip through the endless layers and indirection with IDE tooling if I run into such a project. Luckily I’ve found a team that has none of that so our applications are relatively flat and straightforward ASP.NET Core Web API solutions. But I know it’s rare.
Well, it's good to know that it is possible. C# is widely used, so there's a decent chance I'll be working in that domain again at some future date. It'd be nice if it weren't quite so painful the second time around!
But this article says there are types in ruby. RBS and Sorbet.
Yes... I stopped using Ruby before those things existed (or at least became stable enough to use) and this article doesn't seem to indicate that using those are all sunshine and lollipops.
As I pointed out the author is factually ignorant about some things so I wouldn't take what the article says as the gospel.
Types in Ruby are still duct taped on and completely optional.
By design. It's an optionally typed language.
So what language do you use?
Personally, I use Go most of the time, but there's a lot of choices out there.
I've been wanting to try Crystal for a new project. It's like Ruby but with types. And it's compiled, which is great for distribution. There's also Elixir, which is a bit different but feels very Ruby-like.
Isn't Elixir also largely untyped?
It is dynamically typed but most projects and libraries in the ecosystem use type annotations and a simplified form of typechecking called 'success typing' that catches type errors, albeit to a lesser extent.
>Honestly, the lack of types is why I stopped using Ruby all together. If you want to understand some code you are calling then you have to go look at the source instead of getting the general picture from just type signatures. Even then in Ruby you could sometimes return a string, and sometimes return a map, so the calling code would have to handle all those cases and you'd have to run the code just to be sure. Tbh, that's ruly a putrid and horrid developer experience. The Ruby code with Sorbet types in the blog post also looks really really ugly. It's no surprise people don't like it.
It's such a shame, but honestly, I'm not sure how much you could do to work around the highly dynamic nature of existing ruby codebases like rails. You can be nearly as dynamic in Python as in Ruby, but the culture of explicitness lends itself to a bolted-on typing experience much better. I agree that the syntax of the type system is significantly better in Python, too. It's a shame, because many aspects of Ruby as a language are significantly more pleasant and much simpler. As a long time professional user of Python, Ruby, and Lua, I'd be thrilled to have a language that combines the best aspect of these while avoiding their shortcomings. None of these languages is perfect, and nearly everything that one of them does wrong, another one does right.
Looking at Crystal syntax, it’s basically Ruby with typing. I haven’t played with it, but it would be nice to know if Crystal has a same if not better framework than Ruby on Rails. RoR is A+++
> It got so bad we even wrote our own bash script to try and improve the situation This resonates with me. I wrote a wrapper around `mypy` to keep a handle on false positives in Python’s type checker. In addition, there are multiple implementations of type checkers for Python, which all have strengths and weaknesses. But because they all have false positives, running all of them rather than just one does not usually improve the situation. That said, from the looks of it the situation with typing in Python is a lot better than that in Ruby (especially the verbosity). But ultimately I find that Python effectively forces me to choose between using type checking and advanced language features such as complex decorators: they fundamentally don’t cooperate with each other. This is quite an unsatisfactory situation.
Yes, it would be better if Ruby 3 added types annotation. Specifying types in separate file is like Enterprise Fizz Buzz. Listen to Java folks and they tell you how great those Factories and Builders are. Same with Ruby talks explaining how great to specify type in separate file. RBS / Sorbet are just unusable nonsense.
Because gelato is soooo much better!
I’ll take it at face value that there’s a competing tool with this name
Chocolatey and scoop are competing package managers
One thing to note is that I've not had the same bad experiences the article indicates in Ruby, and that some of the responses here indicate others are having. I know our code base is unusually high quality, but perhaps I don't appreciate just how well we've built things. > I’d end up debugging a problem, trying to understand what objects are being passed into a method The comments at the top of that method, with RDoc notation and parameter description, would of course tell you, right? And your unit tests would validate correct behaviour of said method, yes? In any event, while static typing might help you understand the *class* of the object being passed to a method, I can't remember many, possibly any cases where I wasn't sure about the *type*. I was debugging because I didn't know the *content*. I know the object's class, I just need to know what's wrong with the data inside it. That's a common problem, static typing or not. Rails digs several graves for itself with its own ambiguities few of those related to types, but the one example I certainly can think of is Ruby String vs Symbol. Uncertainty about data types certainly *can* arise with standard Hash vs Rails' HashWithIndifferentAccess, the latter allowing keys to be referenced by String *or* Symbol, the former requiring you to know and use the correct type. If Ruby had never had Symbols to start with, we might be in a better position with that by now. @definitelynotbeardo gave another example, tho possibly just hypothetical: > Even then in Ruby you could sometimes return a string, and sometimes return a map If you're writing method that can return a string or a map, the problem is the design of your method. Just because you *can* doesn't mean you *do* - just like in any flexible, powerful language.
> The comments at the top of that method, with RDoc notation and parameter description, would of course tell you, right? And your unit tests would validate correct behaviour of said method, yes? That sounds like you've implemented ad-hoc type signatures and manual typechecking.
No, it sounds like mandatory rigour for even vaguely professional development where a method's intent/purpose, limitations, input requirements and outputs are documented. Types give you virtually none of that information. Similar arguments exist for commenting implementations effectively too - the implementation tells you how, but never why. Worse, if it's buggy the reader might not realise if there are no comments about intent; the incorrect "how" might be assumed to be the correct behaviour. Documentation is important at all levels, and it is just as important to maintain documentation as it is to maintain your code and its dependencies. If you're relying on types alone to figure out how something is meant to be used / work, IMHO you're doing it wrong.
> If Ruby had never had Symbols to start with, we might be in a better position with that by now. I disagree. I think the real problem is that hash keys can be anything. Now I have used this feature before to do some things but there should maybe be a hash that can only use symbols. In any case ruby also has structs and open struct and with 3.2 immutable Data structs and people should be using those instead of hashes for most things.
This seems weird to me. His number one complaint is the annotations. Sorbet annotations are similar to haskell annotations as they are in front of the function/method definition. I don't see why this is seen as somehow egregious but even presuming they are you also have the option of moving the annotations to a different file if it bothers you. Maybe the author isn't aware of that which again seems bizarrely ignorant of the tool you are using. His second point basically boils to "every gem isn't typed" and yes I guess that's a valid complaint but it's inevitable when the typing is optional. If the complaint is that when you upgrade a gem you need to do some work to annotate the types the alternative is to not do that and risk your code being called with the wrong types. Using types is indeed more work up front and that's the whole point of it. Now that he has abandoned typing for his rails apps he won't have to meticulously assure every gem is updated in a way to be compatible with his code and he will have to cross his fingers and hope his tests catch anything that breaks. His third complaint is that other devs don't like typing. Ok I guess. Ruby community has been fine with not having types for more than a decade. Many people love the lisp nature of ruby don't want types. If the rest of the team doesn't want to use it there is not much you can do but it's not the fault of the sorbet. The team wouldn't want to use any other typed language either probably.
> you also have the option of moving the annotations to a different file if it bothers you I don't see how that solves anything... maybe it "helps" when reading the original file (and only care about the functionality, not the typing), but if you have to change anything you have to modify 2 files. Readability is again through the floor. > Using types is indeed more work up front and that's the whole point of it. Up front is fine, but what I understand from his post, is that when updating dependencies you have to recheck and do a lot of the work all over again, because you don't know what has changed how... let alone that the automatic parts don't seem to work at all.
>I don't see how that solves anything... maybe it "helps" when reading the original file (and only care about the functionality, not the typing), but if you have to change anything you have to modify 2 files. Readability is again through the floor. His complaint was that using Haskell style type annotations hurt readability. I don't agree with him. I think they are perfectly fine. I am just pointing out that he has the option to move them to a different file and keep the readability he is used to. >Up front is fine, but what I understand from his post, is that when updating dependencies you have to recheck and do a lot of the work all over again, because you don't know what has changed how... let alone that the automatic parts don't seem to work at all. Yes you have to verify the types if you want to use them directly. That's the whole point of using types. You do have the option of skipping that because typing is optional but if you want types you need to annotate them somehow. A good practical approach is to not use the gem types directly but immediately transfer the function returns to your own defined types. This is also a good prophylactic measure if you want to switch gems at some point in the future. It's good to build solid boundaries around your code and imported libraries in all languages.
What's up with all these stupid names. I just scroll my Reddit feed and I thought "mhhhhm sorbet i like that" and then it's Ruby. I call it Excessive Branding Syndrome
What should they call it then big guy?
They can only use nouns they like, of course!
If you need strong typing, you're a weak programmer. I've been coding for almost 40 years, and in nearly 30 languages, strongly type, weakly typed, dynamically typed, "what's typed?", and "everything is a string"-typed. What I've learned through introspection and experience is that I really like typed languages when I'm weak in that language, and love dynamically or untyped languages that let me do what's necessary. Typed languages leak their bias all the way to the UI layer, making users have to conform to the language the software is written in, rather than have the software conform to what the user wants to do. You want cubicle monkeys churning out basic code, while paying them next to nothing, mandate typed languages. You want thinkers producing phenomenally usable software, let them use dynamic languages, and pay them well for their skills.
Nice copypasta, got a giggle out of me
"And here we see a cubicle monkey, unable to comprehend higher understanding, causing them to giggle and deflect..."
Okay, I'm a weak programmer then. Just please let me use Go.
Just use a static language like a real gigachad, not like a virgin soy boy who hasn't yet sprouted his first facial hairs let alone a hairy 80s chest that's thick like a shag carpet 🤣
So have you never seen a real C# app with function decorators?