weberc2

> Already covered that.

Where? I didn’t see it.

> Programming languages can save their data as unions or structs, and take the minimal hit to switch on the type. DB's persisting data on disk can do the same but will take a much bigger hit.

Yeah, of course. Disk is more expensive across the board. Same applies for storing ints, but databases don’t punt on that. And anyway, the sum types still exist in the schema, they are just implicit, as hoc spectacles built on the fly by the user. So you’re still dealing with performance issues, but they’re worse.

> On the DBs side, it does go away. The DB only has to guarantee what it says it supports (only store one specific type in a column). So for the DB implementors, that's a great invariant for their implementation ease and performance.

This applies to every feature for every tool. You don’t have to solve the problem if you just put it on your users.

Of course, tools have charters, and the relational axiom is that users shouldn’t have to manage their own storage and retrieval layer, but rather they should declare a data model and interface with it and the RDBMS would make search and retrieval fast and correct. Sum types are necessary in data modeling, so it fits clearly and neatly into the charter.

> An aside: I wish some relation database adopted sum types: I didn't thought about the implications, but doing 'create table foo ( bar Maybe integer );' and then 'select Some bar ...' would be cool (and maybe a cleaner way to work with NULL.)

That's not an aside, that's my whole argument--RDBMSes should support sum types for all of the same reasons that we should use RDBMSes in the first place: developers describe a data model and work against that while the database storage and retreival. Postgres enums and NULL are just special cases of sum types.

> For one, because they need a fixed binary representation for the type, to persist it on disk. In a programming language yoi do things in memory, so you don't have that issue...

Memory and consequently programming languages also requires a fixed binary representation. How you represent data is orthogonal to its storage medium--you can write application memory to disk and read it back in, no problem (e.g., swap).

> Still, you could have had union types, or even coerce everything as string, as SQLite does, but it would be bad for performance as they'd need an alternate representation.

The problem doesn't go away by moving support out of the database and into the application; it only makes it worse insofar as the application is limited in its optimizations. At the end of the day, the real world has sum types, applications use them, and they are encoded into databases--they simply aren't encoded _well_ and the database isn't giving you any correctness guarantees as it does for product types (i.e., structs, records, etc).

Why should we artificially charge law abiding people for making a call? Why not disallow call spoofing? Why should we allow telecom fraud, especially when there are obvious technical solutions?

And what well-funded SIGs are our to get your phone call tax plan?

As an American, I’m curious as well.

Do any relational databases have them? I’ve never understood why not. They go through the trouble of providing a mechanism to formally model your data schema, but if your data involves things that can be one thing or another, they totally punt and ask you to find a way to hack it on top via ORMs or similar. Why not model everything in Postgres such that users can issue requests against their actual data model and Postgres can make it fast, instead of building a shim layer between the data model surface and Postgres (shim layer = ORM, in case it wasn’t obvious) that can only generate queries that are likely more difficult for Postgres to optimize for lack of missing type information.

You can statically type check a dynamically typed, interpreted language. Python via Mypy and Typescript being two examples.

Wouldn't that just be a separate case?

> Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant.

If you're operating a monolith, every release requires coordination from every team, no?

Right. I don't know what issues people are having specifically with microservices, but we're in a sort of hybrid place where we have about 30 engineers split into a few teams. We collectively build/operate ~7 microservices and a dozen lambda functions, queues, etc, all of which are deployed together about ten times per day.

This has been working very well for us, and I would like to see us buy into the microservice model more with teams that each operate one or two services instead of each team committing a little bit to every service. In that model, each team would only need to worry about their own service(s) instead of interactions across every service (or rather, this would be less of a concern).

The only piece that doesn't work so well for us is local development; we've tried Docker Compose and PM2 to run the whole fleet of services in either containerized and native-process configuration (respectively), but the former is slow due to terrible Docker for Mac filesystem performance and the latter introduces all sorts of environment sanitization/consistency issues.

Microservices might be awful for all kinds of reasons, but your pull request problem is caused by your multirepo setup, not microservices. You can have microservices and a monorepo, for example.

I get it, but it’s not a very constructive way to point out their mistake, and it seems like a good way to incite a flame war. Everything else about your comment struck me as really thoughtful.

> I know nuclear fans are a bit emotional and don't like dealing with hard facts and figures. The thought of a single person dying is too much for them to cope with and they can't make logical decisions as a result, but think about it for a while and you'll see that expensive but safe power isn't particularly helpful if there's much cheaper alternatives with only slightly higher death rates.

I don't have a dog in this fight, but comments like this hardly seem helpful and are very likely against HN rules.

Is it common to write apps that target multiple databases with SQL as the abstraction point? SQL behaves so differently across vendors (with respect to performance, extensions, etc) that I would be more inclined to write distinct queries for each vendor rather than try to find strings optimal for every vendor.

Proposing asm and deprecated APIs, "just use a portable wrapper library" as though there are any such (good) libraries, type safety, etc.

Not the OP, but Go doesn't have this problem because all I/O is async under the hood, but it exposes a sync interface. This means the entire Go ecosystem is bought into a single concurrency model and runtime, which some find irksome, but it works pretty well most of the time. Of course, Go also lacks Rust's static safety features, but I think that's orthogonal to its concurrency approach.

This isn’t a new concept; it’s been around for 60 years or more. And ageism hasn’t been the problem, because age correlates with valuable experience (tech may or may not be an outlier here); sexism is traditionally cited as the problem (the argument goes, “employers think a female candidate may have or want children and therefore be less flexible”) although to my knowledge there isn’t much evidence to support this (obviously 60 years ago sexism was a problem, but afaik there’s no evidence that links it to rigid work hours). That said, there is abundant evidence that women really do want to spend more time with their children (compared with men) and therefore prefer jobs with smaller salaries and greater flexibility.

In any case, we can’t function as a society by limiting everyone’s opportunities because someone might be discriminatory. We need to address the discrimination, and we’ve made great strides as a society.

That’s not obvious to me... care to elaborate? What languages that target wasm aren’t supported?

Maybe not, but if someone is willing to pay you for it and the deal is agreeable to you, then good deal. If the deal isn’t agreeable, then negotiate a better deal. If you can’t negotiate a better deal, find a new job, if you can’t find a new job, then your current deal is optimal. This applies where we’re talking about working more hours or less flexibility. It’s economics all the way down.

That’s unclear on my part. Prior to that sentence, I noted that some salaries are high because employers are effectively paying for the employer to be available at specific times, even around the clock. So these low-flexibility jobs have high salaries.

> There's this belief that being available 24/7 is a positive attribute in employees and we really need to squash that. It's unhealthy for everyone.

For whatever reason, employers seem to value this for certain roles, and they often pay a premium for it. This is a Good Thing for people who value money over flexibility; why lock them out of a natural fit? Perhaps you would argue that this isn't good for them, but surely they should be free to make the choice? For those who value flexibility over money, they shouldn't take those jobs. As long as expectations are communicated, there shouldn't be a problem.

Maybe this isn't a real problem, but I want to address it just in case: I'm concerned that some people may feel entitled to a high low-flexibility salary _and_ high flexibility. This sort of entitlement comes up often, and as far as I can tell, it fundamentally ignores economic realities. In other words, if these things are compatible, then proponents need to explain themselves (and provide a lot of support for their arguments) because it's far from obvious.

> Seriously? A huge cultural meme when it comes to Trump being elected was this idea that rural America was disaffected and disheartened because it had been 'left behind' economically.

I don't know where this meme came from, but I don't think it was from rural people and to the extent that it's true, I think it's more a response to the contempt ruralites have felt from the urban elite (ranging from the incessant depictions of rural America as backward and racist to the general neglect with respect in response to the most recession to the pro-illegal-immigration stance which entails competition for the rural/poor and cheap labor for the urban/elites).

Another problem with your argument is the attitude of "why do you choose to live there?" implies that people elected to move to rural areas in a time when these globalization issues were reasonably foreseeable, and it implies that it's trivial for everyone (including the rural poor) to uproot their lives and move to a city.

I don’t think I know any “rural person” who is complaining or even speaks about “being left behind”. Just my data point, but I grew up in rural America and still have lots of connections, so your claim is, uh, surprising to say the least. Maybe the impression of “rural Americans” you received while in the Bay Area / Munich was less than accurate?

I like faster and smaller, but it sounds like we are striving to make the most efficient use of resources, including developer time. "professional engineers" don't have to worry so much about this because the costs of their projects aren't dominated by their own salaries as ours are.

I’m no great fan of NYT, but the alleged point of an opinion column is to present a debate, not to host opinions that the editorial team supports. However, I think there’s a strong case to be made that this isn’t how the NYT operates in practice, and that they mostly pick articles that advance their agenda.

Honestly I'm having a hard time following your position. It sounds like you're making some kind of circular argument; that we should hire more women because they face discrimination. But the whole debate is about whether or not they face discrimination in the first place. Or maybe you're advocating for discrimination in general on the basis that a person's immutable characteristics informs about his/her character (their work ethic, resilience, etc) or their ideas (e.g., the black candidate will bring in new ideas on account of his race compared to the white candidate) with some degree of reliability?

I think clarity would improve your posts.

We don't have enough evidence to conclude that the 'methodology' concern is legitimate and not merely pretense for a political concern. We need to know about the specific concern. I'm glad she's not asking for the paper to be suppressed because if her concerns are valid, they can be vindicated through the ensuing debate; if the debate renders her concerns invalid, that's good too. In either case, we're a little closer to the truth of the matter and we can make better decisions going forward.

> 'Culture fit' is actually one of those criteria I hate: it usually means hiring similar people.

Yeah, I agree that it seems to imply something like that; I meant it in the sense of "hiring people who will move the culture in the direction you'd like it to move", which I think is what we're discussing, but I'm happy to use any such term.

> Most countries here in Europe have not made positive discrimination illegal.

"positive discrimination" is one of the terms I hate. It seems to imply that it is correcting for something when part of the debate is whether or not there is anything to correct for.

> I'm arguing for understanding that most hirers simply hire people with similar backgrounds as their own

I'm happy to accept this understanding, but not blindly. I'd like to know that it's based on robust evidence and at least the obvious counterpoints have been addressed. If the understanding is correct, it should survive rigorous debate and analysis; however, many proponents of this conclusion/theory seem to fervently oppose any such debate, analysis, etc. Hopefully we can at least agree that it would be reasonable to be skeptical of this theory/conclusion if indeed its proponents are trying to stifle debate/analysis even if we don't agree that the stifling is real.

And if you don't agree that the stifling is real, do you feel like there is rigorous debate and analysis on the topic? Do you see skeptics of the theory raising interesting or legitimate questions/issues? If so, do you believe those issues are being adequately addressed (and how so / give examples?)? If not, what issues do you perceive them as raising and why are those issues not legitimate? Can you provide a steelman argument?

> It is you who obsesses over gender I'm afraid, not me. What I am saying is that as the hirer, you are able to give someone a chance. Therefore, you can look at the potential of your candidates, rather than accomplishments. You can also look at how much you can afford a wrong hire, because it is a risk, sure.

It was ambiguous whether or not you were advocating for using gender as a proxy for "better culture fit". The GP was just being explicit that that's a bad idea.

> Knowing that people from group X (be they women, men, minorities, people from poor background without access to networks) on average are going to need bit more help than people from the right background, the right education, the right everything, that is something you can use in order to a) be the change you want to see b) run the risk of fresh ideas in your org.

It seems like you're actually arguing for using gender, race, etc as a proxy for "better culture fit" or "fresh ideas". This is illegal in most civilized places as it's immoral and based on dubious assumptions (notably that there is more inter-group intellectual diversity than intra-group diversity, i.e., all men (or women, or whites, or asians, or etc) are the roughly same).

I would really like any sort of supporting evidence for this claim. I imagine churning 28% of your employee base regardless of gender would produce a culture shift--probably a very negative one. Even more negative if you're targeting people based on their immutable characteristics--and that's before the (rightful) discrimination lawsuits start pouring in.

Maybe start with free catered lunches on Fridays or something.