There's something so mind-blowing about being able to run some code on my laptop and have it be able to literally talk to me. Really excited to see what people can build with this

The whole team worked really hard on this one, please try it out and share any feedback!

I will wait when its available for the plus users but if it becomes available in the API and the price is reasonable then it will definitely change website automation testing.

Definitely check out Speakeasy— we've been using them and the experience + team are fantastic

Fabra is built for the modern data stack, meaning our customers already send all of their data to a central data warehouse as their single source of truth.

It looks like Chartbrew connects to various third-party tools directly, which can lead to silos/discrepancies in our experience.

Chartbrew founder here, just wanted to clarify for readers that Chartbrew doesn't store any data from the 3rd party tools so there's no silo problem. It queries the data sources, computes the data, and stores only the chart configurations.

The only storage Chartbrew does is to cache the data while building a chart so the data source is not queried too many times and the user can see changes quicker. Afterwards, Chartbrew keeps the charts updated with data coming directly from the other tools.

But allowing for integration with multiple data sources doesn't mean you can't use only one if you prefer so. Does Fabra also store the data, or only connects to an external data warehouse?

Exactly! We don't store any data and natively connect to external data warehouses. This means we're way cheaper— no need to move data or store a copy.

I understand, then what's the advantage compared to ChartBrew? Not having the multi-data-source feature doesn't sound like an advantage.

My take is you should always just store any third-party data sources in your data warehouse, where you can then join it with all the other data. Having a feature like this just enables bad practices, and we'd rather be opinionated about how the data stack should look.

Since this is the "best practice" architecture, we've made the decision to focus on integrations with data warehouses specifically— Snowflake, BigQuery, etc. I don't think Chartbrew has these.

Not the OP, but:

Oftentimes data teams have those data sources in the warehouse already (or a process for ETLing new ones in).

Copying data only once means lower costs (maybe) and fewer inconsistencies.

Plus if they’ve done work to join/clean/transform the data in the warehouse they can take advantage of that for product analytics without having to reinvent the wheel in ChartBrew or Mixpanel.

We aren't a data warehouse, just the query-building and visualization layer. We let product teams easily do things like build funnels, measure trends, and more with the data they've already collected.

From your tagline:

> Build funnels and measure trends directly on your data warehouse, without paying for costly ETL and duplicate storage in outdated analytics tools.

Not being snarky, I just don't understand. The output of an ETL is data in your data warehouse. Then you build reports on top of the DW.

How does Fabra prevent me from needing an ETL?

Reverse ETL would be a better description here— think data warehouse -> Amplitude

That's right, we're an Amplitude competitor— but run the queries directly in our customer's own data warehouse.

Appreciate the feedback, will be uploading more screenshots shortly.

Hi everyone! I wanted to share Fabra— product analytics for the modern data stack. Fabra runs directly on your data warehouse, meaning we don't add another data silo or need you to setup costly ETLs.

In addition to self-hosting our open source product, we also offer a hosted version which is WAY cheaper than other tools since we don't store any data.

Let us know if you have any feedback, you can always reach me at nick@fabra.io

the whole concept of the ISS is pretty crazy-- humans have had people in space there almost continuously for decades

Mir was occupied continuously from 1989 until August 1999. There was then an interlude until November 2000 when permanent occupation of ISS began.

It's a shame in a way that Mir didn't hang on for an extra 18 months

And just like that, we've been set back by 10 years in waiting for a chair at the Milky Way Galactic Federation of Planets, which requires a 100 year continued presence of humans in space.

What kind of Galactic Federation defines their requirements in terms of time intervals defined by the orbital period of some random planet using numbers that are nice and round but only in some alien base?

It's mostly a coincidence. It's defined as three times the half-life Rhodium 101.

A Hollywood scriptwriter federation.

In all fairness, Mir soldiered on way longer than it was designed to, and in the last year or two had basically constant issues.

Skylab is pretty cool, occupied for half a year in the 1973, much earlier than I had known we had people hanging out in orbit

https://en.wikipedia.org/wiki/Skylab

This seems like goroutines for java?

More powerful. Java threads are objects with a standard API for managing them, and you can do things like await concurrent work without rolling your own command protocol using channel pairs and hoping some goroutine out there might still be answering. A JMX client can even show them in a GUI.

This makes the same concept radically cheaper by not involving the kernel, which is great because Java hasn't had green threads for a long time, and doing everything async in small worker pools worked but has admittedly been pretty painful.

That’s the idea, just like coroutines in Kotlin.

Coroutines in Kotlin are only a compiler trick, and are stackless. Go and Java's are stackful, reifed: small stack chunks are moved in and out of the heap to the carrier stack.

This means you get an actual meaningful stacktrace when debugging, and not something stemming from a mysterious event-loop thread.

In Java you could save your coroutine state to disk, and wake it up later in theory.

----

EDIT: This being said, I'm 99% sure Kotlin is going to pass Loom's goodness onto their developers when it's available, probably reusing the existing coroutine API.

Kotlin is placing themselves into a corner by trying to go everywhere and married Android.

So for every JVM/Java feature post Java 6 that gets introduced, they will have the dilemma of how to integrate them into a way that keeps language semantics across compilation targets, having multiple solutions to the same problem (Kotlin's one and what each platform later introduced), or just expose them via KMM and leave the #ifdef burden to the community.

That is why platform languages always carry the trophy, even if they are the turtle most of the time.

Well, so far that hasn't been an issue. Kotlin is a pragmatic language. The differences that currently exist can be addressed just with an annotation here or there. Also, Kotlin's features are designed whilst paying careful attention to what the Java guys are doing. Look at how records have played out. You can use JVM records from Kotlin transparently, you can create them by just adding an annotation (not that there's much point in doing so, as records are mostly a labour saving device that Kotlin already had).

Value types are perhaps a better example. Kotlin has them already with nearly identical semantics to Valhalla, but without the ability for them to have more than one field due to the need for erasure. Once Valhalla arrives, Kotlin can simply remove that restriction when targeting the JVM, perhaps add another annotation or compiler flag to say "make this a real Java value type". No language changes needed beyond that.

Kotlin is semantically so close to Java already that they aren't really growing apart, they're growing together. It works well enough to justify its usage, for me.

JVM history is full of pragmatic guest languages.

Yes, and it's richer for it. Java is definitely not the last word in language design!

Indeed, it just has the same role on the JVM as C on UNIX, JS on the browser,....

Just like those, it will slowly adopt whatever is more appealing from the guests and then carry on its merry way, while the other slowly lose their relevance while newcomers try yet again to challenge the place of the host language on the platform.

It sure is a dilemma. Java is catching up. When (if) Java introduces null-safety, Kotlin will loose much of its lustre, at least to me.

Virtual threads are superior to coroutines, which are still a pain in the ass in Kotlin, cause issues with mocking and you can't even evaluate them in the repl.

Kotlin's null safety is only a selling point when one uses 100% libraries written in Kotlin.

PMD, SonarQube and nullable annotations have long sorted that problem in our Java projects.

> PMD, SonarQube and nullable annotations

Not a fan of any of those tools, tbh. Still better than nothing I suppose, but I'd rather use Kotlin in the meantime.

They're talking about it and waiting to see if `?` pays off in C# and Kotlin before moving on it.

From C# point of view, I have hardly seen anyone use it outside conference talks about new C# features.

Right now there are 20 years of having null as default and turning it on just generates endless warnings.

So it is left for complete new projects where almost no third party libraries are being used, which right now is very little.

I also hope that C# 10 doesn't get !! for checked parameters, but it might already be too late.

Interesting, got any links?

I do not, but as always this is the Java way. Being the last mover is how Java moves forward with features. They let other languages experiment first so they don't have to support a bad feature for eternity because of Java's backwards compatibility promises.