On Firefox, newlines in code blocks are broken for this website. This causes the page to scroll horizontally to accommodate all the code blocks. The code is all wrapped in a single line.
T-Ruby is Ruby with syntax for types
61–70 of 155 posts
Re: T-Ruby is Ruby with syntax for types
#62Earlier quoted context omitted.
(I'm not sure if this still holds under a world where LLMs are doing the majority of writing code but this is my opinion from prior to LLMs) From someone who has worked mostly in Ruby (but also Perl and TypeScript and Elixir) I think for web development, a dynamic language with optional types actually hits maybe the best point for developer productivity IMO. Without any types in a dynamic language, you often end up w…
> the best point for developer productivity IMO. That is a fair opinion. My opinion is different, but that's totally fine - we have different views here. What I completely disagree with, though, is this statement: > Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. I have been writing ruby code since…
The times I've been bitten by type safety issues is far less than the hassle of maintaining types. Seriously, it is a much smaller issue than people make it out to be. I will say that I do get bitten by the occasional `NoMethodError` on `nil`, but it really doesn't happen often. Since ruby is very dynamic it is hard to say how many of those errors would be caught even with type annotation. I also don't find myself needing to write specs to cover the different cases of type checking. For me it is a tradeoff with productivity.
That said, I do like it when an LSP can show some nice method signature info, and types are helpful in that way. I think it depends. At the surface level, I like some of the niceties that type annotations can bring, but I've seen how tricky defining more complex objects can get. Occasionally I would spend way too much time fighting types in elixir with dialyzer, and I've often not enjoyed TypeScript for the verbosity. So I understand the cost of defining types. To me, the cost often outweigh the benefit of type annotation.
Re: T-Ruby is Ruby with syntax for types
#63Worth mentioning is Crystal lang: Ruby, with types!
> Ruby, with types!
"Language with ruby-like syntax" more appropriate.
Re: T-Ruby is Ruby with syntax for types
#64Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?
Having to support legacy systems with 15y+ development where the system works but you wish you didn’t have to spend so much effort figuring out types?
Or maybe you are an expert with a framework, you are very productive with it, you know the tricks, but you wish it had types support so maintaining these systems would be easier.
Picking a “better” language or learning a framework in another language is not always a pragmatic choice.
Re: T-Ruby is Ruby with syntax for types
#65Earlier quoted context omitted.
(I'm not sure if this still holds under a world where LLMs are doing the majority of writing code but this is my opinion from prior to LLMs) From someone who has worked mostly in Ruby (but also Perl and TypeScript and Elixir) I think for web development, a dynamic language with optional types actually hits maybe the best point for developer productivity IMO. Without any types in a dynamic language, you often end up w…
This is our experience. We have added Sorbet to a 16 year old Rails app. It is a big win in avoiding errors, typos, documentation, code completion, fewer tests are required, etc. And the LLMs take advantage of the types through the LSP and type checking.
I’d love to hear from you or someone in your shoes: what are some patterns or examples of tests that are made redundant by types?
“It has a field of type X” has never been a useful test for me, my tests are always more like:
“if I send message X I get return value or action Y”
… with my admittedly limited experience of types I don’t see how they replicate this.
Therefore it looks like I’d only be “replacing” tests that I’d never write in the first place.
What am I missing?
Re: T-Ruby is Ruby with syntax for types
#66Earlier quoted context omitted.
> the best point for developer productivity IMO. That is a fair opinion. My opinion is different, but that's totally fine - we have different views here. What I completely disagree with, though, is this statement: > Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. I have been writing ruby code since…
The times I've been bitten by type safety issues is far less than the hassle of maintaining types. Seriously, it is a much smaller issue than people make it out to be. I will say that I do get bitten by the occasional `NoMethodError` on `nil`, but it really doesn't happen often. Since ruby is very dynamic it is hard to say how many of those errors would be caught even with type annotation. I also don't find myself ne…
I fully agree with this. I'm building a site in OCAML, and I just this week spent 90 minutes debugging some weird error I didn't understand because an implicit type was being pulled through in a global context. It was pretty irritating.
Maybe this isn't a fair comparison, since I'm pretty new to OCAML and I'm sure an experience developer would have seen what was happening much quicker than I would have. But I'm not sure I spent 90 minutes TOTAL on type errors doing Python web dev.
Maybe I'm exaggerating, and I probably just don't remember the first time I hit a type error, but my experience with type errors was that I would very occasionally hit them, and then I would just fix the type error. Pretty easy.
Re: T-Ruby is Ruby with syntax for types
#67I don't programme much any more but the whole beauty of Ruby that it pretty much heavily relies on #respond_to? / duck typing and thus you don't rely on types or class checking at all.
Most ruby code isn't written like that - it's written like most static languages, where objects conform to interfaces / traits / type classes / pick your poison. The community is shifting towards explicitly specifying and statically checking types now. rbs and sorbet are a testament to this. I wouldn't say it's really a beauty of the language, it may have been the original design intent but time has shown what's actu…
I don’t think the existence of a library to do something is evidence of the community shifting. For me the complete absence of types from any Ruby I see IRL or in examples from conference talks, readmes etc is evidence that the community is uninterested despite tons of effort from big players.
Re: T-Ruby is Ruby with syntax for types
#68Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?
Type free languages like Lisp, Python and Ruby have faster software development times than languages that use types.
The developers who are using the statically typed languages, which are slower to develop in, with are being pushed to use the faster languages.
But those developers don't know how to code in type free languages. So they attempt to add the types back in.
This of course reduces the software development speeds back to their previous speeds.
This means the whole thing is basically folly.
If you want a real example you can take a look at Turborepo, which in weakly typed Go took 1 developer 3 months to develop and has 20,000 lines of code. The direct port to Rust took a team of developers 14 months to develop and has 80,000 lines of code.
Exact same program but the development costs went up proportionally to the increase in the strength of the type system.
There are plenty of developers out there who have only used static typing and don't understand it comes with massive software development costs compared to it alternatives.
If you are developing a SaaS and you use duck typing, unit tests and micro-services. You will get to market long before your competitors who don't.
Re: T-Ruby is Ruby with syntax for types
#69I don’t like types in separate files but I also don’t want them cluttering my signatures. Types in comments would be my ideal, am I the only one who prefers this?
Edit: I see sorbet supports this as an experimental feature https://sorbet.org/docs/rbs-support
Re: T-Ruby is Ruby with syntax for types
#70Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?
Two reasons.
First, YJIT/ZJIT do much better when they know the type signatures of methods. You pay a performance penalty for implicit polymorphism, e.g. using a mix of types (Integer, Symbol, String) etc in the same method argument.
Second, from my experience with Typescript, as much as I naturally dislike type declarations, I find it does help LLMs. Having strongly typed libs/gems and being able to mix in untyped app code would be a nice balance.