Naming conventions seem like the way to go.
3,462 karma · joined November 17, 2008
jamie@scattered-thoughts.net
Naming conventions seem like the way to go.
Also the simplicity in zig comes from a major innovation in controlled partial evaluation, which we've yet to really explore the consequences of. Rust had already made a major innovation in the form of the lifetime system. It needed to figure out all the implications of that so it made sense to draw from existing designs where possible for the rest of the language rather than piling on more new and untested ideas.
jamie=# (select a, a+1 as c from nums) order by b,c;
a | c
---+---
3 | 4
0 | 1
1 | 2
2 | 3
(4 rows)It's a separate part of the grammar:
<query primary> ::=
<simple table>
| <left paren> <query expression body> [ <order by clause> ] [ <result offset clause> ] [ <fetch first clause> ] <right paren>
But, if "QE is a <query expression body> that is a <query term> that is a <query primary> that is a <simpletable> that is a <query specification>" then the <order by clause> may select columns from the <table expression> even though those don't really exist any more by the time the <order by clause> runs. It's tricky to implement.I think a lot of what makes SQL hard to implement comes down to consistently prioritizing local convenience over global complexity, combined with not being able to break backwards compatibility to simplify the design.
Eg here is the `a+1` vs `1+a` thing explained for ORDER BY - https://i.imgur.com/bklpjkP.png. Here are the conditions under which ORDER BY can reach inside SELECT to pick columns from the FROM clause - https://i.imgur.com/aoeqDGn.png.
Chapter 2 of the spec is 1732 pages of that kind of language, so it's hard to be sure that any particular behaviour is not in there somewhere. But I'm fairly sure that all the examples with set-valued functions are postgres-isms.
I think this one is in the SQL 2016 spec. There's definitely a section about how to put the AST into a normal form to compare expressions for syntactic equality.
EDIT found it - https://news.ycombinator.com/item?id=22991487
Absolutely. Even aside from safety, rust has so many quality of life improvements over C++ - algebraic data types, pattern matching, checked errors instead of exceptions, sane standard library, easy packaging, readable error messages, #[must_use], immutable utf8 strings, traits instead of templates, hygienic macros etc.
Other than compile times and editor tooling, which are being actively worked on, the only real pain point I can think of is the poor support for custom allocators.
As for other alternatives, I don't personally have strong opinions on go but I think it's notable that none of the ex-cockroachdb folks at materialize suggested using it instead of rust.
* timestamped changes eg "record foo was deleted at time 42"
* watermarks eg "I've now sent you all the changes up to time 42"
Here's the implementation of the kafka source - https://github.com/MaterializeInc/materialize/blob/master/sr.... (There's also a bit of code in the parser/planner to wire up the CREATE SOURCE syntax, but it's fairly trivial.)
KSQL has a distinction between streams and tables, effectively giving you control over how views are materialized but also forcing you to do that work yourself. In Materialize you just write the same SQL that you would for a batch job and the planner figures out how to transform it into a streaming dataflow.
KSQL is also eventually consistent - late arriving records might cause changes to previously emitted answers. Materialize won't give you an answer for a given timestamp until it can guarantee that the answer is correct and won't be retroactively updated later.
Expect to see some performance comparisons soon too.
This is correct. There is an example in the docs of dumping json records into a source and then using materialized views to normalize and query them - https://materialize.io/docs/demos/microservice/
I'm continually baffled by this kind of reaction.
I spend ~30k USD per year - more than the average american and more than 99% of the world. I live in a nice apartment with a garden, a 10 minute commute from the centre of one of the most expensive cities in the world. I buy organic food from the local supermarket and eat out multiple times per week. This year I vacationed in Tenerife, Greece, Italy, San Francisco and Vancouver.
This is, by any reasonable standards, a life of luxury. And on a typical FAANG salary it would take ~7 years to save for retirement - https://networthify.com/calculator/earlyretirement?income=13...
You would think most people would be interested to learn that their level of wealth opens up the option of complete financial independence in a comfortable middle class lifestyle before the age of 30, but instead it's always straight to yelling about dried beans.
The article suggests being able to save 89k per year. Under reasonable assumptions, 7.5 years of saving at this rate will support an income of 31k / year (the median US salary) for the rest of your life, leaving you with ~50 years of runway for whatever else you care to do.
This is especially interesting if the thing you actually want to do is something that is valuable to society but not profitable eg maintaining free software or raising a child.
https://networthify.com/calculator/earlyretirement?income=12...
From my notes:
* Soviet collectivization. Inspired by huge mechanized farms in the US. Vision of doing for farming what assembly lines did for manufacturing. Both Soviet and US attempts to do so failed badly. Party resorted instead to martial law and grain seizures, creating peasant uprisings. Forcibly relocated peasants into standardized, pre-planned mega-farms which were ruled by agricultural specialists. Ignored local conditions, vastly over-simplified and over-abstracted different areas of land and differently-skilled populations. Pressure from above to deny failures led to plans quickly losing contact with reality. Peasants gained most of their food by farming their own private plots in their little free time. Peasants effectively became indentured slaves, stripped of any cultural institutions that might be a focal point for rebellion, and naturally responded with terrible productivity. More deaths from starvation that WW1 and civil war combined.
* Compulsory villagization in Tanzania. Similar story. Government (with support of the Western world) wanted to modernize the peasantry. Forcibly relocated peasants to standardized, pre-planned villages. (Was supposed to be voluntary, but top-down pressure for results led to initiative-taking). Peasants were moved vast distances, rendering their deep local knowledge worthless. (Peasants don’t come in standardized, fungible units). Forced to apply Western farming techniques which failed badly in the local climate and ecology. (The peasant practices of dense polycropping turn out to be much more effective in climates with high primary productivity than monocropping and ridging as is common in the West). Authorities heard reports of atrocities but insisted they were isolated cases.
* And again in Ethiopia. Lead to widespread famine.
For example:
> The hash table used by the authors of ART in their study was a chained hash table, but this kind of hash tables can be suboptimal in terms of space and performance due to their potentially high use of pointers.
> Our experiments strongly indicate that neither ART nor Judy are competitive to the aforementioned hashing schemes in terms of performance, and, in the case of ART, sometimes not even in terms of space.
https://www.victoralvarez.net/papers/A%20Comparison%20of%20A...
I specialize in systems engineering and performance optimization. I can help you:
* handle big data without building an expensive distributed system
* replace complex hand-coded data pipelines with simple declarative languages
* improve response times and reduce server expenses for your web service
* use web assembly to speed up hotspots in your web app
* train your team in Rust or Julia
"Jamie is a first principles thinker with a deep understanding of systems and algorithms. He is fearless in the way he approaches problems. Jamie’s research on staged compilation saved our team many person years of effort, and his training and support was crucial to our adoption of Julia. I hope to have the opportunity to work with him again soon."
-- Molham Aref, CEO, RelationalAI
"Jamie brought a degree of rigor and theoretical knowledge that took the company to places we never could've gone otherwise. From exploring the implications of language semantics to building high performance database engines, he didn't just help us get things done, he helped us get them done right. As a result, we were able to explore in weeks what could've easily taken years."
-- Chris Granger, CEO, Eve
"Jamie took over the latexsearch engine, our most technically challenging project to date, and turned it from a foundering prototype into a successful service with over 200k users. His engine required only one small server and ran uninterrupted for over 5 years with no errors."
-- Brian Bishop, VP Platform Development, Springer
jamie@scattered-thoughts.net
Blobs is less a data-format and more a replacement for C's ability to cast arbitrary memory locations to structs.