They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.

No they aren’t. A higher version of UUID isn’t “newer and better”, like the word “version” implies. It’s just different. It’s like they called a car “vehicle version 1” and a motorbike “vehicle version 2”. The common use of “version” in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.

The talking pumpkin is 100% right that they should have used “type” or “mode” or “scheme” or something instead.

Nothing else has code completion that even comes close to being that good.

Well, except Visual Studio (for C++), Qt Creator, and every Java IDE in existence.

There aren’t many good cross platform GUI toolkits. I mean realistically is there anything other than Qt?

I know what both of those are and how to use them. But they are entirely relevant to the thread. Did you comment in the wrong place?

What are you talking about?

Ugh yeah that’s infuriating on Github search too. Obviously if I’m searching for some identifier I don’t want 10 pages of results in /tests.

How hard can it be? Just weight anything with test in the file path lower than everything else. Job done.

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 would prepare a healthy supply of alcoholic beverages and maybe some antidepressants! Also clear your calendar so you have a few weeks to debug.

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.

The kitty graphics protocol lets you send images to display in the terminal. I had a play around with it trying to make a similar GUI. The big gotcha is text rendering. You can either stick to normal grid aligned monospace, or I think you could maybe use a texture atlas, but it’s not going to be very efficient at all. I haven’t got as far as trying that though.

The videos… while they work are probably uncompressed video which is only going to work well over a very fast network.

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?

You’ll always get downvotes for this from Linux apologists who didn’t have the exact problems you’re describing, but you’re 100% right. There are loads of things you might reasonably want to do in Linux that require a command line, or just don’t work well.

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.