Live data from Hacker News

Python at Scale: Strict Modules

instagram-engineering.com

161–170 of 259 posts

Re: Python at Scale: Strict Modules

#161

Earlier quoted context omitted.

> As orf said you have no idea about their codebase. I do too: It's Python and it's several million lines. Metaphor: you've got three pallets of goods and have hired three trucks to move them. I don't have to know how you wrapped the pallets to know that you brought two too many trucks. I don't have to know the details of what's included in "Instagram Server" et. al. to make this call (obviously) based on my experien…

I'm not sure what good these kinds of bets are. All code could be made leaner and smaller. What's your point?

> I'm not sure what good these kinds of bets are.

I'm just putting some numbers on my confidence level.

> All code could be made leaner and smaller. What's your point?

That Instagram's code could be made much leaner and smaller. I feel like I've been very clear about that.

Re: Python at Scale: Strict Modules

#162
post #92

Earlier quoted context omitted.

It's a good question. Why would you pick Java over Go or C++?

Why would you pick Go or C++ over Java? C++ is a hydra of complexity, sure it has it's place, but it's not nearly as productive as Java for your typical web application. Go is almost the opposite, so simple it lacks features like generics. The last time I used Go it had fundamental usability issues around dependency management(although I think recent versions have improved on vendoring a little).

> C++ is a hydra of complexity, sure it has it's place, but it's not nearly as productive as Java for your typical web application.

Modern C++ well is as productive ( probably even more productive ) as Java. The main issue with C++ is recruitment, C++ engineers are rare because C++ is barely teached.

Re: Python at Scale: Strict Modules

#164
post #159

Earlier quoted context omitted.

On that note, I'd include Erlang. It's not gradually typed, per se, but you can have a fully dynamic language (no type specs, no Dialyzer), a completely optimistic static analyzer for inferring types and warning where it's inconsistent (Dialyzer runs), and then you can add specs where needed to tighten up and improve what Dialyzer can catch, to basically be a fully static language.

Dialazer is pretty bad and not even close to a static language.

That critique is a bit unspecific but I tend to agree.

I have heard good a stuff about "gradulizer" though. It uses a gradual type system instead of dialyzers success typing.

https://github.com/josefs/Gradualizer

Re: Python at Scale: Strict Modules

#165

Earlier quoted context omitted.

Go may "feel" like Python, but it's almost nothing like Python in actual practice. It's not dynamic (and doesn't even have generics), and its error handling is dramatically different.

It _is_ like Python in practice (I use both languages all the time). That’s largely why you see it used in many of the same places as Python. It has dynamic features by way of interface{}, which is every bit as “generic” as what Python has to offer. :) But yes, the error handling is different—values vs exceptions.

I am of the view that interface{} is the worst of both worlds with regards to static/dynamic typing. Dynamically typed languages typically have type coercion and structures that make dealing with vars with unknown types easy.

However golang doesn't have that. So you get the danger of a dynamic language without the features that make powerful.

Re: Python at Scale: Strict Modules

#166

Earlier quoted context omitted.

Go may "feel" like Python, but it's almost nothing like Python in actual practice. It's not dynamic (and doesn't even have generics), and its error handling is dramatically different.

It _is_ like Python in practice (I use both languages all the time). That’s largely why you see it used in many of the same places as Python. It has dynamic features by way of interface{}, which is every bit as “generic” as what Python has to offer. :) But yes, the error handling is different—values vs exceptions.

Go has generic types the same way Python has macros, or the same way C++ templates is a functional programming language.

C has void *, writing generic code using it is hell. Enough so that people went through a lot of trouble creating C++ and later Rust to escape it.

I'd say the type casting from interface{} to whatever you assume is in there qualifies as different.

Pretty much every single aspect of these languages is different from what I can see, the only thing they have in common is included batteries, the rest is growing popularity and consequences thereof.

Re: Python at Scale: Strict Modules

#167

More and more I want someone to create a new language that amounts to a strict subset of Python, with mypy built-in, and is compilable into machine code. Python has by far my favorite syntax, community, and in my experience leads to the greatest productivity. There just happens to be a lot of overly dynamic features, that aren't even used by most, but used just enough to hold back optimization and structural improvem…

I completely agree. With python I need ten packages. With the shit show of JavaScript I need 100 conflicting packages. Why bother on a backend framework like js. it's a worthless language for backend development

Re: Python at Scale: Strict Modules

#168

More and more I want someone to create a new language that amounts to a strict subset of Python, with mypy built-in, and is compilable into machine code. Python has by far my favorite syntax, community, and in my experience leads to the greatest productivity. There just happens to be a lot of overly dynamic features, that aren't even used by most, but used just enough to hold back optimization and structural improvem…

How about Nim? It has Python-like syntax and is as fast as C. https://nim-lang.org/

Re: Python at Scale: Strict Modules

#169

More and more I want someone to create a new language that amounts to a strict subset of Python, with mypy built-in, and is compilable into machine code. Python has by far my favorite syntax, community, and in my experience leads to the greatest productivity. There just happens to be a lot of overly dynamic features, that aren't even used by most, but used just enough to hold back optimization and structural improvem…

How about Nim? It has Python-like syntax and is as fast as C. https://nim-lang.org/

Answered this below:

> I've been tracking nim, and would agree it's the most promising so far! I feel though that it's trying to be too flexible in many ways. Examples of this include allowing multiple different garbage collectors and encouraging heavy ast manipulation. I'm also afraid it is different enough to keep it from attracting a significant amount of developers from the Python community. Nonetheless, it's something I plan on using and contributing to, since it's the best option so far.

Though, now that another commenter pointed out mypyc: https://github.com/mypyc/mypyc I believe I'll invest my limited free-time in that project instead, as it will allow me to stay within the Python community and eco-system that I love so much.

Re: Python at Scale: Strict Modules

#170

More and more I want someone to create a new language that amounts to a strict subset of Python, with mypy built-in, and is compilable into machine code. Python has by far my favorite syntax, community, and in my experience leads to the greatest productivity. There just happens to be a lot of overly dynamic features, that aren't even used by most, but used just enough to hold back optimization and structural improvem…

Very much this! For numerical computing, Numba + llvmlite attempts to do it.

I don't know however if this approach could be extended to other domains - say making a web framework. Given, python classes let you do so much tinkering, any attempts to port existing code will probably need a lot of rewriting?

Post reply on HN