benesch (u/benesch) - Readit News

benesch commented on Leaving Google airs.com/blog/archives/67... · Posted by u/todsacerdoti

benesch · 4 months ago

It’s hard to overstate the amount of service Ian provided to the Go community, and the programming community at large. In addition to gccgo, Ian wrote the gold linker, has blogged prolifically about compiler toolchains, and maintains huge swaths of the gcc codebase [0]. And probably much, much more that I’m not aware of.

I’ve had the pleasure of trading emails with Ian several times over the years. He’s been a real inspiration to me. Amidst whatever his responsibilities and priorities were at Google he always found time to respond to my emails and review my patches, and always with insightful feedback.

I have complicated feelings about the language that is Go, but I feel confident in saying the language will be worse off without Ian involved. The original Go team had strong Bell Labs vibes—a few folks who understood computers inside and out who did it all: as assembler, linker, two compilers, a language spec, a documentation generator, a build system, and a vast standard library. It has blander, corporate vibes now, as the language has become increasingly important to Google, and standard practices for scaling software projects have kicked in. Such is the natural course of things, I suppose. I suspect this cultural shift is what Ian alluded to in his message, though I am curious about the specific tipping point that led to his decision to leave.

Ian, I hope you take a well-deserved break, and I look forward to following whatever projects you pursue next.

[0]: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS

benesch commented on Apache Iceberg iceberg.apache.org/... · Posted by u/jacobmarble

jl6 · 7 months ago

The table on that page makes it look like all three of these are very similar, with schema evolution and partition evolution being the key differences. Is that really it?

I’d also love to see a good comparison between “regular” Iceberg and AWS’s new S3 Tables.

benesch · 7 months ago

Yes, the three major open table formats are all quite similar.

When AWS launched S3 Tables last month I wrote a blog post with my first impressions: https://meltware.com/2024/12/04/s3-tables

There may be more in depth comparisons available by now but it’s at least a good starting point for understanding how S3 Tables integrates with Iceberg.

benesch commented on Amazon Aurora DSQL aws.amazon.com/rds/aurora... · Posted by u/aws_hero

craigkerstiens · 9 months ago

It feels very disingenuous to say "Postgres compatible" and have this as a missing feature set. I'm sure they'd quickly argue it's wire compatibility, but even then it's a slippery slope and wire compatible is left open to however the person wants to interpret it.

There is no 'standard' or 'spec' for what makes something Postgres wire compatible.

This feels like a strong overreach on the marketing front to leverage the love people have for Postgres to help boost what they've built. That is not to say there isn't hard and quality engineering in here, but slapping Postgres compatible on it feels lazy at best.

benesch · 9 months ago

> I'm sure they'd quickly argue it's wire compatibility, but even then it's a slippery slope and wire compatible is left open to however the person wants to interpret it.

I actually think that they'd argue they intend to close the feature gap for full Postgres semantics over time. Indeed their marketing was a bit wishful, but on Bluesky, Marc Brooker (one of the developers on the project) said they reused the parser, planner, and optimizer from Postgres: https://bsky.app/profile/marcbrooker.bsky.social/post/3lcghj...

That means they actually have a very good shot at approaching reasonably full Postgres compatibility (at a SQL semantics level, not just at the wire protocol level) over time.

benesch commented on Thoughts on DuckDB's Grammar Patching Thing buttondown.com/jaffray/ar... · Posted by u/foldU

retrocryptid · 9 months ago

Is this "a new generation discovers DSLs"? I had 15 minutes of fame inside IBM in the 80s by saying "The good news about FORTH is you can extend the parser to create your own Domain Specific Language. The bad news is the guy down the hallway already has."

There are a couple things going on here:

1. DSLs aren't "bad." But they may require more forethought than you typically have had to apply to typical programming tasks.

2. Doesn't perl6 do something similar? It was about the only thing about perl6 I liked. Insert reference to your favourite dynamic grammar system: icon? forth? some lisps?

3. something that is sorta new to think about is SQL is supposed to be a declarative language and behind the scenes there's a planner that knows what to do to put a particular record in a particular state. And yeah, you're doing something similar, changing the semantic rules to produce an AST, which you're still using with previously coded code to determine the semantics of the thing you wrote in the new grammar. But that's essentially what the OP said here.

4. I agree with the author that maybe PEGs aren't the most awesome thing in the world, but they seem to be well understood and actually doing something is better than trying to mzke things perfect.

5. I liked the author's write-up, but as an old programmer take umbrage at the idea that changing your parser in the middle of a program is "crazy", we used to do this... well maybe not all the time... but with a greater frequency than we do today.

benesch · 9 months ago

> I liked the author's write-up, but as an old programmer take umbrage at the idea that changing your parser in the middle of a program is "crazy", we used to do this... well maybe not all the time... but with a greater frequency than we do today.

I think Justin addresses that point, though! He writes:

> The development of programming languages over the past few decades has been, at least in part, a debate on how best to allow users to express ways of building new functionality out of the semantics that the language provides: functions, generics, modules.

And indeed by modern PL standards patching the parser at runtime is very unusual.

The "modern" language that I've worked in that comes closest is Ruby, since the combination of monkey patching and the lack of symbols in the function call syntax is well suited to constructing DSLs. But most teams I've worked with that use Ruby eventually developed a strict "no monkey patching" rule, based on lived experience. At scale allowing developers to invent DSLs on the fly via monkey patching made the programs as a whole too complicated to reason about—too hard to move between modules in the codebase if every module essentially had its own syntax that needed to be learned.

I suppose describing this as "dark, demonic pathways" is a bit overstated for comedic effect but indeed "change the language syntax at runtime" does seem to be generally accepted these days as a bad software engineering practice. Works fine at a small scale, but doesn't age well as a team and codebase grows.

benesch commented on Amazon S3 Adds Put-If-Match (Compare-and-Swap) aws.amazon.com/about-aws/... · Posted by u/Sirupsen

jauntywundrkind · 9 months ago

https://github.com/slatedb/slatedb will, I expect, use this at some point. Object backed DB, which is open source.

benesch · 9 months ago

Yes! I’m actively working on it, in fact. We’re waiting on the next release of the Rust `object_store` crate, which will bring support for S3’s native conditional puts.

If you want to follow along: https://github.com/slatedb/slatedb/issues/164

benesch commented on Skeptical of rewriting JavaScript tools in "faster" languages nolanlawson.com/2024/10/2... · Posted by u/todsacerdoti

wormlord · 10 months ago

> For another thing: it’s straightforward to modify JavaScript dependencies locally. I’ve often tweaked something in my local node_modules folder when I’m trying to track down a bug or work on a feature in a library I depend on. Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.

Anecdotally I have had to do this in js a few times. I have never had to do this in Rust. Probably because Rust projects are likely to ship with fewer bugs.

Also Rust is harder to pick up but what are you going to do, use the most accessible tool to solve every problem, regardless of its' efficacy? I am not a Rust expert by any means, but just reading the Rust book and doing a couple projects made me a better programmer in my daily driver languages (js and Python).

I think speed is less important here than correctness. Every time you ship a buggy library you are wasting the time of every single end user. The correctness alone probably saves more time in total than any performance gains.

benesch · 10 months ago

> Anecdotally I have had to do this in js a few times. I have never had to do this in Rust. Probably because Rust projects are likely to ship with fewer bugs.

Still anecdotal, but I have worked on a large Rust codebase (Materialize) for six years, worked professionally in JavaScript before that, and I definitely wouldn’t say that Rust projects have fewer bugs than JavaScript projects. Rust projects have plenty of bugs. Just not memory safety bugs—but then you don’t have those in JavaScript either. And with the advent of TypeScript, many JS projects now have all the correctness benefits of using a language with a powerful type system.

We’ve forked dozens of Rust libraries over the years to fix bugs and add missing features. And I’m know individual Materialize developers have had to patch log lines into our dependencies while debugging locally many a time—no record of that makes it into the commit log, though.

benesch commented on The notifier pattern for applications that use Postgres brandur.org/notifier... · Posted by u/kiyanwang

BeefySwain · a year ago

I was actually asking about the automatic timed re-license to Apache :)

benesch · a year ago

Ah, I misunderstood! Yes, we may have invented that. I whipped up the cron job a few years back in response to concerns from our legal team. I’m not aware of any prior art for automatically advancing the change date for the BSL.

benesch commented on The notifier pattern for applications that use Postgres brandur.org/notifier... · Posted by u/kiyanwang

jjovan1 · a year ago

Ok so I was wondering if your solution is faster. I noticed their materialized views are not as fast for real time data.

benesch · a year ago

We haven't benchmarked TimescaleDB, so I can't say. Results tend to vary heavily by workload, too.

What I can say is that the research at the heart of Materialize (https://dl.acm.org/doi/10.1145/2517349.2522738) allows us to efficiently maintain computations that are more complex than what a lot of other IVM systems can handle.

Your best bet is to run your own benchmark of both systems using data that's representative of your workload. We offer a free seven day playground if you'd like to run such a benchmark: https://console.materialize.com/account/sign-up

We also have a community Slack where a number of Materialize employees hang out and answer questions: http://materialize.com/s/chat

benesch commented on The notifier pattern for applications that use Postgres brandur.org/notifier... · Posted by u/kiyanwang

BeefySwain · a year ago

I love this concept. Did you all come up with this or is there prior art? Is there a name for this concept?

benesch · a year ago

We did not originate the Business Source License (BSL/BUSL). It was originally developed by the folks behind MariaDB. Wikipedia has a good article that covers the history: https://en.wikipedia.org/wiki/Business_Source_License

Other large projects using the BSL include CockroachDB and (somewhat infamously) Terraform.

We're very glad to have been using the BSL for Materialize since our very first release. Relicensing an existing open source project under the BSL can be a painful transition.