- dolmen parentI don't get the logic of cleaning dishes BEFORE putting them in the dishwasher.
- I think there is still space for an alternate Go syntax for scripting with the following constraints:
* a single file exposing a "main" package and its "func main()"
* import syntax that merges requires from go.mod (import both packages and modules)
* simplified error handling (just ignore returned errors in code, and they are caught by the transpiler to be handled as fatal)
Those are my ideas to go beyond my own goeval that already allows to run Go oneliners. https://github.com/dolmen-go/goeval
- Also, for Go oneliners: https://github.com/dolmen-go/goeval
(Disclaimer: author here)
- But first ensure that the input error is properly reported to the client in the response body (ideally in a structured way), so the client could have figured out by himself.
If a fix is needed on your side for this matter, having a conversation with a customer might be useful before breaking more stuff. ("We have no state code in EU. Why is that mandatory?").
- TLDR: I agree.
A library might also be used in multiple place, maybe deeply in a dependency stack, so the execution context (high level stack) matters more than which library got a failure.
So handling failures should stay in the hands of the developer calling the library and this should be a major constraint for API design.
- Check varlink, an alternative to D-Bus defined in the SystemD world.
- > An important part of adoption will probably be bindings to other languages. The libraries are all in C++, but since they aren't very big (by design), making Rust / Go / Python bindings shouldn't be hard for someone experienced with those languages.
If the the protocol is that clean, make a formal specification for it that can be used to generate client code.
A binding to C++ is definitely not what I want in my Go program.
- AI are good at JS because basically there is a ton of JS code available publicly without usage restriction: the JS code published to be executed in your browser. Most of JS code attached to web pages has no explicit license, but the implicit license is that anyone can download it and run it. Same for HTML and CSS. So using that public code to train models is a no brainer.
- > Users uploading their own stuff completely willingly to some sketchy service
> Getting the user to run the malware themselves
Here are two good reasons for not trusting a password manager that stores your vault online.
On the other hand, most people have no backup strategy for their digital life.
- Cosmocc and Cosmopolitan are remarkable technical achievements and llamafile made me discover them.
The llamafile UX (CLI interface and web server with chat to quickly interact with the model) is great and make easy to download and play with a local LLM.
However I fail to see use cases where I would build a solution built on a llamafile. If I want to play with multiple models, I don't need to have the binary attached to the model data. If I want to play with a model on multiple operating systems, I'm fine downloading the llamafile tool binary for the platform separately from the model data (in fact, on Windows one have to download the llamafile.exe separately anyway because of a limit of the OS for executable files).
So Cosmopolitan is great tech, the llamafile command (the "UX for a model" part) is great, but I'm not convinced by the value of Cosmopolitan applied here.