SpaghettiX

But that would be the same argument for using electron? Why use this and not electron?

I had the same issue with a different key on 2 separate macs. A 1 and a 2 year old MacBook pro. 95% of the time I'm WFH using magic external keyboard, which also has the same problem so I bought a new one. Keyboards are a massive problem at apple.

I agree. The author seems only happy with RAG, insert nail/hammer quote.

I think of contradictory examples where the article doesn't make sense: LLM Chat products are just the product of training data. Generative coding applications take 1 prompt and generate a lot of code.

What this article did make me think is the existing Chat UI in coding apps are too limiting. Some have image attachments, but we need to allow users to input more detail in their prompt (visually, or by having a pre-generation discussion about specifics). That's why I think product engineers will benefit from AI more than non technical folk.

Also, do you have resources that align with those opinions?

Drone startup | Senior Software Engineer, Fullstack Software Engineer | 2 days/week in the office (London, UK) | UK citizens only

You'd be working with other passionate product engineers who previously worked at Google, Amazon, Helsing, Darktrace and Improbable. You'd be working alongside me in building a modern, ground control station application for drones using web technology. For my project, we use React, Tailwind, drizzle-orm, SQLite, Postgres, maplibre, deck.gl, Node, Python, asyncio, FastAPI and more.

Examples of things we're building: low latency data and video streaming services for collaboration, or intuitive/modern applications for planning and performing drone missions.

If interested, please reach out to my temporary disposal email: demise-collar-lurk@duck.com

We highly value passionate engineers with personal projects or technical hobbies. We also value collaboration: pair programming, discussing, teaching and learning from others.

I mostly mean the text editing functionality I guess. Visual Studio Code is the IDE I use

Stealth startup in drones | Senior software engineer, Fullstack software engineer | currently remote, but potentially 2 days/week in the office next year (London, UK) | UK citizens only

You'd be working with other passionate product engineers who previously worked at Google, Amazon, Helsing, Darktrace and Improbable. You'd be working alongside me in building a modern, ground control station software for drones using web technology. For my project, we use React, Tailwind, drizzle-orm, SQLite, Postgres, maplibre, deck.gl, Node, Python, asyncio, FastAPI and more. We highly value passionate engineers with personal projects or technical hobbies, over leetcode engineers. Examples of things we're building: low latency data and video streaming services for collaboration, or intuitive/modern applications for planning and performing drone flights.

If interested, please reach out to my temporary disposal email: whole-heap-justly@duck.com

PS: I value collaboration: pair programming, discussing, teaching and learning from others. One positive signal is that I've gained 27k points on StackOverflow. Bonus points if you've demonstrated positive impact/glue in teams and organisations.

Absolutely! Imaging setting a bunch of css styles through a long winded AI conversation, when you could have an IDE to do it in a few seconds. I don't need that.

The long tail of niche engineering problems is the time consuming bit now. That's not being solved at all, IMHO.

This checks out with someone I know who grows their own plants, and me, who doesn't spend time growing plants. We're both not interested in the product.

Maybe it has a niche. Millionaires who want to go on holiday but still like to grow plants. It seems more like a gimmick.

I still use StackOverflow. Not as much as I used too, thanks to GPT, but still multiple times a day. What I find is that I spend less time on SO.

However, IMHO deleting questions you originally wrote in the past is hurting other users more than it is hurting AI training.

Other users cannot write similar answers to yours, because it doesn't add anything and they'd get downvoted or deleted. So if you hadn't written your answer years ago, others could've written something similar. Also, other users may have commented on your questions/answers. Their efforts would be lost/deleted if you deleted your questions/answers.

Thanks for your previous contribution to the community. But I would say the worst you should be able to do is remove your name/anonymise your posts, not just delete them.

Has anyone also used an interesting alternative, Elysia, and understand the differences? Both are quite modern, ergonomic frameworks.

I haven't used it, but Tooljet is the open source Retool. Also, there's AppSmith and Budibase. Both open source.

https://www.tooljet.com/

https://www.appsmith.com/

https://budibase.com/

There is an even longer and useful list on https://git.herrbischoff.com/awesome-macos-command-line/abou...

FYI for anyone who seems this, the website says:

Just kidding, Drizzle is free and open-source. You can still make your contribution!

What alternatives do you recommend, and why?

I've heard of syncthing a few times. I'm trying it now on Android + macOS, seems to work well.

What do you like about LogSeq?

I tried doing that (I pay for Obsidian Sync, and have a lot of plugins so I run only the bare minimum plugins I need on mobile), but app start time and syncing time on mobile makes this quite a bad experience. Instead, when I need to write something quickly, I create a temporary Google Keep note.

When I'm back at my laptop, I merge it into my Obsidian Vault.

Whilst you're here, when can we expect D1 to be distributed instead of a single instance, and when will D1's API to be stabilised?

Thanks :)

Edit: I just found https://blog.cloudflare.com/d1-turning-it-up-to-11/ so I'll read that first

Thanks for your reply.

I hit the CPU time limit a few months ago. I was paying for unbound and my account default was on. I guess I also hit the memory limit (128MB).

Perhaps we should reply on: https://community.cloudflare.com/t/long-running-webcrypto-ap... and https://community.cloudflare.com/t/options-for-password-hash.... Though I'm not sure if it will work, certain algorithms might take more than 128MB.

Nice article on optimising tRPC on serverless functions, thanks!

Some of my thoughts: This is a problem that manifests only if you use serverless. also, unfortunately the solution shown is service-specific. The code to split tRPC routers into multiple API routes is different for Next vs. Cloudflare Workers, and so on.

I've enjoyed engineering serverless applications over the past few years, but there are some weird challenges like this one. Other issues (I use Cloudflare Workers) is that it: - runs your code on V8 and not NodeJS, so you don't have the Node APIs (though it tries to add compatibility). - has CPU limit: makes it impossible to resize images or even hash passwords using bcrypt. - Running locally has been a pain (though emulators / miniflare have been developed in recent years).

I would suggest most projects should avoid serverless and stick with conventional technology.

Its impossible to resize images or hash passwords on Cloudflare workers: the CPU time limit is too low.

I don't see how this makes Cloudflare interesting for AI. I suspect the same problems will exist.

This isn't so different than running onnx in a worker without constellation, and using KV directly?

The negative is it's such a closed ecosystem.

Please stop the spam and disclose your affiliation with this competitor.

Genuine question: I wonder why you didn't think to disclose your relationship with the product? I notice this a lot, and it ruins my perspective of the product. Haven't you seen people start their comments with "full disclosure, I made this" type sentences.

(Hi, thanks for reading, I'm the author).

In this case, the article uses the term pension to include "defined contributions", like in https://www.moneyhelper.org.uk/en/pensions-and-retirement/pe....

Countries have various mechanisms to save for retirement and it’s wise to do so Could you elaborate on why is it "wise to do so"? On paper, these contributions is free money.

In practice, you don't have access until retirement and the law can change at any time. (See article for more disadvantages that are often overlooked or not mentioned.)

How can anyone forecast the economy in 40 years? It looks like people rightfully "avoid trusting the employer", but how can anyone trust the governments more than employers?

Hi, thanks for reading it. I'm the author. I'm sure others might understand the pension world more than me - I wanted to share my perspective. I was offered a pension match in th past, some were good (e.g. up to 7% match).

I didn't include the "positives" of having a pensions, because that's common knowledge about pensions. I might improve this article based on your concerns.

Yes, is free "pension-money", but until you take it out, it means nothing. Some of the disadvantages in my article are more certain to actually happen. All of the disadvantages I noted need to be resolved before you get your extra 7%-matched pension money.

Is the risk worth it? For me: no, pensions are not worth the risk.

I appreciate some events can be asynchronous for clients, for example: actions taken by other users, or events generated by the system. However, I do think implementation details (using async in the server) should be encapsulated from clients: when users save a new document, it's much easier for the client to receive a useful albeit delayed response, rather than "event submitted", wait for the result on a stream. Of course, other relevant clients may need to hear about that event too. The service architecture should not affect / make-life-harder for clients.

Therefore I think disagree with both parent and grandparent comments. Use each when they make sense, not "synchronous by default" (grandparent comment, though I do think there are good points made), or "asynchronous based on service architecture" (parent comment).

But my better solution is to pull the async-ness all the way out to the client: https://matssocket.io/

Is that a solution that you use? I took a look at matssocket https://www.npmjs.com/package/matssocket, it currently has 2 weekly downloads. :thinking:.

Thank you for outlining the dumpster fire that is the British Pound.

Thanks

It's nice to hear that NATS is tackling this problem space. I'll give it a try.

I disagree that simply because it is not advertised as a "edge" technology that it is not one of the best-in-class techs for edge. It simply means, we are doing a poor job at awareness.

It's very easy to say "NATS is for everything", which seems to be the case here. It would be great if that was backed up with evidence.

Currently, the only people I see talking about NATS for edge is Synadia - they're also not very specific. In theory/documentation, "edge" is a core NATS use case, but in practice why does NATS compare themselves to Kafka and microservices? Most of that playlist is not edge-focused. Can you explain what concepts and problems you have to solve to support the "edge" - none of that is in your website.

The issue you called out is a Firefox-specific issue, but it will be addressed and not indicative of an inherit limitation of NATS.

My point is NATS is not being used in browsers, mobile apps or edge use cases. It doesn't even explore the concepts. It looks like it doesn't care about Firefox. For IoT, what does NATS bring on top of MQTT? NATS ends up being an MQTT broker so it will have to compete with all of them.

Why don't you start comparing yourself to products and technology that serve the edge (other edge-focused companies (ably, pusher, pubnub), and other MQTT brokers)?

Side note: Would appreciate it if you disclosed your affiliation with Synadia and NATS before advertising it.

a big benefit of that that full stack developers, will be able to communicate between web app and backend services in the same way that services talk to each other in a secure and reliable way

In practice, I have not seen that manifest as a benefit. Services have a dramatically different environment than edge devices. Tools built for services (NATS, Kafka, gRPC) do not translate well to the edge. The latter is used by a group of people who don't care or understand the edge-edge-cases: when a user drives through a tunnel and is disconnected, or when they restarts their device, or is throttled by an OS, etc. One issue I found with grpc-web (the alternative to grpc that supports browsers) is that it's severely limited by connection count by the browser - making streams completely useless). Also, grpc-web is neglected by Google.

NATS does not look ready, and is not designed for use, in browsers or mobile apps. It's not a use case that Synadia/NATS care much enough to even mention on their website.

(react + flutter) in my case

How are you using NATS in Flutter? Using the client library that hasn't been updated in 20 months, with no link the repository and 4 upvotes? Or writing your own custom library to connect using websockets. If you use websockets directly, you'll be writing extra code to handle disconnections, retries, qos, etc.

Even with NATS jetstream, NATS has a focus on service communication.

"It supports websockets" and "qos" does not mean it will work robustly with web apps if nobody uses NATS for that use case. See https://github.com/nats-io/nats.ws/issues/172 for an example issue. If NATS is not used for websockets in browsers, it will have a mine field of issues to fix. And what about all the other clients (mobile, mobile web)? Sure there may be a NATS client library for it, but it won't handle user connectivity issues, because again it's aimed at service communication where the network is great.

People are using NATS in kubernetes, not web browsers.