HackerTrans
TopNewTrendsCommentsPastAskShowJobs

Cappybara12

4 karmajoined 2 वर्ष पहले

Submissions

[untitled]

1 points·by Cappybara12·पिछला माह·0 comments

Transformer vs. Post-Transformer Debate: Kaiser, Kosowski, Jones, Lechner [video]

youtube.com
5 points·by Cappybara12·2 माह पहले·3 comments

Apache Iceberg vs. Databricks – benchmarked

olake.io
9 points·by Cappybara12·8 माह पहले·2 comments

Claude sonet 4.5 will no longer be only for devs thing

youtube.com
2 points·by Cappybara12·10 माह पहले·1 comments

We built the fastest data replication tool in the world using Go

2 points·by Cappybara12·10 माह पहले·1 comments

comments

Cappybara12
·13 घंटे पहले·discuss
Oh yes, ofc
Cappybara12
·13 घंटे पहले·discuss
[flagged]
Cappybara12
·4 दिन पहले·discuss
He came to X to post about this instead of his very own meta threads. This just shows how much interested he is to make this thing big, and of course, the cost can stay bearable for us considering all of these cash burn that these companies are doing
Cappybara12
·7 दिन पहले·discuss
[dead]
Cappybara12
·2 माह पहले·discuss
I had the same reaction when I came to know. IMO, the panel is interesting cause Kaiser wasn’t especially dismissive of the Post-Transformer side, in his rebuttal he explicitly said he was “very sympathetic” to their arguments.

He also more or less conceded Adrian’s framing that we still haven’t had a real “PageRank moment for intelligence” yet even while defending Transformers as the strongest thing that currently works and scales on the current hardware.

One of the sharpest lines in the whole debate is probably Llion’s version of the local-minimum argument: Kaiser may be right up until the day a real breakthrough arrives and then wrong forever.
Cappybara12
·2 माह पहले·discuss
I found the disagreement striking. Kaiser argues Transformers still win unless someone shows a better scaling curve while the other researchers argue the field is overfitting to current hardware and missing better architectures.

There was a back-and-forth on scaling, hardware constraints, continual learning and latent reasoning.
Cappybara12
·8 माह पहले·discuss
For every other data engineer or someone in higher hierarchy down the road comes to a choiuce of Apache Iceberg or Databricks Delta Lake, so we went ahead and benchmarked both systems. Just sharing our experience here.

TL;DR Both formats have their perks: Apache Iceberg offers an open, flexible architecture with surprisingly fast query performance in some cases, while Databricks Delta Lake provides a tightly managed, all-in-one experience where most of the operational overhead is handled for you.

Setup & Methodology

We used the TPC-H 1 TB dataset which is a dataset of about 8.66 billion rows across 8 tables to compare the two stacks end-to-end: ingestion and analytics.

For the Iceberg setup:

We ingested data from PostgreSQL into Apache Iceberg tables on S3, orchestrated through OLake’s high-throughput CDC pipeline using AWS Glue as catalog and EMR Spark for query.. Ingestion used 32 parallel threads with chunked, resumable snapshots, ensuring high throughput. On the query side, we tuned Spark similarly to Databricks (raised shuffle partitions to 128 and disabled vectorised reads due to Arrow buffer issues).

For the Databricks Delta Lake setup: Data was loaded via the JDBC connector from PostgreSQL into Delta tables in 200k-row batches. Databricks’ managed runtime automatically applied file compaction and optimized writes. Queries were run using the same 22 TPC-H analytics queries for a fair comparison.

This setup made sure we were comparing both ingestion performance and analytical query performance under realistic, production-style workloads.

What We Found

We used OLake to ingest to Iceberg and was about 2x faster - 12 hours vs 25.7 hours on Databricks thanks to parallel chunked ingestion.

Iceberg ran the full TPC-H suite 18% faster than Databricks.

Cost: Infra cost was 61% lower on Iceberg + OLake (around $21.95 vs $50.71 for the same run).

here are the overall result and our ideology on this-

Databricks still wins on ease-of-use: you just click and go. Cluster setup, Spark tuning, and governance are all handled automatically. That’s great for teams that want a managed ecosystem and don’t want to deal with infrastructure.

But if your team is comfortable managing a Glue/AWS stack and handling a bit more complexity, Iceberg + OLake’s open architecture wins on pure numbers faster at scale, lower cost, and full engine flexibility (Spark, Trino, Flink) without vendor lock-in.

read our article to know more on our steps followed and the overall benchmarks and the numbers around it curious to know what you people think ofcourse these are numbers but it largely depends on your experience too of how you adopted in your org
Cappybara12
·10 माह पहले·discuss
Claude Sonnet 4.5 is a pretty big step forward in how AI can actually use a computer. On OSWorld (a benchmark for real-world computer tasks), it’s now scoring 61.4% just four months ago, Sonnet 4 was leading at 42.2%.

What stood out to me wasn’t just the raw numbers but how it’s being used. The Claude for Chrome extension basically lets the model act right inside your browser it clicks, types, navigates sites, fills spreadsheets, etc. It’s not just about generating text or code, it feels better and easier to work with an assistant that can actually do the work for you.

What I like about this approach is that it doesn’t feel limited to engineers. Sure, devs can use it to speed up tasks, but non-technical folks could benefit just as much since it works as a simple browser extension. While other models are chasing raw speed and size, this one seems aimed at practical usability.