2
points
TeeWEE
Joined 1,389 karma
Software engineer. Love Mobile!Keywords: Android, Appengine, Python, Golang, Java, NodeJS, etc. Learning Machine Learning. Experience with google cloud and AWS.
- Wow Sam Altman is so full of himself... I would never want to work for this narcist. Just watch this video. https://x.com/sama/status/1925242282523103408
- It depends. That’s the whole point.
I see a lot of people here saying one is better than the other. But it depends on your use case and company size.
GRPC is a lot more complex to start using and hides internals. However it has some major advantages too like speed, streaming, type safety, stub generation. Once you have it in place adding a function is super easy.
The same can be said of OpenAPI. It’s easier to understand. Builds upon basic REST tech. However JSON parsing is slow, no streaming and has immature stub generation.
From my experience a lot of users who use OpenAPI only use it to generate a spec from the handwritten endpoints and do manual serialization. This is the worst of the two worlds. - manual code in mapping json to your objects - manual code mapping function parameters to get params or json - often type mapping errors in clients
Those engineers often don’t understand that OpenAPI is capable of stub generation. Let alone understand GRPC.
GRPC saves a lot of work once in place. And is technical superior. However it comes at a cost.
I’ve seen OpenAPI generated from routes, with generated clients libs work really well. This requires some time to setup because you can hardly use OpenAPIGenerator out of the box. But once setup I think it hits a sweet spot: - simple: http and json - can be gradually introduced from hardcoded manual json serialization endpoint (client and server) - can be used as an external api - allows for client lib generation
But it really depends on your use case. But to dismiss GRPC so easily mainly shows you have never encountered a use case where you need it. Once you have it in place it is such a time saver. But the same holds for proper OpenAPI RPC use.
However my inner engineer hates how bad the tooling around OpenAPI is, the hardcoded endpoints often done instead of server stubs, and the amount of grunt work you still need todo to have proper client libs.
- What do you mean with validating the bindings? GRPC is type safe. You don’t have to think about that part anymore.
But as the article mentions OpenAPI is also an RPC library with stub generation.
Manual parsing of the json is imho really Oldskool.
But it depends on your use case. That’s the whole point: it depends.
- This results in me trusting Tesla less.
If this was fake, how do we know the robovans were not remotely operated? They might as well be too to get the stock price up?
There is no way to know. I am really doubting Tesla now. It wouldn’t surprise me that, in order to prevent mishaps during the event, everything is remotely operated…
People will say: that’s not true. But where did Tesla clearly specify this upfront?
I saw the initial fullscreen disclaimer. But that might also apply to the robovans right?
- Very nice!
However for our use case we want total control over the server database. And wanted to store it in normalized tables.
The solution we went for us is streaming the mutation stream (basically the WAL) from/to client and server. And use table stream duality to store them in a table.
Permissions are handled on a table level.
When a client writes it sends a mutation to the servers. Or queues it locally if offline. Writes never conflict: we employ a CRDT “last write wins” policy.
Queries are represented by objects and need to be implemented both in Postgres as wel as SQLLite (if you want offline querying, often we don’t). A query we implement for small tables is: “SELECT *”.
Note that the result set being queried is updated realtime for any mutation coming in.
It’s by default not enforcing relational constraints on the clientside so no rollbacks needed.
However you can set a table in different modes: - online synchronous writes only: allows us to have relational constraints. And to validate the creation against other server only business rules.
The tech stack is Kotlin on client (KMM) and server, websocket for streaming. Kafka for all mutations messaging. And vanilla Postgres for storing.
The nice thing is that we now have a Kafka topic that contains all mutations that we can listen to. For example to send emails or handle other use cases.
For every table you: - create a serializable Kotlin data class - create a Postgres table on the server - implement reading and writing that data, and custom queries
Done: the apps have offline support for reading a single entity and upserts. Querying require to be online if not implemented on the client.
- 2 points
- 90% of AI companies are just thin layers on top of an LLM, sometimes useful but they have all the problems LLM have (I will explain)
For existing companies with AI features: more useful but mostly LLM bolted on with the same use cases. They can improve the product if used right. But for me it’s mostly often just a gimmick.
The problem with LLMs: They mostly generate stuff they have seen and are bad as truly new stuff. They make mistakes You need to put time and energy in the review it.
For stuff that transforms data it’s useful. Like rewriting a piece of text.
It’s also useful for search queries on the corpus the LLM is trained on.
It’s good at pattern recognition and lastly: human like voice interfaces.
But for generating novel stuff: good luck reviewing it.
People who just blindly copy paste the output of an LLM: that’s quite dangerous and potentially plain wrong.
At least that’s my experience.
- It is a neat tech demo but it clearly shows the limits of AI:
- I got it to generate invalid SQL resulting in errors - it merely generates reasonable SQL, but in my case it generated to disjoint set of tables…. - In practice you have tot review all code - It can point you into the wrong direction. Novel systems often have something smart/abstract in there. This system creates mostly Straightforward simple systems. That’s not where the value is
All in all, it’s not worth it to me. Writing code myself is easier than having to review LLM code
Within our organization we have forbidden full LLM merge request because more often than not the code was suboptimal. And had sneaky bugs/mistakes.
I’m not saying these can’t be overcome. But not with current LLM design. They mostly generate stuff they have seen and are bad as truly new stuff.
- 18 points
- I don’t drink alcohol anymore. But I still drink. 0% alcohol beverages. 0.0 beers. Or <0.5% beers. I especially like IPA or Weissbeers
I still get invited for drinking. I still join parties. I still act crazy. Just without the bad side effects.
Note: going to a dance party the whole night still gives you a hangover. But because you were active. Not because of the alcohol. It’s less extreme.
- One things this articles kind of misses: You need that unique token... Ok, you can get it in some way.. But ticketmaster should keep it private, then, even if you know the algorithm. You still cant do a lot without the token......
So he reversed engineered it, but its still secure: You need the token.
Both in software hardware and handing.
https://youtu.be/P-H-GJaGiUg?si=eq8YWy8gyJ5YS99X
I think it even surpasses Chinese brands.