HN user

math

469 karma

https://www.matthowlett.com https://twitter.com/matt_howlett

Posts1
Comments140
View on HN
Calendar 7 months ago

Saw this last year and liked it so much I added something very similar to it to Infumap (https://github.com/infumap/infumap). You can drag items of arbitrary type onto dates. When more than one item is associated with a date, a numbered button appears; clicking it lets you cycle through them. Items can be pages or links to pages, which when clicked show the page as a popup. Calendar pages in the parent page display as a list of all items scheduled for the next seven days.

I'm using SolidJS for Infumap (https://github.com/infumap/infumap), which is getting pretty big.

Two main comments that come to mind:

Because the state -> DOM mapping is non-trivial for my application, I ended up writing my own virtual DOM diffing code, a primary facet of React. I appreciate the ease of being able to circumvent this where it's not necessary and performance considerations dominate, though I admit i've not felt the need to do it anywhere yet.

The AI training data set for React is much larger. The models seem to do fine with SolidJS, though I suspect there is meaningful benefit to using React from this point of view.

Overall, I'm happy with where I'm at and I prefer the SolidJS way of thinking, though if I were to do it all over again, I'd probably just go with React for the above two reasons.

Results will vary a lot with all the parameters (of which there are many). They don’t disclose all the detail but I know they have done thousands of tests across the parameters space. I know they believe they can process sludge produced from other processes.. The industry generally is very opaque, I think for competitive reasons and also because it’s so complex/nuanced.

In the context of a company, the higher up you get (on a technical track), the more you need to operate across different projects, technologies etc. - being able to jump into new things is mandatory/expected. But having deep knowledge in something important to the org gives you a foundation on which to succeed. I would say that specialising perhaps allows you to stand out more efficiently as a lower level IC.

You can tune Kafka down fairly well if you know what you're doing, but it's not optimised for that OOTB. Or just use Confluent Cloud, which is fully managed and scales down as low as you want (costs cents per Gb). Disclosure: work for Confluent.

FWIW, I didn't mean to suggest this was coordinated.

I take the point that my comment here is of low value. I do believe related issues will perhaps turn out to be the most important of my lifetime though, and it's unusually tricky to know how they should be tackled in the public arena. Apologies for me failing to do so appropriately here.

I was affiliated with a company in Singapore which had it's bank account closed, I believe due to FACTA, even though at the time no one involved with the company had ever been to the US and didn't have any ties to the US. It was simply that the size of the account was too small to justify the associated administrative burden. FACTA has impact beyond US citizens - pretty annoying.

At the moment you more or less need to write a DBMS in your app code, but I don't think that's the end state. I think what we're seeing the beginnings of something big - it just might not seem like it yet because it's the v1 / no where near complete version. I think having all your data in a single system (Kafka, KsqlDb, ..) that allows you to work with it in cross paradigm ways will turn out to be very compelling.

there are pros and cons to having a C dependency. the main benefit is reliability (get it right once, leverage that across languages). Another benefit is usually performance. The main practical gotcha is that security dependencies are incompatible across platforms, and the best you can do is distribute a number of builds of the C dependency compatible with common platforms (but that is workable).

the go story isn't as bad as you might think. there is a performance hit with the interop, which is of the order of 20% iirc - but throughput still massive, and this is not of practical significance. The Confluent go client (a binding to librdkafka), is used to push much of the volume through two of the largest Kafka installations in existence.

there is a PR open on the confluent go client that will include builds of librdkafka in the github repo, meaning this will 'just work', without the need to install librdkafka separately in most common scenarios.

note: i work on kafka clients (including minor contributions to the confluent go client).

There is currently (much anticipated!) work underway to remove Kafka's Zookeeper dependency: : https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A...

As of v0.9 (about 4 years ago), clients have no use for a direct connection to Zookeeper, and don't maintain one.

Fat clients are more effort to make, which is a significant downside, but this is abstracted from the user and Kafka has critical mass - the client story outside Java is improving dramatically. A fat client allows for optimal availability, throughput, latency.

I've been building something very similar to this ...but also quite different. The details (around usability) have proven very difficult to get right, but I'm really excited by how it's turning out. If you like the core idea as well and would be interested in taking part in a private beta, please send me an email (contact details in my profile). I expect it to be ready for others to try in maybe a few months.

In Blazor, what is sent to the browser is a .NET runtime, then the .net assemblies (which are .NET CIL, not wasm) which the runtime executes. They seem to have this working well, but it's less efficient than, for example, Rust which has no runtime and compiles directly to wasm. C# is very much my goto language, but my eye is currently on Rust in this space because the scenarios where I feel the need for something other than Javascript in the browser are all performance related - i.e. I find React / JSX great for working with the DOM.

Why Use F#? 8 years ago

quite the contrary, people are quickly moving away from the .net framework towards .net core, which is now objectively better and moving at a fast pace. I help maintain a popular open source library for .net. We develop on MacOS using VS Code (only use Windows for testing) - the experience is good. We have many large customers (brands you would know), and .NET Core support is important to pretty much all of them.

https://github.com/confluentinc/confluent-kafka-dotnet