Hacker News Reader

That is a double edged sword. Sure, that dynamically typed language of python or ruby might be quick to develop on but they often contain a lot of surprising bugs.

Compilers catch a lot of bugs before your software is in production.

I don’t know. I keep seeing this argument. I’ve been developing on the Django stack for the past 10+ years. I have fixed many bugs if mine and of others. It has been extremely rare, if at all, that they were bugs caused by an incorrect type. The closest I can think of is a typo in a method or class name, but is it really a bug if you catch it instantly? These are just not the types of bugs that end up creeping into the code.

In the meantime Django provides productivity like you can’t get many other places. It’s just a pleasure to work with and aside from a couple of setting-related places it’s code is a pleasure to read.

Has Django's ORM syntax changed recently?

If not, this is the first time I've heard someone say it's a pleasure to read/write.

I've done lots of Python over the years (Zope3, Django, flask, aiohttp, custom stuff...), and if there is one thing I wouldn't like to come back to, it's Django.

Sure, it's a do-everything toolset, but the syntax is an abomination (imho, at least, though I hope that doesn't need to be stressed every time).

To contrast ORM syntax, look at old SQLObject, Canonical's Storm or both SQLAlchemy's declarative and core implementations.

It has not but it has expanded and been polished up. I used to be pretty anti-ORM because I felt like they were leaky incomplete abstractions. Having used SQLAlchemy for a major project in the past (used it on top of Django instead of the built in one) and then coming back to Django’s, I can say that Django’s is to me easier and nicer to use. The performance is now on par with the SQLA declarative implementation. I never really loved the core implementation for being as verbose as it was. I would rather write SQL directly at that point.

About the only place where I dislike Django’s ORM is stuff around aggregation and annotation. The fact that the order in which you declare your annotations matters is annoying af and while I understand the need for it, I do wish there was a better way. Having said that, I have simply started structuring my models in a way that doesn’t require complex aggregation and that made my life a lot easier. If I have an instance of a Book model I know what fields to expect it to have and don’t worry about whether this particular time it has some specific annotation attached to it or not. That has made the rest of the code a lot cleaner.

Basically, I think to each their own, but I don’t see the Django ORM as a negative. Give it a try and see how it works for you especially if you can avoid going against the grain with it.

Tests catch bugs too. As will pylint and mypy.

Even pyflakes will catch the most numerous bugs.

I used Python on the backend for years and have taken to Go, the verbosity feels like a minor complaint to me, productivity in either language feels about equal to me but the end product is just better in Go. Better performance, better packaging and deployment, etc. I still use Python a lot for other things.

> Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for their size.

I once tried to get into a large Python project, and even the IDE (PyCharm) had trouble "guessing" the function parameter types. It's absolutely not scalable. I don't want to be reading a function and guessing "what the hell is the type of this?".

Good news! Since ten years ago, you don't have to!

    def myfunc(foo: Dict[str, MyObject], bar: int, baz: str) -> List[MyObject]:

This would be nice if everyone used that. When I looked at the source code for mayan-edms, they weren't using that.

Apache airflow? Doesn't use it. Jupyterhub? Doesn't use it.

I was happy to see projects like Zulip using this, but if it's optional then I can't rely on people actually using it. It's the same thing with ruby/sorbet.

That’s shifting the goalposts a bit. You can use optional typing in your project as it’s scales, and there are plenty of projects that have been stable for what they do through other testing. Pick dependencies carefully and use typing as needed

I'd say typing is even more important when you are using other people's code with your code. It's also a huge productivity boost too when the relevant methods and types are available to you, the editor almost writes the code itself!

The projects that don't use it probably need to maintain compatibility with Python 2, for whatever reason. I expect that more and more codebases will be at least somewhat typed as Python 2 is deprecated everywhere.

This is the same programming community that is half stuck on Python 2, no way should anybody expect types to have reached majority mindshare.

I've only heard this "stuck on Python 2" FUD from non-Python programmers, you may want to get your arguments with the times.

Weird of you to assume that I don't work in Python. Do you just not interact with the scientific Python community? Your anecdata that is blind to large swathes of the community is no more valid than my firsthand experiences. This comes off as defensive, not informed.

It's an objective fact that Python 3 was not adopted quickly (given various EOL deadline extensions) and that plenty of libraries are stuck on 2, so your point that types have been around for 10 years is not really an argument that I can actually expect to be able to use types when working within the ecosystem.

I work in web development, Django moved to 3 exclusively versions ago, and I drop support for Python 2 pretty easily in the libraries I maintain. numpy requires at least 3.7, same for pandas, and sklearn is at least 3.6. When you say "half stuck in Python 2", do you mean you have a lot of legacy code you don't want to update? Because I don't think that's Python's fault.

Ah, so the answer to "do you interact with scientists" is no, even though scientists are responsible for a huge amount of the python code that exists. Got it, maybe consider that your experience isn't universal.

I don't know why you think dismissing legacy code is valid! More code is old than new in the world, and the idea that you're only going to run into codebases with the most up to date versions of software seems pretty naive to me.

Serverless runtimes have historically been behind on Python versions, Airflow had a hell of a time with dependency issues and Python 2, etc etc.

I also don't really care whose fault it is - the question isn't "is Python morally wrong", the question is "can I rely on the technology that you offer as the solution to a problem as being actually used by the community and therefore actually a viable solution to the problem." Python type annotations are not popular.

> I don't know why you think dismissing legacy code is valid!

Because everyone everywhere has legacy code. In that sense, Python isn't split between versions any more than any other language, making that statement moot.

If you want to use type annotations, you can, for years now. If you want to use macros to generate macros in Rust, you can, it's not Rust's fault if you're stuck on 1.20 and don't want to upgrade.

I agree that all languages have legacy code, that was sort of my point :)

> If you want to use type annotations, you can, for years now.

Yes! And it's a cool feature. Can I expect most libraries to provide types so that I know I'm calling them correctly? Is it going to be an uphill battle for my team to use them, because the community at large doesn't find them necessary? The default for a majority of Python codebases is to not use types, and that's totally fine, but that also means that rather than type annotations solving the super-grand-OP's concern, they're going to potentially add friction.

It's likely, and that's FINE, that you're going to be in dynamic-land when you're working in Python, due to the preferences of the community, and it's cool that you can use annotations if you yourself want to get some nice signature checking.

But you don't need the libraries to have type annotations for them to be useful to you. You can use the libraries' classes as types, and type signatures are already very useful even if you only use them in your code. I agree that they will be even better when morelibraries declare them too, but I find that type annotations are a huge benefit in my own code either way.

I think we can agree on that - my point primarily is that:

1. In my own code, they are super helpful

2. I still get really frustrated when I'm calling other libraries (I had this experience when the various typed JSes were fighting it out as well) - in fact for a lot of web-style work that I do MOST of my code is calling a library, which is where I'd get most of the value.

Sure, I agree with that. More libraries supporting types would be great. I don't know why they don't, it's not like they need to support any Python versions that don't support types... I guess most just haven't gotten around to it.

> It's absolutely not scalable.

And yet, somehow YouTube muddled along through and made it work.

And Instagram, and Dropbox (backend and client), and ...

People always forget that none of the things we stress about (code cleanliness, architecture, UX,...) make or break a product.

It's some weird combination of solving an actual problem decently enough (iow, it does need to work most of the time :)), good timing and some arbitrary pick up by the masses.

Like Google succeeded because they provided a no-frills search that had no ads, and geeks like us started pushing it down the throats of our non-geeky friends as The One True Search.

I ain't saying that Python leads to bad code (because you can have bad code in any language, just like you can have good untyped Python), but that there's this talk of scalability like it's some msgic thing that's impossible if all the stars are not aligned.

I agree that it's harder as the project gets bigger, but at the beginning you don't have to worry about that. By the time these problems become real limitations, you hopefully have a business and enough revenue to deal with them, which could include rewriting parts of or the entire application in a statically typed language if necessary.

"If you're just launching, your focus should not be on performance or how easy it is to dockerize but to figure out who your user really is."

I agree here but I should note that my main focus is spending less time debugging errors at runtime and in production, and avoiding errors in the first place. This is primarily why I use rust.

"Not sure the verboseness of either golang or rust"

Verbosity has nothing at all to do with implementing good, robust code. You could do it in python, rust, or another language. With certain languages you don't have to spend time writing guard code because it's handled natively by the compiler, type system, or both.

" dynamically typed languages (arguably) makes it easier to change things,"

They make it easier to change things, not necessarily correctly. With modern IDEs refactoring is not an issue.

"Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for their size."

I am aware of this, but I can't help but wonder if they would be able to iterate much more quickly knowing that the compiler and type system eliminate entire classes of bugs. Sure, you might be able to get to running code a little bit faster, but if you have to spend time guarding it and debugging runtime errors... is it really faster?

===

There seems to be this mindset that being fledgling startup means no time for silly things like types or compilation, etc, only iteration. If one actually does their market research and figures out who their users are and what they want, one should be able to iterate just as quickly in i.e. golang or another compiled language with a healthy ecosystem.

I have not worked at a FAANG company or a company even remotely the size of those companies, but I have created and maintained somewhat large ruby on rails codebases. Debugging runtime errors became my bane, especially when I could not guarantee that the persons writing the ruby code were following modern practices (or any practices at all). Not that I think compilers are perfect, but they -do- catch so many errors, some of which may have made it into runtime.

> If one actually does their market research and figures out who their users are and what they want, one should be able to iterate just as quickly in i.e. golang or another compiled language with a healthy ecosystem.

That's the key thing. You don't know until you put people in front of what you're building, to understand if you're actually solving the problem. Or even if the problem you're aiming for is the right problem. Hence you want a non-verbose and simple program that is easy to adopt to changes you want to make. Verbose languages that enforces you to be very strict, doesn't allow itself to change as much as a non-strict one. You're right that it's more error-prone, as you don't have the same guarantees. But in the beginning of launching something new to the world, you are gonna need to focus more on what needs to change, rather than how correct something is.

I agree with you. I've worked at several startups and they start with 'productive' languages like python, ruby, and PHP. These are great for getting something up and running easily.

Everything looks great at the beginning. They have features, customers and a growing codebase full of technical debt. Debt that I think would be greatly reduced if the code was compiled.

Maybe it is the price you need to pay to be successful but I doubt it.