101–110 of 121 posts
> At Microsoft, we believe in the value of using our own products, a practice often referred to as "dogfooding". One would think, unfortunely that is not how it looks like in the zoo of native Windows desktop development, or Xamarin/MAUI adoption in their mobile apps.
Seems like this exists in a similar problem domain as pkl? https://pkl-lang.org/index.html
1. Read a .pkl file from disk and generate (for example) a Person struct with a first, last name and an age value.
2. Let's say that according to some TypeSpec, the HTTP endpoint /greet accepts a POST request with a JSON payload containing a first and a last name. You convert your Person struct into a JSON literal (and drop the age field in the process) and send it to the HTTP endpoint
3. You should receive a greeting from the HTTP endpoint as a response. The TypeSpec may define a greeting as a structure that contains the fields "message" and "language".
4. You can then use pkl to write that greeting structure to disk.
Sidenote: pkl also supports methods[1] but in almost all use cases you only use pkl to define which fields your data has. TypeSpec cares most about the methods/endpoints. Of course, you still need to define the shape of the arguments to these methods and that is where you have a bit of overlap between these two technologies. I can imagine that you would generate pkl definitons from TypeSpec definitions.
[1] https://pkl-lang.org/main/current/language-reference/index.h...
I wish any of Typespec, Cue, Pkl, Dhall, etc. would just implement their core functionality in C with an ABI for other language bindings. Needing to use whatever dep they decided to operate with as part of adoption of the language itself is a big ask. I want to try out your config language, I don't want/need all of node to make this happen.
Since CUE is written in Go, you can output a .so that is then used like your C based desire, if I understand you correctly
Earlier quoted context omitted.
FastApi can generate the OpenApi yaml
not everyone writes Python, and not everyone starts code-first
Bespoke languages are a hard sell and incur significant extra effort on the team building this. 1. People don't want to learn bespoke languages. 2. You have to build all the ecosystem tools for a language (compiler, docs, language-server, IDE integrations, dependency management) Similar endeavors are WaspLang and DarkLang, which I have yet to see in the wild or (meaningfully) on HN. Better to use an existing language…
Thanks for hof! Thinking of using it for a project. In what state is the project? I noticed that commits slowed down lately and I was wondering if you consider it stable at the moment and can be used as is.
I've been working on some AI related stuff lately, part of the reason for the slowdown. And actually using hof myself for real work
Code gen is pretty stable. I've been meaning to fix the TUI keybindings on mac before releasing the current beta. Was also hoping the the evaluator improvements would land upstream, but that hasn't happened yet...
I'll take a stab at releasing a new version this weekend, per your inspiration
Earlier quoted context omitted.
Moreover, compiling an IDL to N languages is substantially easier than compiling implementation code across N languages, especially when generating idiomatic code is a requirement. A language purpose-built for this task is going to produce better results while having substantially lower complexity. (My $0.02 as someone who works on TypeSpec)
I would have expected a bit more than type specifications, maybe some behavior specifications also? Something like Daan’s type states. But I get why we are still splitting hairs over data types.
Earlier quoted context omitted.
Both of them. Both of them are wrong.
When one starts gluing together a lot of data pipelines full of JSON trash and from all kinds of systems with incompatible data types (whether or not “lol what’s an integer?” JSON is involved), one quickly comes to appreciate why things like Protobuf exist and look the way they do.
And then one proceeds to spend days trying to mash that JSON mess into a protobuff and debugging segfaults, rather than just getting the job done with HTTP.
> At Microsoft, we believe in the value of using our own products, a practice often referred to as "dogfooding". One would think, unfortunely that is not how it looks like in the zoo of native Windows desktop development, or Xamarin/MAUI adoption in their mobile apps.
It must be a new policy, or maybe only for this product (which makes good marketing). I've used Microsoft Graph to manage emails, and I'd be very surprised if they use if for Outlook...
Earlier quoted context omitted.
You can create your own emitters, there's info in the docs on how to do so. My team built a custom TypeSpec emitter to output a SDK and set of libraries
I wonder if they have plans to introduce any default emitters as part of the package? Nothing about that in the docs that I could find. [1] [1] https://typespec.io/docs/extending-typespec/emitters