albertwang

Here’s the spaceX announcement (non-paywalled): https://x.com/spacex/status/2046713419978453374

SpaceX’s announcement (non paywalled):

https://x.com/spacex/status/2046713419978453374

great news, this looks great! is it just me, or do most of the english audio samples sound like anime voices?

Media commentary: https://venturebeat.com/ai/huaweis-new-open-source-technique...

http://archive.today/9HkLP

I definitely get your point, but over-generalized comments like these are also dangerous.

Just as there are many MBAs who were or are veteran software developers, the HN community is large enough that there are many members who are professional investors.

The Met has a video overview of the exhibition:

https://youtube.com/watch?v=3CxZ2PrXQ1M

https://www.metmuseum.org/exhibitions/listings/2021/medici-p...

Sorry if it's a bit of an enterprisy-response, but please reach out! We are supporting some non-cloud commercial customers on a case-by-case basis. The reason for this is that we find the support and maintenance burden to be much higher with a non-cloud delivery model, which isn't always a great experience for either party. We also have a managed product (where the data plane resides in your environment) that may work, depending on your infra and security requirements.

Re: custom code -- our codebase is fully source-available and open to contributions, but the source+sink code going through some refactoring to make it more beginner-friendly. Depending on your consistency requirements, we also support Debezium and our own CDC format (https://materialize.com/docs/connect/materialize-cdc/) for folks who want to bring in their own data sources. (For quick prototypes, we also support csv/json/plaintext source types, as well as SQL INSERTs!)

Exactly! Since most ELT tools (including Airbyte) support json + csv output formats, those work perfectly well with Materialize out-of-the-box. I'm playing around with Slack+Stripe Airbyte sources to try and come up with some fun dashboards to show off in Materialize as we speak.

As cirego mentioned, we (Materialize) have the TAIL operator, which was built to allow users to subscribe to changes:

https://materialize.com/docs/sql/tail/

Nothing we can share publicly at the moment yet, but if you reach out and chat, we're more than happy to give you some numbers that I think will address what you're looking for!

Do you happen to have any examples of real-time queries or apps you would be interested in?

Re: the second point — you’re right, Materialize has historically leveraged existing upstream systems (like Kafka) for things like persistence. But we also hear you loud and clear that not everyone wants to stand up Kafka :)

Donanemab slowed cognitive and functional decline of patients with mild Alzheimer’s by 32% compared with placebo

Link to press release: https://www.prnewswire.com/news-releases/lillys-donanemab-sl...

We’re very aware of ksqlDB. I would recommend this video from last week where Matthias talks about some of the strengths and weaknesses of ksql: https://youtu.be/KUQuegJ4do8

Here's a 15-minute introduction to Timely Dataflow by Frank, our co-founder: https://www.youtube.com/watch?v=yOnPmVf4YWo

As George points out above, we haven’t added our native persistence layer yet. Consistency guarantees are something we care a lot, so for many scenarios, we leverage the upstream datastore (often Kafka).

But to answer your question, yes, our intention is to support separate cloud-native storage layers.

Materialize is a bit more of a lower-level technology, and less of a single "feature". I've included some example use cases built on top of Materialize in my other comment.

In addition, while Materialize does support connecting to other databases, to power "real-time materialized views", a common architecture we are used for is to present a SQL view on top of streaming systems (such as Kafka or Kinesis).

Here's an overview of Materialize that explains the relationship between Timely Dataflow, Differential Dataflow, and Materialize, starting at 23:20 - https://materialize.io/blog-cmudb/

(Responding from the perspective of Materialize, the technology and company built on top of Differential Dataflow) Some examples we're seeing interest for:

Building realtime, low-latency (< 10 sec) dashboards. The type of things where you previously would have had to wait for several hours or a day for ETL pipelines to crunch through a lot of numbers.

We're also fielding interest for streaming ML applications. Ie, moving from batch models to streaming models.

Also worth pointing out that Differential Dataflow has been around for awhile, while Materialize is fairly young. We're still constantly learning about new applications!

Out of (self-interested) curiosity, what are you referring to with the "nvme->timely dataflow on a laptop" reference?

The closest benchmark I could find was the "FASTER State Management for Timely Dataflow" paper from ETH Zurich, but that wasn't run on a laptop.

I'm a PM @ Materialize. Regarding the questions from the OP's link:

#1 -- Postgres is built in C, while Timely/Differential (which underpin Materialize) are built in Rust. Materialize could be a Postgres extension at some point, but for now we want to control the stack (to more easily do cross-dataflow optimization, etc)

#2 -- We are absolutely interested in exposing an API to enable new data sources (and data sinks!). It currently takes a bit of time to understand some basic Timely Dataflow concepts, but we intend on documenting this and opening things up. We're also trying to understand user requirements around things like durability guarantees and UPDATE/DELETEs (Feel free to email me or hit us up in our public Slack as well).

If anyone is interested in sending data via HTTP POST, we'd love to hear more: https://github.com/MaterializeInc/materialize/issues/1701.

Source appears to be here: https://github.com/StanfordSNR/gg

Some more info linked here: https://news.ycombinator.com/item?id=16570548

Salesforce Press release: https://www.salesforce.com/company/news-press/press-releases...

2016 article with more details: https://arstechnica.com/tech-policy/2016/03/ibm-sues-groupon...

It links to the original lawsuit (https://arstechnica.com/wp-content/uploads/2016/03/IBM.Group...) as well as the 4 patents: 5,796,967, 7,072,849, 5,961,601, and 7,631,346

Link to the research paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3195066

From the abstract: Using algorithms to analyze the blockchain data, we find that purchases with Tether are timed following market downturns and result in sizable increases in Bitcoin prices. Less than 1% of hours with such heavy Tether transactions are associated with 50% of the meteoric rise in Bitcoin and 64% of other top cryptocurrencies. The flow clusters below round prices, induces asymmetric autocorrelations in Bitcoin, and suggests incomplete Tether backing before month-ends. These patterns cannot be explained by investor demand proxies but are most consistent with the supply-based hypothesis where Tether is used to provide price support and manipulate cryptocurrency prices.

Disclosure: I work at Datadog --

Tracing requests across services and hosts to identify bottlenecks is one reason why Datadog decided to build a tracing component in APM! A flamegraph is one such method to visually infer critical path analysis that Datadog APM supports. Some obvious things to consider are ease of setup and whether the libraries and languages you use are supported. Some not-so-obvious things to consider are:

  (1) whether you wish to infer this from a single request, or across multiple requests, 
  (2) how to define "interesting" traces -- as you could be collecting millions or billions of traces in production 
  (3) how to create a bigger, "aggregate" picture across individual traces.  

Note that on Robinhood you're only entering a "pre-ipo" bid but are not participating in the ipo -- i.e., you aren't guaranteed that your order will fill at any point

Source: https://support.robinhood.com/hc/en-us/articles/115000902306...

To add -- a better comparison in the open-source world might be Zipkin or Pinpoint, which aim to offer similar tracing capabilities with language integrations.

There's frequently a lot of confusion in the APM market -- As you might have noticed, there's a lot of overlap in what both tools can do. Graphite is primarily used for time-series metrics, whereas AppDynamics is a full-stack APM vendor.

In other words, Graphite can be used to aggregate any metric you're interested in (such as CPU usage), which you would then correlate with other relevant metrics (such as number of web requests/second). If you're specifically interested in tracking application-level performance (what is my website throughput or where are my endpoint bottlenecks), you would need to find an integration for your specific environment, or custom instrument your application.

AppDynamics also has graphing features, but aims to bundle any other relevant use cases an application developer or operations person might need. For instance, it includes service topology maps (see which services are running on your infrastructure, and are talking to which other machines) and application logs (to parse unstructured text). They have also built many integrations (to collect relevant metrics), usually for large enterprises.

Except Bobby Axelrod doesn't have a "Billionaire Pig" which gets to live in it's own room and retire on a vegan farm: http://www.businessinsider.com/steve-cohen-did-have-a-pig-20...

You have a few hardcodes that assume where the service is being run: https://github.com/fatiherikli/klassify/search?utf8=%E2%9C%9...