Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python at Scale: Strict Modules

instagram-engineering.com

Post reply on HN
Print view View original

221–230 of 259 posts

Re: Python at Scale: Strict Modules

#221

Post by angry_octet »

peteradio wrote: post #118
cpeterso wrote: post #100

Earlier quoted context omitted.

I like Python, but I often wonder how many developers use Python because they actually use dynamic language features versus just liking the languages' clean syntax and library ecosystem. I'm surprised languages that offer both REPL (for development) and AOT native compilation (for production), like OCaml, are not more popular. Evidence that syntax matters, I guess. :) mypy and mypyc are interesting but their compile-…

Names matter and OCaml is a crappy name.

If you think OCaml is bad, it used to be Caml Special Light, a play on Camel cigarette naming.

Re: Python at Scale: Strict Modules

#222

Post by angry_octet »

dgoldstein0 wrote: post #172
Sophistifunk wrote: post #115

Earlier quoted context omitted.

I think a great deal of this sort of thing could be done by just doing some eval in a dynamic state before you stop the vm and compile its stable state, rather than the actual source code.

I think you missed part of the point of what the article was trying to say - or rather, what they hoped to do with this strict python. One of those things being some form of hot code loading. A snapshot of the state can't be incrementally rebuilt - it's very much all or nothing; whereas if we know or modules are side effect free, or at least some useful part of module loading is, we could cache that part and get fast…

Sounds like they need Erlang.

Re: Python at Scale: Strict Modules

#223

Post by coldtea »

pjmlp wrote: post #213
coldtea wrote: post #208

Earlier quoted context omitted.

> Its adoption at banks and life science research labs tells another story. In all 10 of the places it was adopted? Compared to Python with the thousands of deployments "at banks and life science research labs" it's a no show....

Compared to UNIX with the thousands of deployments "at a couple of universities campus and hobbists" it's a no show....

Sure, though Python doesn't compete with UNIX, while it does with Julia for data science so not sure what the above is supposed to mean

(though, "competes" assumes Julia is getting anywhere close to Python's adoption in data science, but still)...

Re: Python at Scale: Strict Modules

#224

Post by coldtea »

pjmlp wrote: post #206
watt wrote: post #200

Earlier quoted context omitted.

Kotlin might become the default Java syntax, that's what the GP is saying. And I agree.

Java is Java. On what concerns the JVM, Kotlin hype will be over in a couple of years, and it will get as much use as Scala, Clojure, Beanshell, Groovy enjoy nowadays. Guest languages never get to own a platform, and with time all platform languages end up getting enough features that the large majority of developers never bother with extra tooling, debugging layer and idiomatic wrapper libraries of the guest languag…

>On what concerns the JVM, Kotlin hype will be over in a couple of years, and it will get as much use as Scala, Clojure, Beanshell, Groovy enjoy nowadays.

And we know that because?

>Guest languages never get to own a platform

That depends on the platform, who is running it, and how. You couldn't have a worse steering than Oracle.

And most "guest languages" are smaller affairs, they don't have companies the size of Google chosing them for Android app development (a huge niche in itself). Or have first class support from the most popular IDE of the host environment.

Plus, anything is anecdotal, as we have so few cases of major parent/host language rivalries, and even fewer cases with similar dynamics, that there's no real prediction.

Scala was too complex for most Jave-ers, too slow to compile, didn't have a Google pushing it to its platform devs but an insignificant company, etc. Clojure was a Lisp (= doomed), Beanshell and Groovy where from small, insignificant origins, and not pushed by anyone really mainstream the size of Google/FB/etc.

Kotlin doesn't have any of those issues.

Heck, even Elixir does quite well I hear.

Re: Python at Scale: Strict Modules

#225

Post by weberc2 »

qtplatypus wrote: post #165
weberc2 wrote: post #153

Earlier quoted context omitted.

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.

Go has those features in the reflect package (so as far as I know, Go is just as powerful as Python), but you’re right that they aren’t easy to use. If you do use them, it’s quite clear, and will be addressed in code review so you don’t have nearly as many dynamic typing bugs as Python—it’s not anywhere close.

Very dynamic code shouldn’t be easy; the happy path should encourage clear, simple code. By encouraging people to stay on the happy path, their code is more performant, maintainable, etc and it keeps the average code quality quite high across the ecosystem.

Re: Python at Scale: Strict Modules

#226

Post by pjmlp »

coldtea wrote: post #224
pjmlp wrote: post #206

Earlier quoted context omitted.

Java is Java. On what concerns the JVM, Kotlin hype will be over in a couple of years, and it will get as much use as Scala, Clojure, Beanshell, Groovy enjoy nowadays. Guest languages never get to own a platform, and with time all platform languages end up getting enough features that the large majority of developers never bother with extra tooling, debugging layer and idiomatic wrapper libraries of the guest languag…

> On what concerns the JVM, Kotlin hype will be over in a couple of years, and it will get as much use as Scala, Clojure, Beanshell, Groovy enjoy nowadays. And we know that because? > Guest languages never get to own a platform That depends on the platform, who is running it, and how. You couldn't have a worse steering than Oracle. And most "guest languages" are smaller affairs, they don't have companies the size of…

Because history has proven that multiple times.

UNIX and C, Web and JavaScript, Windows and .NET/C++, macOS and Objective-C/Swift, Android and J̶a̶v̶a̶/Kotlin/C++....

Google only cares to push Kotlin on Android, and it only matters because Google visibly doesn't want to move Java beyond the Java 8 subset that Android currently supports, so the choice is between an handicapped Java support or Kotlin.

Until there is a JVM written in Kotlin, and Kotlin gets first class support in all Java IDEs instead being a tool to sell InteliJ licenses, it is just yet another language that happens to target the JVM.

This ignoring that Kotlin already has a couple of impedance mismatches with the JVM, sequences vs streams, lambdas vs SAM, co-routines vs fibers, inline classes vs data classes.

Elixir is doing well because many developers seem wary to learn Prolog/Erlang syntax.

Re: Python at Scale: Strict Modules

#227

Post by pjmlp »

coldtea wrote: post #223
pjmlp wrote: post #213

Earlier quoted context omitted.

Compared to UNIX with the thousands of deployments "at a couple of universities campus and hobbists" it's a no show....

Sure, though Python doesn't compete with UNIX, while it does with Julia for data science so not sure what the above is supposed to mean (though, "competes" assumes Julia is getting anywhere close to Python's adoption in data science, but still)...

It is supposed to mean that if Linus had listened to these kind of opinions Linux had gone nowhere.

Re: Python at Scale: Strict Modules

#228

Post by joshuamorton »

weberc2 wrote: post #215
nine_k wrote: post #154

Earlier quoted context omitted.

It depends. Code reviewers glazing over copy-pasted boilerplate blocks can more easily lose track of the whole, and miss an error which is obvious when the whole is expressed in 10 lines. There is some optimal range of expressive density for comfortable use by humans. APL or K likely above that level, and Go feels below it, not as low as COBOL, but still.

The opposite is true in my experience. Most of that boilerplate is brackets and indentation, which visually frame the interesting bits, drawing your eye to them. This is, of course, subjective, but I use both regularly and at worst this is not a problem for Go.

The problem here is that there is boilerplate at all. There shouldn't be.

Boilerplate distracts from what is actually going on. I can generally identify code smells from the shape of python code (like, blur all the text so I can't read the words, and the shape of the blocks tells me everything I need), I can't do the same in go, because there's so much more indentation and visual stuff happening, and most of it (boilerplate error handling) isn't interesting.

Re: Python at Scale: Strict Modules

#229

Post by chubot »

gpderetta wrote: post #205
chubot wrote: post #192

Earlier quoted context omitted.

Probably the biggest issue is that it can't run many libraries and frameworks because they use a lot of dynamic features, i.e. reflection and metaprogramming. To be more specific: getattr, operator overloading, descriptors, heterogeneous dicts, decorators, etc. Type checking and metaprogramming are fundamentally at odds [1]. Dynamic languages like Python have more of a focus on the latter. They later added type check…

> type checking and metaprogramming are fundamentally at odds [1] I would say that dynamic metaprogramming is at odd with type checking (and optimizations, and in general understanding the behaviour of a program statically). But of course metaprogramming can be done perfectly fine in a statically typed language.

There's less conflict if you release the features in the same compiler of course, but it's definitely not "perfectly fine".

My blog posts give some more color on that, but also see:

https://discuss.ocaml.org/t/the-future-of-ppx/3766 (breakage)

https://words.steveklabnik.com/an-overview-of-macros-in-rust (breakage)

Also, OCaml has had at least 4 different metaprogramming systems -- ocamlmeta, camlp4, ppx, etc. Rust is getting its second one post-1.0 as AFAIU.

There are lots of open problems related to metaprogramming and type system design because they interact heavily.

This blog posts also hints at that: https://nim-lang.org/araq/v1.html

In contrast, in Lisp, metaprogramming is "just programming".

Re: Python at Scale: Strict Modules

#230

Post by weberc2 »

codr7 wrote: post #166
weberc2 wrote: post #153

Earlier quoted context omitted.

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…

Yeah, I get it. It’s a little disingenuous of me to say that interface{} qualifies as generics, but I can’t quite put my finger on why it is different than Python. Neither are typesafe (although mypy supports generics, but has many other issues), but in any case typesafe generics would I think improve Go.
Post reply on HN