Arrays and tuples are very different. Arrays are homogeneous structures, all entries have the same type. Tuples are heterogeneous, so entries can have different types.
2,776 karma · joined April 17, 2011
If you want to do something more OLAP-ish or insert data in bulk, you have a huge problem. SQLAlchemy is far better, even though SQLAlchemy also has its own share of limitations (dealing with jsonb_to_recordset and functions like it for example).
So you also have to make at least 150k+ to make up for that. If you were to make significantly less than that, say 120k you’re probably worse off in the end.
This is usually not considered when people talk about pre-tax salaries. Ultimately though that’s just accounting, really that is part of the money you earn.
Our company is also not aiming to pay above average salaries, as explained company wide by people on a VP-level.
Context: 4 years of work experience.
The difference is just in when you get the error and what kind you get. Do you get errors at runtime or does the compiler complain?
I would argue that doing some of this in Python with no language support at all, is in some ways more manual than Rust, where you get at least assistance.
Ownership and borrowing in Rust is solving a much bigger problem than what has been traditionally understood as memory management. Put another way: Other languages even with GC only solve memory management partially.
Rusts approach has downsides with cyclic data structures, that’s true but how often do you implement those in real world code? Async can indeed be tricky, that requires a bit of time to wrap your brain around but I think it’s getting better.
If you do very low level stuff, you might think about that a bit more but then you have to in any case.
The German word for 2 is "zwei", which is relatively close to and even rhymes with the word for 3 "drei". "Zwo" is used to make it easier to distinguish the two.
If that's a problem you find yourself having at all, much less regularly. You have a serious observability problem.
That would be a crime in Germany, you can go to prison for and they are actually very very close to crossing that line, if they haven't already overstepped it.
Quite frankly I doubt it's possible to recover from that without removing the founders (currently acting as CEO and CFO) from the company.
[0]: https://www.postgresql.org/docs/current/datatype-json.html#J...
The problem is not just the risk associated with AGPL, it's also that the benefit is actually quite small. I think most companies would be a lot more willing to use AGPL, if there were any compelling projects using it.
At Zalando everyone has read access (except to secrets). You can request write access with a command line tool another employee can then approve it. There is also an option to request access with an incident ticket, in that case you immediately get write access without approval by someone else. Write access expires after 1h.
Access to the underlying AWS account uses the same mechanism.
If you're hiring people at the very top or with rare skillsets, like building browser engines, building databases or people whose skill is at author/contributor level to relevant technology (for the job in question), you're probably not going to go with the usual process anyway as there is less uncertainty.
If you reject someone who would have been a good fit but still hire someone good eventually, that’s ok.
A bad hire is not fun, not for HR, not for the hiring manager, not for the colleagues and ultimately not for the person who got hired. Especially if they had to move for the job, possibly with family.
A bad hire has massive negative consequences for many people. Of course you want to avoid that, if that comes at the cost of not hiring someone who would have been great occasionally, that’s unfortunate but acceptable.
The voting population in this case would consist of politicians in the legislative branch.
In that context running postgres on K8S makes a lot of sense. You already have K8S and experience running it. Running postgres there makes it possible to share resources between databases and other applications. That improves utilization which means you can reduce costs significantly.
Another advantage is that unlike managed solutions such as RDS, you can use a more recent postgres version and postgres extensions that RDS doesn't support. Extensions such as PgQ or TimescaleDB or ...
Having said all of this. In a large organization, you have the benefit of economies of scale. Large fixed costs (such as developing the expertise required to run (postgres on) K8S reliably) can be amortized. It's possible for this to be a good idea, even a best practice for large organizations while at the same time a terrible idea for smaller ones. Most of the time, using a managed service like RDS is probably a better choice. In other words: You are not Google. You are not Facebook. You are probably not even Zalando. Figure out what's right for you.
You can run more queries concurrently but then the database just switches between those, which usually means worse latency and not potentially worse throughput.
As you wrote yourself an application handles request probably by doing a few database queries. As a consequence regardless of how many requests you can handle concurrently, they are probably all bottlenecked by the number of CPUs on your database server.
All of this is probably true regardless of whether you are using async or sync io. However with async io you have some overhead.
Of course, if you also happen to be doing other kinds of IO, say HTTP requests to other services in addition to or instead of those database queries. This might look a bit differently.
tl;dr: It really depends on what your application is doing.
It's also definitely a zero-cost abstraction as I can see because the manual solution that's equivalent to get_len1() would be to essentially call free() on things. That would ultimately suffer from the same problem.
Personally I think the problem is not that ORMs are leaky abstractions, it's that they often pretend not to be. SQLAlchemy just leaks unapologetically, if you struggle with ORM you can drop right down to using an DSL to construct SQL or just write SQL directly without feeling like you have to fight the ORM and mess with undocumented internals you shouldn't be touching.
So no, this is not a big task. It’s not a task at all.
This is not entirely true. Democracy is a broad term and different democracies work very differently.
In Germany for example political parties are quite powerful, politicians have to be elected by party members, there are no primaries like in the US. Being a politician in parliament or becoming chancellor in Germany requires a political career that takes quite some time.
This excludes people in ways that are both good and bad. On the good side someone like Trump would have no chance at all because he lacks the political track record and relationships. On the bad side politicians in Germany are not a very diverse group. There is a strong bias towards older people, people who've been in politics for their entire life and people in professions that allow for spending time as a politician in parliament for a couple of years and continuing in their regular job afterwards. In practice this means teachers and lawyers, at least in Germany.
They do protect other people from the person wearing the mask spreading the virus. The consequence is that for masks to work at scale a large number of people need to wear them.
That's quite common take on C though, which is not that wrong, if you go back in history far enough. It's quite wrong today though.
However you'd definitely pay less than 400/month. If you're paying more than 200/month, you got quite unlucky. In some places, such as Berlin, childcare is free.
To the extent cost is a a factor, it's unnecessarily high due to these aforementioned issues[1]. So I don't think money invested into self-driving cars hurts trains and rail infrastructure.
[1]: https://www.vox.com/policy-and-politics/2017/1/1/14112776/ne...