formatting does depend on the type of variables. Go look at ktfmt’s codebase and come back after you’ve done so…

I skimmed it. It appears to visit the AST of the code and format that, as any formatter does. ASTs have not been type checked.

Can you give an example?

it gives you an option, just like if it was an interface. Did you actually try this out before commenting?

Precisely! It doesn’t know the answer so it has to guess, or make you guess.

And how often are you naming functions the exact same thing across two different classes without using an interface?

You mean how often does the same field name come up more than once? All the time obviously! Think about common names like id, size, begin, children, etc. etc.

I’m sorry, but you clearly haven’t thought this out, or you’re really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).

I’m sorry but you clearly haven’t thought this through, or you’re just happy to ignore the limitations of Ruby. I suspect the latter. Please don’t pretend they aren’t limitations though. It’s ok to say “yes this isn’t very good but I like Ruby anyway”.

I think you’re getting a bit confused. How do you know where x’s type is defined and therefore where x.bar is defined if you don’t know what type x is? It’s literally impossible. Best you can do is global type inference but that has very big limitations and is not really feasible in a language that wasn’t designed for it.

Do you think that formatters for dynamic languages need to know the type in order to format them properly? Then why in the world would you need it to know where to jump to in a type definition!?!

Not sure if that is a serious question, but it’s because formatting doesn’t depend on the type of variables but going to the definition of a field obviously depends on the type that the field is in.

Maybe my example was not clear enough for you - I guess it’s possible you’ve never experienced working intellisense, so you don’t understand the feature I’m describing.

class A:
  bar: int

class B:
  bar: str

def foo(x):
  return x.bar

Ctrl-click on bar. Where does it jump to?

I do like the author’s overall point that we should try and fix the issues rather than just pretend they don’t exist.

However a lot of these seem to be things that people have obviously thought of already, and they’ve thought about it more than the author and found problems that he just hasn’t got to yet. Incremental linking for example. Yeah obvious idea but did he think about all of these issues?

Good brainstorm anyway.

Oh really? How would an IDE go-to-definition on x.bar in this code?

def foo(x):
  return x.bar

Best it can do is heuristics and guesswork.

I assume you’re talking about embeddable languages. I’ve used Rhai and it’s quite nice but I wish it had type annotations.

Gluon is another option but IMO they’ve gone way too far into crazy and unergonomic ML-style syntax. Which is weird considering it’s implemented in Rust which has much nicer syntax for the same things which they could have copied.

Yeah I have yet to really use Deno in anger because so many people are like “but Python exists!” and unsurprisingly we now find ourselves with a mess of virtual environments and pip nonsense that has literally cost me weeks of my life.

Though if you’re using Numpy that source like “proper work” not the infrastructure scripting we use Python for so I probably would go with Rust over Deno. I don’t know of mature linear algebra libraries for Typescript (though I also haven’t looked).

IMO probably the biggest benefit of Rust over most languages is the lower number of bugs and reduced debugging time due to the “if it compiles it probably works” thing.

that’s a tough sale to the product team

Sounds like you’re not the boss enough!

I agree Rust has a pretty steep learning curve so it’s definitely reasonable to worry about people learning it, especially existing employees. Though I don’t really buy the “easier to hire people” argument. There are plenty of Rust developers actively looking for Rust jobs, so I suspect you get fewer candidates but the ones you do get are higher quality and more interested.

But anyway I don’t think that argument holds for Deno. Typescript is in the same difficulty league as Python. Anyone that knows Python should be able to transition easily.

Yeah I was very impressed. The only problem with uv and third party tools in general is that the main reason we’re using Python is because my boss didn’t want people to have to install extra stuff to use it. I would prefer using Deno, but apparently a one-line rock solid install command is too much to ask compared to the mess of Python infra… smh.

I’ve literally never heard anyone say that

Well you didn’t listen then. Google the phrase.

I can tell you’ve literally never even tried this…

I do not need to try it to know that this is fundamental impossible. But I will try it because you can go some way towards proper type knowledge without explicit annotations (e.g. Pycharm can do this for Python) and it’s better than nothing (but still not as good as actual type annotations).

It’s also much more readable than bash, python, javascript, etc. so writing a readable (and runnable everywhere)

Bash definitely. Not sure I’d agree for Python though. That’s extremely readable.

they’re fast enough

Strong disagree. I switched from pip to uv and it sped my install time up from 58 seconds to 7. Yeah really. If pip is i/o bound where is all that speed up coming from?

Matrix code is the very best case for offloading work from Python to something else though.

Think about something like a build system (e.g. scons) or a package installer (pip). There is no part of them that you can point to and say “that’s the slow bit, write it in C” because the slowness is distributed through the entire thing.

You’re talking about rails.

Maybe other Ruby code is better, but people always say Rails is the killer app of Ruby so…

Use an IDE like I said and you can literally just “Find all usages” or “Jump to declaration”, etc.

That only works if you have static type annotations, which seems to be very rare in the Ruby world.

In any case, you shouldn’t be using any of these for large projects like gitlab, so it’s completely inconsequential.

Well, I agree you shouldn’t use Ruby for large projects like Gitlab. But why use it for anything?

Profiling is an extremely useful tool for optimising the system that you have. It doesn’t help if you have the wrong system entirely though.

Maybe, but I think the only app store that does vet apps is the Apple one, so that should be the default expectation.

And I think even they wouldn’t manually look for something like this. They’re mainly concerned about people breaking the commercial rules.

Well yeah if by “well architected” you mean “doesn’t use Python”.

“microservices” or “better queries”

Not everything is a web service. Most of the slow Python code I encounter is doing real work.

No there’s an LGPL version still. You can’t static link it for non-commercial use.

Ever tried to follow a large Ruby codebase like Gitlab? Absolutely nightmare. Not only does it not have type annotations, so you can’t follow code by clicking, but you can’t even follow it by grepping because Rubyists seem to love generated identifiers. Even the syntax of the language makes grepping worse, e.g. the lack of brackets prevents you from grepping for function calls like foo(.

I can give you some basic Python set-up advice (which is hard-won because nobody tells you this stuff):

1. Use pyproject.toml, not requirements.txt. It’s better and it’s the recommended way.
2. Always use type annotations. I saw you used it a bit - well done! But just use it everywhere. Add declarations & type annotations for your class member variables. You’ll thank me later! Also prefer Pyright to Mypy; it is far far better (and the default for VSCode).
3. I would recommend using Black to autoformat your code. It’s easily the best Python formatter. You can automate it using pre-commit.
4. ALWAYS PUT MAIN IN A FUNCTION. You should not run any code at a global scope. Do it like this:

def main():
  ...

if __name__ == "__main__":
    main()

There are two reasons:

1. Generally it’s good to keep variables to the smallest scope possible. Putting everything in a global scope will just mean people start using it in their functions, and then you have a mess.
2. Any code you put in a global scope gets run when you import a module. Importing a module should not have any side effects.

Other minor things:

1. Path has a crazy/neat override of the / operator so you can do Path("foo") / "bar" / "baz.txt".
2. Don’t use assert for stuff that the user might reasonably do (like not choosing a background image). assert is meant to be for things that you know are true. You are asserting them. Like “hey Python, this is definitely the case”.
3. TK is an ancient shitty GUI toolkit. I would recommend QT instead (though it will probably be more pain to set up).

If everyone had a magic lamp that told them whether performance was going to be an issue when they started a project then maybe it wouldn’t matter. But in my experience people start Python projects with “performance doesn’t matter”, write 100k lines of code and then ask “ok it’s too slow now, what do we do”. To which the answer is “you fucked up, you shouldn’t have used Python”.

That’s not really true. C# and Java are reference-based, uses GC and can be multithreaded, and are very comparable to Rust/C++/C performance. Certainly no more than twice as bad. Whereas Python is probably 50x as bad.

The real answer is that Python developers have deliberately avoided worrying about performance when designing the language, until maybe 2 years ago. That means it has ended up being extremely dynamic and difficult to optimise, and the CPython implementation itself has also not focused on performance so it isn’t fast.

But I agree the aim of offering C/C++ speed is never going to be met with Python syntax.