rbs VS typeshed

I saw no mention of RBS+Steep, the latter providing a LSP. I use it a lot and very much like it, although it's still young and needs love, but it's making good, steady progress! I've been very pleasantly surprised by some of the crazy things Steep can catch, completely statically!

You appear to be working on projects with Sorbet (which I tried to like but found it fell short in practice, notably outside of the app use case i.e it's mostly useless for gems) so it may be a tall order to try on those. Maybe you can give RBS+Steep a shot on some small project?

RBS: https://github.com/ruby/rbs

RBS collection (for those gems that don't ship RBS signatures in `sig`, integrates with bundler): https://github.com/ruby/gem_rbs_collection

Steep: https://github.com/soutaro/steep

VS Code: https://github.com/soutaro/steep-vscode

Sublime Text: https://github.com/sublimelsp/LSP

Vim (I'm working on it): https://github.com/dense-analysis/ale/pull/4671

I don't know what you mean by "Static typing is not webscale".

> https://news.ycombinator.com/item?id=39159481

Bugs exist in all code written in all programming languages and you will find bugs in programs written in statically typed languages too as you know. Programming languages are rarely chosen for the absense of bugs alone though or we'd all be using SPARK Ada or something.

> spitting out code as fast as your keyboard works, or is is not having features do weirdo things

This is a straw man. No-one has suggested that "spitting out code as fast as your keyboard works" is what Rails allows you to do, or that Ruby code results in features that "do weirdo things".

In reality engineer productivity is important and Rails enables it in a web environment.

> I have more than once tried to contribute fixes to GitLab's codebase, and every time I open the thing in RubyMine it hurpdurps having no earthly idea where symbols come from or what completions are legal in any given context.

Yes, I prefer writing statically typed languages and I would /greatly/ prefer Ruby to be statically typed for a number of reasons, but it will likely never be so in a way I consider to be usable (see https://github.com/ruby/rbs). Not being able to definitively tell what a method returns or where one is defined is a total PITA, but it's one of the array of up and downsides to Ruby, with each language having a different set.

> I trust JetBrains analysis deeply, so if they can't deduce what's going on, then it must take an impressive amount of glucose to memorize every single surface area one needs to implement a feature.

You don't need to know how all of Rails works to write a Rails app, as I'm sure you know, so this seems like another mis-representation of the truth, just as you don't need to know how the compiler or CPUs work to do a lot of (most?) programming.

> That or, hear me out, maybe "it works on my machine" is a close to correct as the language is going to get without explicit type hints as a pseudo static typing

You seem to be suggesting that Ruby on Rails applications behave unpredictably on a machine to machine basis but that's not really how Ruby works in practice, or matching on my experience.

Are you familiar with rbs (https://github.com/ruby/rbs)? If so, what issues do you see with using that over TypeScript?

Ruby does have optional type annotations, if you want them:

https://github.com/ruby/rbs

Is anyone using RBS? Or, is it still half-baked? I haven't seen any recent posts about it this year. Though, I see the repo has some recent activity.

Currently rbs collection resolves stdlib dependencies, but rbs -r LIB option doesn't resolve them unfortunately. For instance, logger depends on monitor, but rbs -r logger doesn't load monitor.

Here is link number 1 - Previous text "RBS"

Partial clone reduces the impact, but it just procrastinates the problems.

"csv.pyi is from VS Code Pylance extension" is misleading. Yes, it's included in the code base of the extension, but it's likely originally from python/typeshed. I diffed csv.pyi in the extension and the repository, and they're exactly the same.

You can check the typeshed library that offers stubs for many packages.

https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.

https://github.com/python/mypy same with typeshed https://github.com/python/typeshed

Here's the tensorflow type stubs on typeshed. https://github.com/python/typeshed/tree/main/stubs/tensorflow

Also, be aware that there is already a central place for stubs files. If you are going to take the time to write one, contributing it there will help everyone if the package owners aren't already including some type hints.

Python's type hints are definitely an improvement and they're getting better all the time, but they're still frustrating to use at anything approaching the edge. I long for something as elegant and functional as TypeScript.

One hurdle I've stumbled over recently is the question "what is a type?", the answer can be surprising. Unions, for example, are types but not `Type`s. A function that takes an argument of type `Type` will not accept a Union. So if you want to write a function that effectively "casts" a parameter to a specified type, you can't. The best you can do is have an overload that accepts `Type` and does an actual cast, and then another that just turns it into `Any`. This is, in fact, how the standard library types its `cast` function [1]. The argument I've seen for the current behavior is that `Type` describes anything that can be passed to isinstance, but that's not a satisfying answer. Even then, `Union` can be passed to isinstance and still does not work with `Type`. Talk currently is to introduce a new kind of type called `TypeForm` or something to address this, which is certainly an improvement over nothing, but still feels like technical debt.

[1]: https://github.com/python/typeshed/blob/main/stdlib/typing.p...

>Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.

No, I really don't.

https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.

https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.

https://gitlab.alpinelinux.org/alpine/aports/-/merge_request... - I noticed that gnome-passwordsafe crashes some times, debugged it to discover that it was missing a dependency, sent a PR to the distro package to update the dependencies.

etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.

The csv module is one of those standard library modules that doesn't provide its own type hints, but instead gets them through the external typeshed project, and (for compatibility/implementation reasons, I surmise) the name of these types sometimes don't quite align with the objects they correspond to. So, for all intents and purposes, _csv._reader is the correct name of the type that csv.reader() returns, as ugly as it is.

You have to do handling like that in other languages like TypeScript anyway.

Painpoint with type annotations:

- not being able to reuse "shapes" of data: TypedDict, NamedTuple, dataclasses.dataclass, and soon kwargs (PEP 692 [1]) all have named, typed fields now. You have to

- Since there's no generic "shape" structure that works across data types, there isn't a way to load up a JSON / YAML / TOML into a dictionary, upcast it via a `TypedGuard`, and pass it into a TypedDict / NamedTuple / Dataclass. dataclasses.asdict() or dataclasses.astuple() return naive / untyped tuples and dicts. Also the factory functions will not work with TypedDict or NamedTuple, respectively, even if you duplicate the fields by hand. See my post here: https://github.com/python/typeshed/issues/8580

- Standard library doesn't have runtime validation (e.g. pydantic / https://github.com/pydantic/pydantic).

- pytest fixtures are hard.

- Django is hard. PEP 681 may not be a saving grace either. [3]

[1] https://peps.python.org/pep-0692/