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

251–259 of 259 posts

Re: Python at Scale: Strict Modules

#251

Post by weberc2 »

joshuamorton wrote: post #244
weberc2 wrote: post #239

Earlier quoted context omitted.

Like I said, I disagree with this. I suspect this is either because you're very experienced with Python and relatively inexperienced with Go, or perhaps you're simply an outlier. I think if you surveyed developers who are very experienced with Python and have at least a few months of experience with Go, you'll find people say that it's easier to identify issues in Go code--and I think this largely comes down to the r…

At this point I've written fairly little go code, but reviewed quite a bit. Among those I work with, my opinion seems to be shared. > I think you'll find that visual structure is actually important. I didn't say otherwise. What I did say is that go adds visual noise that isn't present in python. (and it is noise: the proposal to add try! shows that the error handling style is noisy. It can be basically entirely remov…

> Among those I work with, my opinion seems to be shared.

Yeah, preference distributions are hard to assess. Either of us could be wrong.

> I didn't say otherwise. What I did say is that go adds visual noise that isn't present in python. (and it is noise: the proposal to add try! shows that the error handling style is noisy. It can be basically entirely removed by an automated transformation).

I’m glad we agree that terseness is not readability and visual structure is valuable. How do we meaningfully debate whether some boilerplate is noise or useful visual structure? Why is Python’s implicit propagation of errors elegant and beautiful visual structure while Go’s explicit error handling is ugly noise? Specifically how do we know that you aren’t prejudiced by your disproportionate experience with Python (even assuming my disproportionate experience with Python and preference for Go is an outlier)? What are the criteria?

Re: Python at Scale: Strict Modules

#252

Post by meowface »

weberc2 wrote: post #214
pjmlp wrote: post #181

Earlier quoted context omitted.

Yeah, never understood what a Python Dev could find attractive in Go, besides not having to deal with C instead. Which is positive mind you, but they would be better served by adopting PyPy.

Pypy is super cool, but it doesn’t solve for maintainability and it only improves performance by one order of magnitude, leaving it 1-2 orders slower than Go. Besides, IMO, goroutines are so much nicer than Python’s async.

Yeah, I totally agree. I love Python, but I can't stand Python's async situation. I don't like Go, but I think its concurrency is miles better.

Re: Python at Scale: Strict Modules

#253

Post by strokirk »

chenzhekl wrote: post #168
timothycrosley wrote: post #18

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/

It's certainly interesting to use! However, it's type checker still have a lot of work to go, since you can easily segfault due to using a nil reference.

Re: Python at Scale: Strict Modules

#255

Post by bcherny »

ashishb wrote: post #247
paulddraper wrote: post #148

Earlier quoted context omitted.

Yes gradually typed languages are usually looser/more flexible about static typing. > A caller can change sync function to async, breaking the functionality downstream. I think you mean callee? Are you taking about using a returned result? Because most languages permit ignoring return values. If you want to check out promise use, check out https://tsetse.info/must-use-promises

Sorry, I did mean callee. Consider ``` const myIntValue = f(); ``` This code will silently break when f changes from sync to async.

Right, but there will be an error where you consume myIntValue:

  const myIntValue = f()
  
  // Error TS2365: Operator '+' cannot be applied to types 'Promise' and '2'
  const myResult = myIntValue + 2
  
  async function f() {
    return 42
  }

Re: Python at Scale: Strict Modules

#256

Post by qtplatypus »

weberc2 wrote: post #225
qtplatypus wrote: post #165

Earlier quoted context omitted.

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 peop…

It is rare that I have had problems with dynamic typing errors in P* languages. I am of the view that that dynamic code should be one of two things.

1) Super easy. That way doing it right is trivial. 2) Impossiblely difficult so the only people who are doing it can be trusted to do it right.

To me go falls between those two. It’s real easy to say interface{} (indeed it is more difficult to make a non empty interface) but doing it in a way that is safe isn’t easy.

I don’t think expressive power is the point here. As they are both compleate languages. More it is an issue of what trade offs and comprises have been made.

Re: Python at Scale: Strict Modules

#257

Post by weberc2 »

qtplatypus wrote: post #256
weberc2 wrote: post #225

Earlier quoted context omitted.

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 peop…

It is rare that I have had problems with dynamic typing errors in P* languages. I am of the view that that dynamic code should be one of two things. 1) Super easy. That way doing it right is trivial. 2) Impossiblely difficult so the only people who are doing it can be trusted to do it right. To me go falls between those two. It’s real easy to say interface{} (indeed it is more difficult to make a non empty interface)…

I'm not sure (1) exists, probably by definition. And I certainly don't agree that Python makes it easy to "do it correctly". Our Python app has daily 500s due to typing errors. We also suffered for years because we would build magical things that we thought would work in every scenario but ended up being untestable and/or failed to consider numerous edge cases ("what happens if someone inherits from my magical class?") and/or which failed to extend properly ("oops, someone renamed this attribute and now all of our hasattr checks are broken, and the tests didn't catch it because they passed mocks"). Eventually we built a culture that mostly discourages magic/gratuitous dynamism, but it took years and we're still suffering from that legacy code.

These problems simply don't crop up in Go, or at least they're in a different ballpark in terms of frequency and severity. So yeah, Go lacks typesafe generics, but I'll make that tradeoff all day every day in exchange for the maintainability, performance, tooling, distribution, etc improvements that Go offers today. No contest.

Re: Python at Scale: Strict Modules

#258

Post by qtplatypus »

weberc2 wrote: post #257
qtplatypus wrote: post #256

Earlier quoted context omitted.

It is rare that I have had problems with dynamic typing errors in P* languages. I am of the view that that dynamic code should be one of two things. 1) Super easy. That way doing it right is trivial. 2) Impossiblely difficult so the only people who are doing it can be trusted to do it right. To me go falls between those two. It’s real easy to say interface{} (indeed it is more difficult to make a non empty interface)…

I'm not sure (1) exists, probably by definition. And I certainly don't agree that Python makes it easy to "do it correctly". Our Python app has daily 500s due to typing errors. We also suffered for years because we would build magical things that we thought would work in every scenario but ended up being untestable and/or failed to consider numerous edge cases ("what happens if someone inherits from my magical class?…

It seems that we have different experiences with regards to typing errors. Perhaps due to different practices, coding styles and problem domain.

Re: Python at Scale: Strict Modules

#259

Post by nimmer »

timothycrosley wrote: post #26
TylerE wrote: post #19

Earlier quoted context omitted.

nim

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…

> allowing multiple different garbage collectors

How's that a problem?

Post reply on HN