An oral history of Bank Python • Hacker News Board

Re: An oral history of Bank Python

#331

Post by decafninja » Tue, Nov 09, 2021, 2:22 PM UTC

harel wrote: post #311

bantatoes wrote: post #304

Earlier quoted context omitted.

I think this would have depended on the teams/individuals you worked with. I recall some devs being completely clueless about environments - my code (that depends on dozens of other files) in uat is producing different outputs compared to my code in dev, why? Some didn't know how to debug. Many went on to FAANG as senior engineers (including Uber when it was the next big thing), hedge funds (citadel, 2s), startups (t…

I have no doubt the people who BUILT Quartz are top notch. Users of it... Mileage varies i suppose.

The builders/maintainers (AKA the "Quartz Core Team") seemed to have a poor view of the users (AKA the "Line of Business" development teams). Of course you wouldn't catch them saying that openly, but it was sometimes implied during interactions. I will admit, that view was not completely unwarranted.

Re: An oral history of Bank Python

#332

Post by bloblaw » Tue, Nov 09, 2021, 6:17 PM UTC

AnonymousPlanet wrote: post #330

bloblaw wrote: post #236

Earlier quoted context omitted.

If you compare Python's deployment and dependency management to those of statically compiled languages like Go, Rust, Zig, or Nim, you quickly see the experience with Python is quite poor. In all the above languages, you simply ship a statically compiled binary (often just 1 file), and the user needs nothing else. With any sufficiently complex Python project, the user will need: 1. virtualenv 2. possibly a C compiler…

Or you just provide your own Python package. Most of the time that will be less than 100 MB if you don't include huge libraries. You can test and build automatically. For deployment you then have an installer or rpm that is probably smaller than most of the other enterprise software your customer's infrastructure admins are handling.

The problem is "less than 100mb" is unacceptable (for my use cases).

There are use cases where 100-300mb is no big deal and customer can handle this.

But single binary deployments with a statically compiled language where a fully-featured binary can weigh in from 5-30mb are what I'm after.

And honestly, with upx I can take even those fat Go binaries down from ~35mb to 7-8mb. That's an order of magnitude less than 100mb of Python and all it's dependencies. Not to mention with all those languages I mentioned (Go, Rust, Nim, Zig), I get multi-threading and high-performance as well.

Re: An oral history of Bank Python

#333

Post by CRConrad » Tue, Nov 16, 2021, 1:04 PM UTC

int_19h wrote: post #225

lmm wrote: post #20

Earlier quoted context omitted.

> The part about programming languages frequently not having tables is interesting. The closest as mentioned is the hash, but you lose so much in that abstraction eg the relational aspects. The counter argument then becomes the obvious: why aren't you using a database library, or in a pinch, sqlite? Rightly so. Why would you add relational tables to python rather than have a generic python database spec or a collecti…

Funny thing is, databases were tightly integrated into programming languages all the way back in 80s - that's exactly what dBase was, and why it became so popular. FoxBASE/FoxPro, Clipper, Paradox etc were all similar in that respect. And yes, it made for some very powerful high-level tooling. I actually learned to code on FoxPro for DOS, and the efficiency with which you could crank out even fairly complicated line-…

> FoxBASE/FoxPro, Clipper, Paradox etc were all similar in that respect.

> the efficiency with which you could crank out even fairly complicated line-of-business data-centric apps was amazing, and is not something I've seen in any tech stack since.

Did you ever get to try Delphi? Those "line-of-business data-centric apps" is what it was all about.

And I'm not quite sure, but I think and hope Free Pascal / Lazarus is close to that in ease and power.