kubota

I strongly disagree that SQL is broken. Try using JPA or your favorite ORM on a large project with a complex entity graph. It is a nightmare having to ctrl-click deep into the entity graph to see what annotations are on some great-grandchildren to get an idea as to what query is being executed. When working with relational data SQL has always been the ideal tool for the job on the projects I've worked on.

Kotlin had its time in the sun but it's a harder swallow now with Java's release cadence closing the gap every 6 months.

Go is a small language that is widely used and easy to pick up.

I would love if this IDE had first class support for Bazel projects. IDE support is one of Bazel's weaknesses. I feel an IDE focused on polylingual monorepos and their build tooling (Bazel) would do well, as no single IDE works well for that use case. Seems like it would be possible to whip something up using the facilities provided by the language server protocol and Google's Bazel expertise.

Jeff will be able to commission another sculpture for his yacht.

I feel like many niche AI startups that use ChatGPT / X as their foundation might learn this the hard way.

Many chose that profession with the aspirations of becoming an A list star.

So what? That's about top of band for an AI product manager. Care to compare that to top of band for an A list actor? They pull in $50M for a single film.

Part of me loves the advent of so many zero-cost-abstraction languages. The other part wishes the systems programmers would pick a winner already so that the already small community of systems programmers do not end up multifurcated into even smaller communities of Rust, Zig, Val, etc developers. I hope the systems language wars end soon in other words.

What's the point if your pr is removed from the merge queue automatically when there are conflicts introduced? I thought that was the problem it was trying to solve.

Bazel, rules_proto and its grpc rules for various languages is the tooling you are looking for in my opinion! It's so nice to be able to share your proto files and generate stubs / clients across language boundries, being able to see exactly which pieces of your application break when a shape or signature changes in a proto file. Without a monorepo, it would be hard to see the impact of proto changes across disparate code repositories.

Yes.

I've used C++ on hobby esp32 projects, this is appealing to me. I could not find details on resource usage in the documentation.

Oracle listaggs do support distinct, since 19c.

Legislatively forced RTC protocol would be welcomed by me! I am the Android user that "ruins" my inlaw's group chat.

You lost me at "While AI regulation is important" - nope, congress does not need to regulate AI.

I think AI startups will face headwinds because the established players have access to valuable model training data. For example, a large health insurance company can mine their claims data and create features and software offerings from this data, a startup will have to pay handsomely for valuable data.

Most of my apis are consumed my multiple clients, many without user interfaces (other backend systems), some with mobile user interfaces, some with web interfaces. I should make my backend clients parse HTML? Or my mobile clients parse HTML? I don't see any benefit to coupling data to a visual markup language, unless you are only serving web ui clients, and have no plans for that to ever change. Or I should stand up additional services (and pay for their operation and maintenance) just to server side render my data wrapped in html? That seems sillier to me, but to each their own.

I don't know. The tabs example on the htmx page is perceptibly slow to me. Making a rest call every time I switch a tab, each time sending 90% of the same html skeleton data over the wire feels like a sin to me. Returning html from my api also feels like a sin.

I have a tractor. Mice like to chew electrical wiring because the wire casings are made of soybeans, so the tractor dealer recommended setting several traps by my tractor. I couldn't stand killing a mouse so I used "humane" catch and release traps, the problem was a mouse died because I forgot to check the trap. So I put a reed switch and an esp-32 on a catch and release mouse trap that when tripped, sent an mqtt message to aws iot, that triggered a lambda function that sent me an email notifying me I had a mouse to let out of its trap.

When I was at a large money center bank a constant source of problems was trying to deploy the 70+ microservices backing our business unit's main application during "release weekend", or for ad-hoc reasons like the log4shell vulnerability patch. It was very frustrating for our build pipelines to compile / test / static scan the entire millions of lines codebase when only a few libraries have changed. This build often took a few hours for our largest application and at least 10 minutes for each microservice. A few times we ran into breaking api changes and only realized it after it was deployed to production. This is the use case Bazel is serving - god like observability across your organizations code base, quickly compiled.

Bazel isn't about a particular language needing its build facilities - its about ALL of your organizations languages being built with one tool, ideally in one monorepository. Its very attractive when you have lots of microservices that would otherwise live in disparate repositories. Using a monorepo and Bazel allows you to share api definitions (proto files) across your entire code base (rules_proto, rules_grpc) , so you see immediately what api changes impact existing code across your entire organization, regardless of what languages each component is coded in.It allows you to containerize (rules_docker) and deploy (rules_k8s) only the components that need to be redeployed with every commit. It allows your entire development team to live, code, test, build, and deploy in harmony.

That takes time and money on OpenAI's behalf. Alternatively they can aquire Bloop after Bloop does all the leg work of integrating their niche with chat GPT. But I agree its a tenuous place to be in as an investor / employee / cofounder of a startup that is at OpenAI's mercy. This model of relying on another vendor's product to base your own saas product on has worked in the past, and it has also failed in the past.

I assumed they were in the trenches fighting.

Do you mean pre-COVID levels?

Whatever happened to move fast and break things? Who cares if it wasn't perfect in the first iteration. It was a shot across ChatGPTs bow, and pleased the shareholders.

This is very interesting. I wonder if it would turn the "visible to you" internet into an echo chamber though.

I disagree, in my opinion micro-services hinder scalability of deployment, and development - at least the way I see most businesses use them. Typically they break out their code into disparate repositories, so now instead of one deployment you have to run 70 different ci/cds pipelines to get 70 microservices deployed, and repo A has no idea that repo B made breaking changes to their API. Or lib B pulled in lib D that now pollutes the class-path of lib A, who has a dependency on lib B. Often you need to mass deploy all of your microservices to resolve a critical vulnerability (think log4shell)

The solution to this is to use the right tool, a build system that supports monorepos like Bazel. Bazel solves this problem wonderfully. It only builds / tests / containerizes / deploys (rules_k8s, rules_docker) what needs to be rebuilt, retested, recontainerized, and redeployed. Builds are much faster, developers have God like visibility to all of an organizations' code, and can easily grep the entire code base and be assured their changes do not break other modules if Bazel test //... passes. It is language agnostic so you can implement your services in whatever language best suits it. It allows you to more easily manage transitive dependencies, manage versions globally across your org's codebase.

Of course Bazel has a steep learning curve so it will be years before it is adopted as widely as Maven, Gradle etc. But in the banks I've worked at it would've saved them tens of millions of dollars.

Also git would need to catch up to large codebases. I think Meta released a new source control tool recently that is similar to git but could handle large monorepos.

I'm excited for the Silverado EV work truck, Chevy is promising it will tow 20,000lbs by 2024, and seems very reasonably priced ~ $39k.

Coroutines are coming soon, project loom.