91–100 of 155 posts
Worth mentioning is Crystal lang: Ruby, with types!
Yeah, I think it would be great if this project made it clear how this compares with Crystal in terms of the syntax.
Worth mentioning is Crystal lang: Ruby, with types!
How alike actually are Ruby and Crystal? I’ve heard the similarity is only skin-deep: similar syntax but quite different semantics. In other words, isn’t describing Crystal as “Ruby with types” similar to describing C++ as “JavaScript with types”?
I think low_type is a much more elegant solution: https://github.com/low-rb/low_type
Earlier 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…
> 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. Especially in older poorly factored codebases where there are often many variations of classes with similar names and often closely related functions it can feel almost impossible until you're really familiar with the codebase. One of the worst part…
Earlier quoted context omitted.
At least for Python (since I'm more familiar with Python code and the Python ecosystem): progressive typing lets you incrementally add typing to an existing Python codebase. So you can have at least some of the benefits of typing for new or updated code without needing to re-write in a new language.
Gradual typing is the worse of both worlds. You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.
Honest 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?
Earlier quoted context omitted.
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 th…
Ugh more transpilers. I think low_type is a much more elegant solution: https://github.com/low-rb/low_type
I think that static analysis could be done with an extension to rubocop via Prism though. Same for documention features via Ruby-LSP tooling.
I think if they worked on those they would very quickly pick up support as the syntax is quite nice.
Until then I think that Sorbet, possibly using RBS-Inline, is probably the best solution. I'd give a notable second to YARD annotations and Solargraph. Solargraph is a much underated project IMHO.
Honest 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 s…
In the past couple of decades I have been through a couple IPOs, a couple of acquisitions, and have been in engineering leadership roles and slinging code in half a dozen different shaped eng/dev cultures.
In every case, static typing makes teams faster and gradual typing was a pain with potential payoffs that were muddy. Gradual typing is a shitty bandaid and so are type annotations.
I have migrated no less than 30 systems from various languages to Go across different companies, divisions, and teams. Mostly PHP, ruby, perl, python. Didn't migrate the elixir but I would have if given the opportunity.
In every single case, the team started delivering software faster. Prototypes became faster with the sole exception of prototype admin crud panels which we have needed like twice out of the nearly three dozen services I have worked on migrating. And super dynamic json can be a pain (which I blame not on problem spaces but on less thought out dynamic typed solutions offloading their lack of design onto customers via randomish response bodies).
When programs/applications get larger, the complexity tries to combinatorially expand. It can quickly outgrow what newer team members can juggle in their head. Type systems take some of that away. They also take away tests that are there due to lacking types. "What if this is a string, or list, or number" isn't a question you ask, nor is it a test you write and maintain.
When everything fits in your head, dynamics types are freeing. When it doesn't fit in your head, tooling helps.
Even smaller programs benefit. The dozens of teams I have personally witnessed don't find adding a type as a slowdown - they see whole test cases they can ignore as impossible to compile.
Earlier quoted context omitted.
Are they _solving_ these issues of dynamism with typing? What other issues does it introduce?
whole lotta companies moving from ruby monoliths to ts distributed systems
Take a working system and rewrite it as a series of separated network services that never quite implement the full original functionality in a new, trendy language just because.
It was a fad that new broom CTOs were keen on 5 years ago and I've seen a few companies killed by that decision.
There's so much unnecessary added complexity in running a distributed system of ts micro-services compared to a monolith. You need to be honest about that.