Hacker News

adamnemecek
Type Server Protocol github.com

nikolatt9 hours ago

DetachHead (maintainer of basedpyright) has criticized the TSP before:

- https://docs.basedpyright.com/v1.40.2/type-server/

- https://github.com/microsoft/pylance-release/discussions/718...

Ty (the type checker maintained by astral) however will apparently support the TSP: https://github.com/astral-sh/ruff/discussions/23432

ghm21808 hours ago

I think the only way MS knows how to make money is lock someone into an ecosystem. I think their next attempt should be a closed source lean checker that has will have proprietary code for NL -> lean formalization checker.

pjmlp8 hours ago

Applies to all big tech contributing to FOSS, they don't do it out of charity.

salynchnewan hour ago

Definitely not true. Historically, it's been one of the ways they attract (and scout) top talent.

IshKebab7 hours ago

I don't think that's true. Many big companies contribute to FOSS in ways that aren't just to attempt to lock people in. Often it's because they use the software and don't want to maintain patches forever - everyone wins if things actually get fixed. Or even because they just want to be known as a good place to work.

__s7 hours ago

That describes how hands off MS was with Postgres committers ime a few years ago. Useful to house them to for helpful office hours too. We'll see how that holds up post HorizonDB

simonjgreen7 hours ago

So… not out of charity then?

lukan7 hours ago

No, mostly not, but that does not mean they engage with locking customers in.

IshKebab7 hours ago

Not purely, but "charity" and "only doing it to lock people in" are not the only options.

wtetzner6 hours ago

Of course not? I don't think anyone claimed it was out of charity.

pjmlp7 hours ago

Name one big tech company in the same monetary level, that doesn't contribute to FOSS without second intentions.

wtetzner6 hours ago

They definitely have other intentions, but it's often the same as people contributing in their free time: they use the software, want to make it better for their purposes, but don't want to be the ones to maintain it.

galaxyLogic6 hours ago

Don't we all have "second intentions"?

Altruism happens usually among members of a tightly knit group, like family members or soldiers of a given unit. Teachers sacrificinng their life to save children. FOSS-developers, are they really producing software out of altruism? Maybe some of them are but it is hard for us to know whether that is so or not.

awesome_dude3 hours ago

If a FAANG releases Kafka, REACT, Kubernetes, or any number of projects that they found helpful, and released into open source - there will always be a claim that they do it with some second intention, such as "be seen to be a positive contributor to the community"

But the truth is - so do I - as a humble contributor to a document, test, bug fix, or feature add to a FOSS project - where's the beef?

endofreach7 hours ago

No. Microsoft and facebook are the try-hardest by far.

1287h7 hours ago

Yes, Microsoft fired the Faster CPython team and Facebook/Instagram tries to buy its way into Python core in order to get their buggy free threading in.

Totally altruistic!

pjmlp7 hours ago

NVIDIA, AWS, Google, Intel, AMD,...

anonymous9082139 hours ago

This should be called Python Type Server Protocol, no? Seems weird to mine the generic protocol namespace for a protocol that only supports Python. Especially coming from the company behind LSP, which actually is generic.

rzzzt9 hours ago

Type Server Subsystem for Python

cobolexpert8 hours ago

Copilot+ Type Server Subsystem for Python Series S

Waterluvian8 hours ago

Copilot+ Type Server Subsystem for Python Series S .NET

kstrauser7 hours ago

…Server 2027.

nazgulsenpai7 hours ago

...Subscription Edition

keitmo6 hours ago

...365

wseqyrku2 hours ago

.PYTHON

[deleted]8 hours agocollapsed

zemo7 hours ago

Language Server Protocol Server Subsystem for Type Server Protocol Servers for Python

warkdarrior4 hours ago

... for Workgroups

awesome_dude3 hours ago

Python Server Subsytem Typing - PSST

wolttam9 hours ago

It is namespaced under the pylance project. I also don't see any announcement here, just a markdown file.

Perhaps the post title could use a tweak

adamnemecekop9 hours ago

roarcher8 hours ago

This is the company that named its web framework "MVC". At least this time they're not eternally polluting search results for an industry standard term.

ameliaquining6 hours ago

I've usually heard it called "ASP.NET MVC" except when the former part was clear from context.

Blackarea9 hours ago

100% - it would make more sense if they also supported elixir or other dynamic languages

pantsforbirds9 hours ago

I do wonder if it generalizes outside of python similar to how LSPs do.

[deleted]7 hours agocollapsed

fnord1236 hours ago

So now I need a TSP AND an LSP eating loads of memory?

coindef19 minutes ago

这个协议真正有价值的地方不在于又多了一个 JSON-RPC 接口,而在于类型信息从字符串变成结构化数据。LSP 的悬停信息本质上是给人看的 Markdown,客户端或代理想程序化地使用类型时只能脆弱地解析文本;如果类型查询返回的是结构化的类型节点,编辑器、重构工具和代理就能直接消费,而不必猜测格式。关键的取舍在于范围与成本:如果每次查询都要计算完整类型图,延迟会很难接受,所以按需、增量的查询和明确的能力协商比协议本身更重要。另外,当前的结果类型明显偏向 Python,未来要推广到其他语言,需要把语言无关的类型骨架和语言特有的类型构造分开,否则很容易变成第二个只服务于单一生态的协议。

impoppyan hour ago

It’s really good that folks over at Astral decided to implement it. It was difficult for me to understand what does this protocol provide that couldn’t be implemented with a new LSP capability, the linked document doesn’t really explain that, but what did become clear to me is that seemingly Microsoft are trying to invent new features for their proprietary LSP server that only works in VS Code so people will have harder times switching to other editors. This way, no matter what Microsoft comes up with, will be matched with very high quality open source tools.

tobz10009 hours ago

As someone with minimal knowledge of LSP specifics, I'm a bit confused about why this exists. Is it the case that LSP alone does not provide adequate functionality for Python type queries?

nextaccountic5 hours ago

> why this exists

https://docs.basedpyright.com/v1.40.2/type-server/

> The "type server protocol" is a desperate attempt from microsoft to prevent pylance from becoming obsolete by outsourcing its type checking to other language servers like basedpyright, ty or pyrefly -- while continuing to keep certain language server features exclusive to pylance.

> This protocol benefits nobody except microsoft. It adds needless complexity to any language server that chooses to support it. Basedpyright does not support it and strongly advises other language servers to avoid supporting it as well.

> For more info see here https://github.com/microsoft/pylance-release/discussions/718... and here https://github.com/astral-sh/ty/issues/1190#issuecomment-337...

Wilfred8 hours ago

It seems to be a more structured representation of the type. Normally in LSP you'd have a plain string or markdown that you render in the IDE, but nothing that you can analyse structurally.

It's a shame it's not just an LSP extension though, or a feature in a newer LSP version. LSP is maintained by Microsoft engineers.

zamalek8 hours ago

workspace/symbol will do it (and the output may need some massaging), but it's optional.

ocamoss7 hours ago

I thought workspace/symbol returns an unstructured payload wrapped w/ some metadata.

Since the format is unspecified I imagine many language servers would just return a string representation of the type, which in Python is a PITA to parse because not every type has a closed-form representation (overloaded callable types, for example, have to be declared as a protocol).

zamalek7 hours ago

Fair enough, I had no idea it was unstructured.

Tarean9 hours ago

So basically adding machine readable type-at-point queries as an lsp extension so Pylance and Pywright can be separated?

The 'result types'format is super python specific, like not having a for all binder. I don't think this specific schema will be used for any non-python languages.

pipes9 hours ago

Can someone explain what this is to someone like me that doesn't know python very well, but programs a lot in c#?

jesuslop8 hours ago

Language server protocol is the interface of a software piece that sits between an IDE and a language toolchain so you don't need to change code in the IDE to add support of new languages (you add support on the LSP server). Then server provides things such as completions/intelli-sense, navigation to definitions and some correction checking. From the anouncement TSP extends LSP for better python type awarness.

0cf8612b2e1e9 hours ago

It kept with UTF-16. New protocol is a chance to correct that poor decision.

marshray6 hours ago

It's just an .md file and a few hundred lines of json schema defining some extension messages, not a bottom-up protocol revision.

ivanjermakov4 hours ago

What's wrong with UTF-16 for transport?

PufPufPuf6 hours ago

I just use the Pyrefly extension in VSCode/Zed, run Pyrefly in the CI, and everything works well. The fragmentation around pyright/pylance/basedpyright/cursor-pyright etc. makes it pretty much unusable, you can't get consistent results across IDEs.

asunny3 hours ago

[flagged]

_heimdall3 hours ago

Reading the main README, I'm not sure why I'd reach for this over ant other typed JSON RPC, tRPC or similar. What are the benefits I'm missing here?

ashkankiani3 hours ago

When I wrote the initial version of the neovim LSP client, I got intimately familiar with LSP, and how much I hate it. Microsoft protocols have a habit of being extremely specialized to their application despite being recommended for broader use. I will never, ever, ever adapt another microsoft language protocol.

rmzs07119 hours ago

Is there any application for that, except python?

ocamoss7 hours ago

Right now it's specific to Python but I think there are other languages w/o an official type checker that might benefit.

PHP, Erlang, Ruby, etc.

dev_l1x_be8 hours ago

The primary reason i guess is standardizing the type checking, so you can bring your own (3rd party).

[deleted]9 hours agocollapsed

rjbwork9 hours ago

It's such a shame python got such mindshare. It's a disaster of a language and ecosystem that people keep bolting and hacking things that much better thought out languages have had for decades.

YuechenLi8 hours ago

At this point, Python is less of a programming language by itself but more of an interop protocol between various C/C++/Fortran/Rust binaries. But again, it's just part of the cycle, Python was a breath of fresh air 10 years ago when academia is still dominated by Matlab, but now it is mostly a mess of a language that's good for throwaway scripts but not very convenient for large software projects compared to statically typed languages.

0gs8 hours ago

thank you for putting this this way. it helped me crack a big unrelated problem

YuechenLi7 hours ago

Out of curiosity, may I ask what the big unrelated problem is?

0gs3 hours ago

still trying to figure out a way to explain it, but i thought i needed a programming language, and it turns out what i need is an interop protocol. i want to be able to "translate" English text to a more or less dense rendering (or a completely different tone/pedagogical approach) without adding or losing meaning.

YuechenLian hour ago

Interesting. Look up "semantic compression", and you can also try out one of my experiments to see if it works for you.

https://github.com/yuechen-li-dev/GenerativeCompressionProto...

chuckadams8 hours ago

I remember falling in love with Python when I first learned it at version 1.5, liked it even more with 2.0, but when 3.0 came around, that's when I noticed the ecosystem falling apart. Not for the obvious incompatibility schism: I do think most of 3.0's changes were good ones, and it finally is the standard default version now, but in many other ways it feels like the ecosystem has still never really recovered. Virtualenv is still the same grotesque hack, where rather than doing what other languages like Perl and Ruby do and making some wrapper around setting PYTHONPATH, it relies on python's behavior of locating the library path relative to the install, thus hardlinking a whole python installation in and making you "activate" it first. That nothing has managed to replace it in 20 years speaks volumes.

kenhwang8 hours ago

I'm hoping one day people look at Python the same way they look at Perl and PHP.

There has been so much programming language innovation in the past decade that I'm surprised someone hasn't built a better Python. I'd like to see something like Rhai or Roto take off which has a natural upgrade path to Rust.

Maybe it's because interpreted languages just aren't in vogue anymore and probably won't be for a long time if humans aren't even coding anymore.

zamalek6 hours ago

> I'm surprised someone hasn't built a better Python.

I believe Mojo is an attempt at that. Python is probably too entrenched by my estimation.

jacquesm8 hours ago

Roughly the time when Guido stopped fighting the hordes. The hordes won, wrested the language away from its creator and now they own the pieces. 2 to 3 was the worst possible way a language has ever been upgraded bar none. Hilariously, even today Python 2 persists in many places because of this.

rspeele8 hours ago

> 2 to 3 was the worst possible way a language has ever been upgraded bar none

Perl 6?

giancarlostoro8 hours ago

Which gave up and became its own language, its own level of confusion.

collabs8 hours ago

> Formerly named Perl 6, it was renamed in October 2019.

I can't imagine how anyone can complain about this. The community revolted. The team listened. What else do we want?

[deleted]8 hours agocollapsed

dist-epoch7 hours ago

Guido wrested himself by accepting the stupid := operator against the huge opposition.

jacquesm7 hours ago

> Guido wrested himself by accepting the stupid := operator against the huge opposition.

Yes, that's the attitude I was talking about.

See, when you are a maintainer of a popular language with a community at some point the bickering becomes the job. And when you are a creative person managing a horde of egos who all participate to put their stamp on something the only reasonable thing to do is to leave them to their own devices, which he did. I really don't blame him. Guido is one of the nicest people and to see how the Python community did not have a single second's consideration for how their incessant infighting must have made him feel is one of the worst stories of the FOSS movement.

dist-epoch5 hours ago

Guido was celebrated because he had taste.

If you don't want bickering create a closed project, make it open but don't accept contributions, etc.

You can't have it both ways "I want a big diverse community, but they should all agree with me"

Aeolun5 hours ago

I think the idea is that you start out believing people will cooperate, and that the best idea will naturally surface, and then you find out humans don’t actually work like that.

jacquesm5 hours ago

It's not about agreement. It's about basic decency.

qw5aj7 hours ago

And a couple of psychopath core devs gleefully celebrated hours after his resignation, marginalizing the event and tried to grab power directly. The two snakes are an appropriate symbol for Python.

jacquesm7 hours ago

Exactly. No good deed goes unpunished.

deathanatos8 hours ago

> thus hardlinking a whole python installation in and making you "activate" it first

You don't have to activate a venv to use it; `$VENV_PATH/bin/python3` just works.

(It also softlinks/symlinks the binaries.)

[deleted]8 hours agocollapsed

benrutter9 hours ago

I work in python daily, it's not necessarily my favourite language, but I'd say it's mostly fine.

What languages are you thinking of specifically when you mention better thought out ones?

rjbwork8 hours ago

Pretty much every other mainstream language bar JS. I'd say also Ruby because I also do not like a lot of its choices, but there's at least a kind of heady elegance to it in a REPL, though I would never want to work on a production system written in Ruby.

Frankly, I just really prefer statically and strongly typed compiled languages.

I did my last company's first Demo and MVP in Python after running through the Koans at my co-founder's behest and ultimately we decided that the production system would not be done in Python. There are some cool things about it - specifically I do like that annotations are real AOP seams, but the numerous footguns and lack of types and a compiler just make it a very annoying ecosystem to work in for me.

pphysch8 hours ago

They are a heavy C# user. Coke/Pepsi situation.

jelloroll425 hours ago

Java would be Coke to C#'s Pepsi

pphysch5 hours ago

Those are closer languages but my broader point is that these application-level languages are more or less interchangeable from a professional standpoint. A Java or C# pro should probably not spend time becoming a Python pro because they could have spent that time producing equivalent value in the languages they are already experts in.

stackghost8 hours ago

I don't agree at all that it's a coke/pepsi situation. That analogy is for when two mostly-interchangeable choices develop tribal followings based largely on personal preference. Coke and Pepsi are both caramel carbonated soft drinks that are terrible for your health differing only slightly in flavour. Otherwise they're materially identical.

C# is strongly/statically typed, compiled, and quite fast (after the vm has started), whereas python is weakly/dynamically typed, interpreted, and generally slow as fuck. Those are two fundamentally different languages, how could it possibly be a coke/pepsi situation?

I think python is fantastic for certain use cases: gluing other tools together (like LAPACK or other ancient libraries), system automation, prototyping, exploitation (I think pretty much all of us were working on stealmybitcoin in python), and exploratory data analysis.

The problems arise when people try to write, say, gigantic GUI applications in python, or really anything with CPU-bound workloads. Part of being an engineer is using the right tool for the right job. Python is the wrong tool for lots of jobs. That shouldn't be a controversial statement.

Jtsummers7 hours ago

> whereas python is weakly/dynamically typed

It's strongly/dynamically typed, not weakly typed. Why do people keep getting this wrong? Has any version of Python been weakly typed? I know Python 2 and 3 aren't, perhaps the first version or ABC, its predecessor language.

wtetzner6 hours ago

> Why do people keep getting this wrong?

It's kinda funny to say people are getting it "wrong" when strong/weak typing isn't really defined anywhere or universally agreed upon.

In fact, even "dynamic typing" can be considered to be an oxymoron, since types are formally defined to be a static property of a language. A more correct term would be "uni-typed".

I'm not saying that the meanings you're using for static/dynamic and weak/strong are bad, just that chastising someone for getting them "wrong l" doesn't make sense for terms that are not widely agreed upon.

pphysch8 hours ago

Numpy is over 2 decades old. Pytorch is a decade old. Python devs know what "right tool for the job" means and focus on solving problems instead of being language purists.

stackghost7 hours ago

This has nothing to do with purism. I use python all the time, where it makes sense.

What I don't do is cultivate a "favorite language" and make it my whole identity, and then take criticism of that language as some sort of personal affront. Python objectively has some serious flaws. That shouldn't make anyone emotional, and I don't know why people get their backs up like this.

pphysch7 hours ago

Who is cultivating a "favorite language"? I missed that part. Agreed that this should not be an emotional issue, that is unprofessional.

Problem with any popular language is an outsider sees one or two statistically-likely codebases that are total turds, and then gets one-shot by the Goomba fallacy.

stackghost3 hours ago

> Who is cultivating a "favorite language"?

I don’t know, but deflecting legitimate criticism of a language by calling it “language purism” seems pretty emotional to me.

FacelessJim8 hours ago

And the thing that maddens me the most is that it has a critical mass where it’s basically the default starting language and most people never really move from there. And so we’re stuck with this grotesque abomination that somehow keeps on rolling. The amount of money that was poured into python to make it barely bearable is probably the GDP of a small nation.

loeg9 hours ago

I’m not a fan either, but it doesn’t bother me at all. Who cares? Let the python people do their thing.

lijok9 hours ago

Fascinating take.

What do you attribute Python's success to, in spite of being a disaster of a language and ecosystem?

TomBombadildoze6 hours ago

20 years working on Python. Two things have driven its success.

First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.

Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.

[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.

It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.

johnfn9 hours ago

It's incredibly easy for new engineers to pick up. On the spectrum between "features easy for beginners but nightmarish for experienced engineers" and "features complex for beginners but great for experienced engineers" it always makes the tradeoff for the former.

dude2507119 hours ago

Yes, just like Go, it's a junior developer onboarding language, that somehow managed to overstay its welcome.

theplumber9 hours ago

Go is awesome and has great ecosystem. I think if you want to just deliver Go is one of the best language out there. Of course as long as the project makes sense(I.e no client side/GUI stuff, there it gets messy)

konart8 hours ago

Some people live to shit on Go since you can't really do "crazy cool shit" as someone I knew put it.

Apparently you can't be a senior dev unless you "just here to deliver"

dijit8 hours ago

C++ is the "just here to deliver" language.

It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.

Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).

No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.

"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.

Go is a lot more elegant and well designed, but it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..

EDIT: if we consider speed a function of development time rather than runtime, of course at runtime C++ can be as fast as it gets.

stackghost8 hours ago

The dump truck that is C++ definitely goes just as fast if not faster than that Hellcat, though.

To me it seems more like C++ is the metal shop's old school 3-axis mill: effective and dangerous. Can do almost anything, including easily maim you unless you're continually vigilant.

Go seems like a CNC machine: just as effective, much less dangerous because it relies on digital safeguards and embedded controllers. You need to go to extreme lengths to make it do something it wasn't designed to do.

Python seems like lego. Shit simple to build things with, lets you start building immediately, fantastic for prototypes, but finished product is still just press-fit plastic bricks

dijit8 hours ago

Well, if we consider speed of development rather than speed of the runtime, the analogy holds better.

bheadmaster9 hours ago

If Go is a junior developer onboarding language, then I proclaim myself a perpetual onboarding junior.

dijit8 hours ago

And that's ok.

timschmidt6 hours ago

I'm not the OP, but it seemed to me that major teaching institutions settled on Python as a pedagogic language after previously having rallied around Java for same, and various other languages before that.

kingstnap9 hours ago

Probably the batteries included Standard Library.

Cross platform interpreter.

NumPy and SciPy really set the stage.

chuckadams8 hours ago

It's definitely a better language than Matlab, and Numpy made it actually fast for that purpose. AI research really took advantage of that even before LLMs hit the scene.

jacquesm8 hours ago

BASIC rebooted. Right at the right time too, BASIC was never going to thrive in the days of the internet.

I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.

thinkyfish7 hours ago

They provide binaries for almost every open source library for every popular platform. If you need something, whatever it is, python was and is probably the easiest way to install and use it.

stronglikedan8 hours ago

well, for one, my boss can use it and kinda understand it, so it must be dead simple

rsalus9 hours ago

Definitely ease of use...

Pxtl8 hours ago

It was the first language that actually felt ready-to-use, available for free-as-in-speech. Batteries included, robust online development community, sensible featureset, main libs that were designed bottom-up instead of top-down. I remember learning Java 1.2 or 1.4 after learning Python and it felt like a huge regression. Swing was a joke compared to TkInter (which was weak compared to proper GUI editors like VB but at least made nice scalable native-feeling GUIs and had a sensible API) and the standard collections were miserable without generics.

But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.

aaabbbbb9 hours ago

Marketing in academia, decent C-API that led to use in scientific Python.

The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.

avaer9 hours ago

- Math + visualization libraries (which ironically have to break out of Python to do their job)

- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician

- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS

wiseowise8 hours ago

No other language came even close to a combination of easiness and expressivity of Python.

svachalek8 hours ago

I've been thinking recently, there's hardly any reason not to use a native language like Rust anymore. The classic reasoning for languages like Python is that it prioritizes developer time and resources over compute resources, but now developer time is rapidly trending to zero and everything is compute dominated.

joshheitzman7 hours ago

Not having to build still saves wall clock time. Also Python is a concise language (fewer tokens in context) with a monster ecosystem that avoids a lot of code having to written by agents (fewer tokens for the current task and fewer for future tasks by keeping the code base smaller).

hocuspocus7 hours ago

Most of that monster ecosystem is exactly that: monstrous code in one-off throwaway libraries written by people who don't care about software, as it's not their job.

If you set a bar, any bar, there's really not much offered by Python that you cannot find in a more reasonable language. Especially if you're gluing together C++ and Rust libraries for data processing or ML workloads. Python is still disproportionately popular there but I'm also convinced its days are counted. C++ will be tremendously harder to get rid of, in comparison, if that's even possible.

kenhwang8 hours ago

Rust has Rhai and Roto too if you need better than Python level of developer considerations.

gostsamo8 hours ago

Unpopular take, but:

I work in python. It's only real and big issue is the slow interpreter. Everything else is resolvable one way or another. The only other big issue it has is the envy of people who imagine that if not for python, their beloved language would be as used as python is now. Most of their beloved languages are older than python or when they were created, they had much bigger ticket backing than python and those languages are still not where python is. The reason? Python is made to solve the issue one has now, not the issue one might have in the future. Local optimum at its best and worst. And honestly, most people have the current issue to solve and rarely reach the imaginary issue to be. If python didn't exist, it would have been invented.

FridgeSeal4 hours ago

The issue is that it just becomes a “bad at everything” tarpit.

- performance is awful.

- gradual typing is sort of ok, but relies too much on runtime behaviour.

- async support is a bit all over the place.

- uv has made the packaging experience sort of liveable, but collectively it’s still very limited: feature support, conditional dependencies, rudimentary tree shaking, cargo-style workspaces, etc.

In an era where your options of tech stack are freer than ever, unless you explicitly need PyTorch, I’m not really sure why you’d choose Python over literally everything else.

risyachka9 hours ago

I will take Python over typescript every second of every day. TypeScript is just so unreadable compared to Python.

mi_lk9 hours ago

OTOH I don't want to live in a universe where Haskell wins

brcmthrowaway9 hours ago

The packaging is a nightmare thats for sure.

Venvs, activate, deactivate, shitty scripts hacking on $PATH. How did this ever ship? Then there was poetry, `uv`, and maybe something in else in $CURRENT_YEAR.

Try to set it up on a new macOS, go on. Install a package from pip, and there's a bunch of garbage that won't let you do it.

It's horrible. Python packaging engineer is now an FTE, maybe that's what they wanted.

Pxtl8 hours ago

The fact that they didn't solve Venv when they did the breaking change in Python 3 is absolutely bonkers.

Toutouxc9 hours ago

As a Ruby dev I'm kind of primed to hate on Python a little bit, but I have to agree. I've written some Python over the years, I've tried to like it, but it just doesn't feel good to me. There are things that are really great about Rust, Elixir, C#, Swift, Java, Common Lisp... Sometimes it's the standard library, sometimes the package manager, sometimes a feature (borrow checker, pattern matching), sometimes a principle (everything is an object, the code is just data). In Python, everything is kind of meh. Like they came up with the list comprehension syntax and that was it for cool things.

Pxtl8 hours ago

List comprehensions? Really? I remember when they were pretty and I was learning them alongside other languages with higher order functions and Python's approach seemed to be the ugliest of its cohort. They were neither as logical as simple Lispy "take a function as a parameter" things like Ruby, nor were they the kind of clean and legible stuff we expect from Python.

Toutouxc8 hours ago

I'm not saying I personally like them, but they're not as bland as the rest of the language. FWIW, I watched 3 non-dev people around me learn Python in uni (biologist, lawyer, graphics designer) and they all liked the list comprehension syntax.

globular-toast8 hours ago

Python had no corporate backing, no marketing, it became popular because people actually like to use it. Sorry you've only been using "better thought out languages" instead.

westurner8 hours ago

Python should have done runtime type checking instead of compile-time only String and List annotations and so on

esafak9 hours ago

Worse is better. Avoid using it yourself and tell others; that's the best you can do.

quotemstr9 hours ago

Python is pretty decent. What are you talking about?

okanat8 hours ago

The syntax and meaningful spaces are annoying. The dynamic typing is abused to hell in everything including the standard library. It has wacky paradigms like "exceptions instead of conditionals" or having "else" clause for loops.

It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.

It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.

[deleted]8 hours agocollapsed

Quitschquat9 hours ago

I blame Perl 6

theplumber9 hours ago

it could be worse like …PHP

mathisfun1239 hours ago

> It's a disaster of a language and ecosystem

"unhinged" take

madelgi7 hours ago

i primarily work in python and from a language-design standpoint, sure, there are generally better options out there. but all the people convincing themselves that a language with this much of a user base and this large of an ecosystem will fade away because of ai or some other reason are deluding themselves. i'm sure the death of python will be imminent for the next several decades, just as it has been for java

paaloeye7 hours ago

Is it Python specific only?

paaloeye9 hours ago

Interesting, LSP, DAP, MCP, and TSP now...

intrasight9 hours ago

TSP : TriSodium Phosphate. Very good for cleaning up a mess.

paaloeye7 hours ago

From Wiki:

Trisodium phosphate was at one time extensively used in formulations for a variety of consumer-grade soaps and detergents, and the most common use for trisodium phosphate has been in cleaning agents.

Ref: https://en.wikipedia.org/wiki/Trisodium_phosphate

ChrisArchitect9 hours ago

Blog posts:

Pylance + Pyrefly: bring your preferred type checker to Visual Studio Code

https://devblogs.microsoft.com/python/announcing-tsp/

Pyrefly + Pylance Integration in VS Code

https://pyrefly.org/blog/pyrefly-pylance/

beaconflint9 hours ago

[flagged]

sick_of_slop5 hours ago

[dead]

wetpaws10 hours ago

[dead]

ahgrta9 hours ago

Type-shed, type-server. When can this Python madness stop? How about using CORBA to make it even more enterprisey?

Why don't you spend your resources on F# instead of this nonsense?

SwamyM8 hours ago

> Why don't you spend your resources on F# instead of this nonsense?

Absolutely!

F# is criminally under-invested in.

rednb8 hours ago

Exactly what i came to write as well. I'd expect Microsoft to invest in F# so that python can slowly fade away the way php did.

arionmiles7 hours ago

The cottage industry around fixing gaps in Python is sometimes awe-inspiring and most times just downright awful.

Maybe just make a Python 4 with better types built in at this point...

pacman13378 hours ago

languages with dynamic types will be obsolete thanks to AI, you heard it here first. It is just introduces more errors, with AI you want formal checking, sure static types are not that, but it is a small piece of it. If 10 percent of errors are types, with a typed language keeping everything the same you have 10 percent less errors, simple as that.

wargames7 hours ago

100%. This is a solution to a problem you wouldn't have if you were just using a statically typed language. AI will naturally drive us to more rigid languages.

hn-front (c) 2024 voximity
source