Hacker News new | comments | show | ask | jobs | submit login

Fantastic article - well worth the read!

One key takeaway I had is that python is closing in on its own “Perl 6” moment. It seems to me (and this is just my opinion), that I’m adding type hints, the complexity has gone up considerably. (Don’t this about the simple syntax, rather think about all the gotchas and edge cases that are going to cause productivity issues for developers in larger codebases.

I really wonder (and have for a while - only now even more so), if Python has gone about it the wrong way.

I don’t develop often anymore because it’s no longer my job, but really do love it when I get to spend time on it. And python, for many reasons, is my go to language (sorry for the pun).

But now I’m starting to look at Swift and Rust, figuring if I’m going to go thru these headaches, I might as well get a more modern language that runs fast as blazes as a nice side benefit.

I’d love some guidance from anyone who’s further down the road with this issue.




Type hints reduce complexity for me. There is no way I could work on a codebase of any reasonable size without them.

The only downside is you have to learn about a (fairly straightforward) type system. But welcome to almost every other language.


Type hints are almost always a crutch or fix for bad design/unclear data flow/`None` abuse.

The idealist in me wishes type hints had never been introduced and we would just write obvious, beautiful code. The pragmatist/realist is happy because type hints are a gradual improvement. The pessimist is saying that the bad devs who introduce awful data flow and abuse None also won't bother using type hints/getting them right, so why bother.

Pick whichever you feel is most appealing.


Type hints are almost always a crutch or fix for bad design/unclear data flow/`None` abuse.

If you've ever worked on a Python code base that you didn't design and write from the ground up, you would know that these are inevitable, and in many cases encouraged by the language. Even if you did design and write it from the ground up, and even if you meticulously document every class and helper method, the reduction in cognitive load is tremendous.

And if you are writing a library or API that other people will use, it's an extra layer of documentation convenience. Why force people to peruse your 200 word docstring when they could just see the signature pop up in their IDE?

edit -

Consider this example:

    Country = NamedTuple('Country', [
        ('iso2', str),
        ('iso3', str),
        ('full_name', str),
        ('short_name', str),
        ('other_names', Sequence[str])
    ]

    class Person():
        __slots__ = ('age', 'name', 'birth_country')

        age: int
        name: str
        birth_country: Country

        def force_standardize_name(self) -> Tuple[str, str]:
            """ Attempt to coerce a name into standardized First, Last form """
            ...
Maybe my design is bad, but just having all that information written right in the source code makes it so much easier for me to work. Not to mention, I can actually run the Mypy static checker on this and verify that my code does what I think it does.


> If you've ever worked on a Python code base that you didn't design and write from the ground up, you would know that these are inevitable, and in many cases encouraged by the language.

I have. Maybe it is "inevitable", but saying Python encourages this is a stretch. Those things happen in other languages, it's just called `null` abuse instead.

> Not to mention, I can actually run the Mypy static checker on this and verify that my code does what I think it does.

Until it doesn't, e.g. at runtime. Type hints are a nice tool, but are not a panacea. They are not the same as variable types. This is probably the most dangerous thing about them. If you want that, Python is not the best choice, type hints don't change that.


I think Swift might be closer to what you want than Rust.

I like both, but Rust and Swift are really for two very different groups and solve different problems. Rust is for the C/C++/assembly programmers who would never even think of using Java or Python. Swift is a modern Java.

If you're coming from Python, I think Swift is closer to what you want since Rust will probably seem more complex for reasons that don't have benefit for the Python-style use case.


The only thing in which Swift relates to Java is syntax. Apart from that, they couldn't be more different.

And if you start digging deeper, you get to see that Swift is a very complex language, too. It's easy to get started, probably easier than Rust, but it has its own kind of quirks.


Swift does have a lot of syntax, but it's quite well designed and that contributes to the reference guide being organised in a useful manor. So that complexity is more manageable than C++ or Rust.

Once they can remove lots of the ObjC compatibility parts, it should get better too.


If you're looking for a modern Java wouldn't Kotlin be your first choice?


You know, previously I had ruled out Kotlin due to the reliance on the JVM (long story, but I'm biased against moving to the JVM).

Thanks to your comment, I checked out the site today - looks like it can be compiled by LLVM !

So thank you - not sure where I'll end up, but it's worth me spending more time to look at.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: