https://github.com/oracle/graal/tree/master/truffle

Disclaimer: graalvm dev here.

Edit: typo

I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble.

Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.

Let me tell about a revolutionary device called a Turbo encabulator.

One of the races in the books was the Anthropophagi (basically modeled on New Guinea headhunters). They talked like that.

[0] https://en.wikipedia.org/wiki/Dave_Duncan_(writer)

I just typed "supercali" in Google, and it autoexpanded it to the full word for me.

It even has a Wikipedia page.

https://en.m.wikipedia.org/wiki/Supercalifragilisticexpialid...

Here's an excerpt from the top of that page:

[ "Supercalifragilisticexpialidocious" (/ˌsuːpərˌkælɪˌfrædʒɪˌlɪstɪkˌɛkspiˌælɪˈdoʊʃəs/ ⓘ SOO-per-KAL-ih-FRA-jih-LIS-tik-EKS-pee-AL-i-DOH-shəs) is a song and single from the 1964 Disney musical film Mary Poppins. It was written by the Sherman Brothers, and sung by Julie Andrews and Dick Van Dyke.[1] It also appears in the 2004 stage show version. Because Mary Poppins was a period piece set in 1910, songs that sounded similar to songs of the period were wanted.[2] The movie version finished at #36 in AFI's 100 Years...100 Songs survey of top tunes in American cinema. ]

You're showing your ignorance of anything more than a few decades old (and for many of you, of a word and famous song that is from your own country), your prejudices, and your hive mind. "yeah, bro, only wutz neeeew izzzz kewl!"

Someone could have asked what I meant instead of stupidly downvoting, but better behaviour is not expected on HN, of course.

No wonder Amy Hoy wrote somewhere, "Fuck HN".

I bet if we google, we'll find many similar quotes and reactions by others, like Amy's.

Not to imply that all of HN is shit. There's tons of good stuff on it, though less lately.

It's just the mentality of some of these people that I am talking about, that is shit.

And I know about the guideline that you are not supposed to complain about downvoting, but I don't care about it. That's my right, not to care about it. And it is not complaining, because I don't care about votes or points. I am just expressing my opinion of what I think is the blind, thoughtless, fly-by downvoting.

Now, downvote away, make my karma go below zero (add that HN feature if it doesnt exist), send me a cease and desist notice :), hellban me, shadowban me (such pretentious terms, as if HN is so important as to merit such terms), delete my account, whatever. Who cares?

Maybe it is time for a new and possibly better thing than HN. (Notice that I didn't say a better HN; who needs more of the same?)

Like Mastodon versus Twitter or whatever, or quite different.

Startup opportunity? ;)

If you get this upset you don't have to post on this site. Or you can learn to be not as reactive to social media.

Maybe you should read more carefully before replying.

I already said above that I was not complaining.

As for my comment (the supercali... word) not adding to the discussion, you are wrong again. The comment was in the same spirit as my parent and grandparent comments, who used words like cromulent, embiggen and perfectumentous.

>And you need to flex your age because of it?

Wrong again. Nothing in my comment shows that I was "flexing my age", as you call it.

>If you get this upset you don't have to post on this site.

Oh, I don't mind posting. I am having fun. I don't let comments like the one that I replied to, spoil my fun.

>Or you can learn to be not as reactive to social media.

Er, the term is "social" media, not "lone wolf baying at the moon" media.

It indicates people reacting (by replying) to other people, which could include approvingly, neutrally or critically, just like in real life, you know.

But there is something in what you say. This "comments about comments about comments about ..." scenario is getting boring and tedious.

From now on, I'll let the blind downvoters be blind downvoters and keep doing their thing. As I said earlier, HN points are not at all important, to me, at least.

Even now the OG comment says “Fuamura” but the quote in the GP comment has the original “Futurama” written in it.

[0] https://news.ycombinator.com/item?id=39239965

https://news.ycombinator.com/item?id=13752964

https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

Especially the Futamura projections. It's almost magic and very few people have even heard of them.

I once saw a demo where someone took a simple operation in Ruby using inefficient-but-elegant syntax (including creating and sorting an array, where a simple loop would have been the appropriate approach in C). He compiled that using TruffleRuby and the entire array construction and sorting was completely optimized out of the generated bytecode.

Here is one of the many: https://youtu.be/bf5pQVgux3c?si=S8Dm5d_GXYXgJtnY

If you go looking for more you will find many more marbles.

And the (original, I think), Pokémon or Tech Term: https://docs.google.com/forms/d/e/1FAIpQLSfsG7AEFLvlW68aIVIs...

not Futurama :D

I think that too, "Futamura projections" are important but they are very very far from "complex mathematical machinery" as you may hear it. They are indeed very simple (even mathematically trivial) and require no special background to understand.

What now?

Cue chase montage shenanigans with Under The Boardwalk playing in the background

Do you smell toast.

thanks, that will help improve the output.

GraalVM is an alternate JDK that can, among other things, do ahead-of-time compilation for Java.

Truffle is a framework for building languages, that sits on top of Graal.

Futamura Projections are a particularly interesting use case for compile-time partial evaluation.

With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) arguments.

When “your function” is an interpreter, and your static arguments are source code, the output is effectively a self-contained compiled binary.

When your function is an interpreter, and the static arguments are the source code for the interpreter itself, that “self-contained compiled binary” is now itself a compiler.

I really like Pkl's comparison page, which includes its weak points as well! https://pkl-lang.org/main/current/introduction/comparison.ht...

Pkl’s native binaries are larger than those of other config languages.

It should be as fast and easy to use and reliable as something like esbuild, so I'd suggest they may want to rewrite it in Go like esbuild. I'm not a Go fan at all, but it clearly does some things really well.

The Gradle compatibility matrix is pretty complicated: https://docs.gradle.org/current/userguide/compatibility.html...

I’ve also used Facebook’s Buck build system, as an attempt to get away from Gradle, and it’s also fussy about JDK versions.

You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.

> t should be as fast and easy to use and

How did you conclude that it's not fast? They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.

Of course, but what surprises me is the lack of backwards compatibility -- future JVMs refusing the run old code. I get that you have to deprecate old unsafe APIs sometimes, but it feels silly that I need three different Java versions for different Android projects.

They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.

That's good! I thought you needed Java to run it.

I figured I should give it a proper try, so I just downloaded it. 105MB!! They're not kidding when they say it's big. I also checked bun (47.7MB) and esbuild (9.8MB) for comparison.

pkl does seem to start up pretty fast, though. 1.6s on the first run (presumably just the time needed to cache that big binary) and ~100ms thereafter.

I'd actually say that our tooling in some ways is more mature. For example, I think our IDE experience (at least in JetBrains editors) is the best out there.

Apple employees can rate it as an old project among themselves, while it is more convenient for everyone else to rate the product from the moment of publication.

It seems like they did not aim to make yet another mvp configuration language, but something that can scale across a wide range of usage scenarios spanning all the way from short-lived processes reading a number from a file to huge libraries of default/override hierarchies. Lack of universality sets an upper bound for the value of a configuration language, particularly when seen through the lens of configuring heterogeneous tech stacks.

wtf is Graal? That sounds like a supporting character from Beowulf.

Polyglot and native compilation enabled runtime for JVM, can run Js, Python, Ruby and more.

That's pretty clever... How is this implemented in actual code though? I can't even begin to imagine how that magic machinery works.

Sadly they renamed Kyber to MLKEM.

https://pq-crystals.org/

I ask cause the Project Galahad page on openjdk.org is a bit sparse on details.

Some background on the recent changes there: https://medium.com/graalvm/truffle-unchained-13887b77b62c

[1]: https://cuelang.org/docs/concepts/logic/

In other words antlr and truffle are a great fit. We even use this pairing for our example language simplelanguage.

https://github.com/graalvm/simplelanguage

Of course, I know those two frameworks are one of the engineering marble of the age and would understand even if they decided to go without any concrete needs for it.

Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point.

I just don't understand why you'd make that decision on a greenfield project today, especially if LSP support is planned at all?

(Pkl, not Apple :p)

What bout Pkl made it easier to write Terraform/K8s manifests/etc.?

Are there any reasonable examples of such?

I wish Apple would continue to open source much more. Especially old software much like Microsoft does. I would kind of enjoy a Linux Distro that can natively run old Apple software and tools.

That's not a complete list of programs Apple has open-sourced, although clearly open-source software isn't what they're best known for. But clang alone is a worthy contribution which deserves to be recognized.

How about if the LSP doesn't cut it for the kind of they IDE support they want to offer?

https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...

Like 'go to definition' or whatever is surely in every IDEs menu, but it can be done with LSP.

"We are also releasing two other plugins: our VS Code plugin, and our neovim plugin. Today, these plugins only provide basic editing features like syntax highlighting and code folding."

Given that writing anything in Java/Kotlin basically requires the use of IntelliJ, it’s not really surprising that a language built on top of Truffle and GraalVM, all Java technologies, would ship with an IntelliJ plugin, _but not_ an LSP. Because such an LSP would have been useless in the primary IDE used by the language developers.

So if you wanna blame anyone, blame JetBrains for deliberately making hard to use LSPs with their IDE. Presumably to build a moat around their plugin ecosystem.

[0] https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...

[0] https://cuelang.org

I'm assuming it's becaus CUE is still unstable?

Anyway, if others are interested in CUE's LSP work, I think https://github.com/cue-lang/cue/issues/142 is the issue to subscribe to

It has always been clear that LSP was high priority, but we have many other high priority work that also needs to be done. Most of the work that we do is driven by feedback and demand from the community.

Additionally, we want to do the LSP right instead of quickly hacking something together. That requires more work than one might think.

While CUE has not reached 1.0 yet, people definitely use CUE in production and we work hard not to break any of their code. I can assure you LSP is missing simply because we had other things to tackle first and not because the language is unstable in a colloquial sense.

For it to gain more adoption it really needs a rewrite in a low-level language (C/Rust), so it can be exposed in various languages through an extension/FFI.

Getting feedback from the community about what other languages they'd want supported first would be of massive help, however.

Rust and Python would be my top picks.

For those who want the justifications for CUE, this is an excellent write up.

[1] How CUE Wins:

https://blog.cedriccharly.com/post/20210523-how-cue-wins/

However it only being in Go and not implemented with some C ABI is a major downside for adoption, especially when their documentation itself for implementing the core CLI functionality in a go program (to then compile to a DLL for use in non-Go land) is pretty sparse.

One thing I like to see is the direction of “declare types and validations in a single place, integrate with any language”.

My daily codebase atm has types declarations in typescript, cue, pydantic and for our database… and it’s driving me bonkers seeing as most types are already declared in Cue to start with. I played a little with packages meant to translate them i.e. Cue -> TS, but nothing worth the effort.

IMO it would be a big upside for Cue to handle these as first class language features.

1. You are limited to N evaluation/reduction steps.

2. The language doesn't include primitives like recursion or loops.

3. You can have recursion or loops, but the language makes you somehow prove that your program will terminate.

I think (1) would be fine, but I don't know any configuration languages that use this approach.

(2) is restrictive/annoying whenever you want to implement any logic in the config language library. Eg. a tool uses a homegrown data format BAML and you need to convert JSON to BAML in the config. Now either you have to write and manually call a preprocessor, or you need to use a patched version of the <config language evaluator> that will have JSON->BAML as a built-in, or you must implement JSON->BAML without loops or recursion. For a more realistic example, imagine that a certain config string has to be HTML-escaped and the config language doesn't provide a built-in for that purpose.

(3) -- you don't want it. There are languages (like Agda) that let you prove things like "this program terminates", but writing those proofs can be harder than writing the program itself.

Recursion is trickier. I think banning it or simply limiting stack depth seems fairly reasonable? In fact I’m pretty sure most Turing-complete languages have a stack depth limit, so unbounded recursion is not allowed for those either. I don’t see a limit being a problem, because again this is a config language.

I don’t see why HTML escaping needs Turing-completeness. It shouldn’t need any unbounded iteration (it should be limited to the size of the input string) or unbounded loops. In general, I can’t think of any typical data processing code where turning completeness is required, but could be wrong. Do you have any practical examples of transformations that need unbounded iteration?

First of all, let's avoid "Turing-completeness" because then we might start arguing about whether a language with unrestricted recursion is or isn't Turing-complete since there are stack depth limits / memory limits / universe will end one day / etc.

I would phrase this question as "why would HTML escaping need unrestricted recursion or loops" -- since in practice config languages either have unrestricted recursion or loops (Nickel), or they don't (CUE, Dhall, Starlark).

For HTML escaping specifically, just having `.map(f)` and `.concat` available (in functional languages), or `for char in string` (in imperative languages), would be enough.

For something like HTML un-escaping, it's already trickier. If you are using recursion, your language needs to understand the concept of the string becoming "smaller" at each step. If you are using loops, `for ... in ...` is not enough anymore.

An even trickier example would be mergesort:

  merge(xs, ys) = ...

  mergeSort(xs) =
    let len   = xs.length
        left  = mergeSort(xs.slice(0, len/2))
        right = mergeSort(xs.slice(len/2, len))
    in merge(left, right)

(Not to mention that this implementation is faulty and will loop at len=1.)

Limiting stack depth at [arbitrary number] -- this is similar to (1). I don't know why configuration languages don't do it, to be honest.

2a. The language includes limited primitives for recursion or loops.

If that’s done right, somehow proving that your program will terminate becomes trivial.

For example, allowing looping over a previously defined array with (key,value1) pairs to generate many more complex definitions that include common value2, value3, etc fields trivially guarantees termination, but a generic “while” loop doesn’t.

That will make you language less powerful, but IMO shouldn’t be problem for a configuration language.

In this example, I’m not sure you would even need that, as the language has ways to share common config values.

Limited recursion/iteration is ok if all you need is to fill existing values into a template and possibly reduce repetition.

But in a large system with many components I might want to take a single timestamp, parse it, and generate timestamps in five different formats for five different subcomponents.

Or I might want to generate a piece of yaml config for an Ansible playbook that needs it, and now my config language needs to know how to escape yaml strings.

Or a config for a static site generator needs to be able to calculate a hash of a local css file because I’d like to use links like `style.css?hash` (a popular cache-defeating mechanism).

Or a certain path has to be split on “.” and reversed (Java-style com.example.blah things).

Or a Unix path needs to be converted to a Windows path, except [some special-cased paths that live in a map in an adjacent config].

There are endless reasons to want arbitrary logic in my config files, beyond reducing repetition. A lot of things I’ve listed are provided as primitives in various config/templating languages, but you always end up stumbling upon something that’s not provided.

Of course, one could say “You should use a real programming language for this kind of stuff”, and I’m happy that the JavaScript ecosystem is converging on allowing .js/.ts files for configs, because that’s exactly what I want too. But I’d like to have the same features available in projects that aren’t allowed to touch JS.

Cue is not general purpose language, with emphasis on it - because it's a good thing.

Asking for upstream embedded support feels like asking for bash interpreter, why would you need it in the first place?

It's based on completely different, logic based paradigms, use it as it is meant to be used - as top level configuration aiding language. Declare policies and generation in it and interface with other languages/tooling though input/output json/yml.

1. The only way to use it is to run their Go CLI app to convert the Cue into JSON and then load that. That sucks. I want native support. Jsonnet does this a lot better (https://jsonnet.org/ref/bindings.html), and PKL at least supports 4 languages. Cue only supports Go directly. Not good.

2. Cue has a super fancy type system, but as far as I could figure out there's no way to actually take advantage of this in an IDE, which is like 60% of the benefits of fancy type systems. In a Cue document you can't say "this is the schema". XML had that decades ago (and it has awesome IDE integration with Red Hat's XML extension for VSCode). Even JSON can sort of do it via `$schema`. The docs are a bit scant but it looks like this supports it too. The fact that Cue doesn't sucks.

3. Cue is pretty much only a fancy type system. It's a really elegant and nice type system, but that's it. It doesn't even have functions. So it isn't going to help with a lot of the things that Jsonnet and PKL help with.

This is not really in the same area as Cue. It's a way more direct competitor to Jsonnet and looks better, based on my brief skim.

My only concern with these sorts of things is that they're basically a whole new programming language, but without many of the features you'd want from a real programming language. It's in an uncanny valley.

Does look nice though.

I've fallen back to YAML because at least its already used for a lot of tools, and has comments, jsonschema support in VSCode giving IDE features, language library support, yamllint, and yq for formatting/querying/mass-updating from the CLI

* JSON. No comments. Deal-breaker

* JSONC. No unique file extension so its difficult to distinguish from JSON. Poor library support due to library authors drinking the "comments are bad" koolaid.

* JSON5. This would be an excellent option IMO except that library and IDE support is not great.

* JSON6. This just complicates JSON5 for minimal benefits. Pointless.

* Cue. As described.

* Jsonnet. Pretty good option tbh! However I couldn't get the Rust library to work. It's a low level parser, seems like you can't just plug it into Serde, which is what 99% of people really want. Also I ran into the "uncanny valley" effect where you can do some things but not all. So it tricks you into writing some programmatic config (e.g. with string manipulation) but then you find you can't do that string manipulation.

* Dhall. Weird syntax (backslash to declare functions. I've also heard it is slow. Didn't try this too much.

* YAML. Obviously YAML is the worst option. However I did realise you can use it as basically JSON5 except with a different comment character, which is not too bad.

* Starlark. Actually I haven't tried this yet but it looks promising.

So yeah I have no idea at the moment.

I wonder if it would be worth defining a "YAML JSON5" format, that's basically YAML-compatible JSON5.

Note that CUE has comprehensions, which are morally (but not syntactically) functions (actually closures). They are a way to transform values (which can be types) into other values.

We are also adding real function types to CUE. At least in the beginning these functions will be written in other languages than CUE itself, however.

While we are very principled when it comes to language design, we are also very responsive to finding solutions to user's problems, and we welcome any sort of feedback, especially if it's backed by specific use cases and experiences.

As mentioned in another comment, support for languages other than Go is coming.

This use of the word is so common in certain math/category theory/compsci communities that I was not aware it was unconventional in any way. It has nothing to do with ethics.

I guess the moral of the story is that the moral of the story can be lost if people don't understand the story.

[1] https://eugeniacheng.com/wp-content/uploads/2017/02/cheng-mo...

I really don’t know why this snark is necessary.

Consider that some engineers poured a lot of heart into what they were building, and are probably excited to finally share it with the world.

I am not saying you have to love it, but just brutally putting it down with no justification seems really rough. Snark is easy.

OTOH, curious to see what advantages Pkl gains from not having the constraints of maintaining familiarity with another language.

> The implementations below are not fully compliant to the specification yet. We aim to remove the differences and provide a common test suite.

This does not inspire confidence that I could use this in a project any time soon.

Meanwhile, from what I can tell Pkl has a single Truffle implementation that currently supports 4 languages, it has a syntax that is more familiar to me as a non-Python dev, it has static typing, and it has a dedicated plugin in most IDEs (whereas Starlark just says to install the Bazel plugin). Maybe Starlark is more appealing to people writing Python or already using Bazel, but for the rest of us there's no contest right now.

https://github.com/bazelbuild/starlark/blob/master/users.md

[0] https://github.com/google/copybara

> Copybara doesn't have a release process yet, so you need to compile from HEAD.

Looks like there's an Arch Linux build maintained by... somebody, but if you're not on Arch then you're going to be building Copybara with Bazel. That this works for them suggests to me that their community has a significant amount of overlap with the Bazel community, so it's not good evidence of Starlark being used outside of the Bazel world.

Lots of projects developed at Google use Starlark. Copybara is one of them. That's where the connection comes from.

Many other companies are also adopting Starlark for their own needs. For example, Meta has invested a lot in Starlark and published their implementation (https://developers.facebook.com/blog/post/2021/04/08/rust-st...), although they don't use Bazel at all.

Starlark was first created for Bazel. The organic user growth comes from people who have seen and used the language, so often Bazel users. But it doesn't have to be.

https://github.com/bazelbuild/starlark

I do like the sound of that. It's always quite tedious to manage configuration in full-stack applications with mixed languages/ecosystems. It seems they already have Pkl plugins for IntelliJ, vscode and neovim and a language server is "coming soon".

http://dhall-lang.org/

This is most useful when dealing with tools like k8s where deploying a single application might involve 3-10 separate manifests (Deployment, Service, NetworkPolicy, HttpRoute, Autoscaler etc etc). With Pkl you can easily write a simple template that only requests the minimum needed to define an “app” (e.g. name, namespace, mixins for sidecars) and have Pkl generate all the needed manifests for you.

Really Pkl should be seen as a language for quickly building templating tools like Helm. But with type safety by default, and no need for horrible indent hacks.

    city = {
        "id": 3,
        "name": "Foo",
        "lat": 3.555,
        "long": 4.11,
    }

    city = {
        "id": "3",
        "name": "Foo",
        "coordinates": [3.555, 4.11]
    }

Something like Cuelang will:

- Define the schema that will let you know what you should put inside.

- Allow you to inflate that schema into a full file, providing only the values.

- Will generate always a correct file, with no typo, or format error.

- Will check that the data is correct and tell you if there are any errors.

- Is note theoretically tied to a particular run time or stack.

https://json-schema.org

I'll be looking into cue, but how does it solve that problem ?

Similar to why do we write Python instead of assembly, or why do relational databases typically have things like datatypes and constraints?

- the validation system

- ability to split large configuration files into smaller files and enhance readability (I know Java / Spring Boot apps already have this ability using profiles)

- multiple language support

Wonder if it’s possible to have more complicated validation functions. The example given validates 1 configuration (“port must be greater than 1000”). But there are times when some configuration is valid by itself however in the presence of other configuration the configuration(s) will possibly be ignored.

Given:

- configA

- configB supersedes configA in app

When:

- both configA and configB set in pkl

Then:

- at compile time, should throw a validation error

Criticisms:

- documentation (in typical Apple fashion) appears to be lacking. Couldn’t find anything on the validation system

- missing LSP support

- yet another config language to support/learn

If you say

a: 5

a: 3

That’s an error.

If you want the ability to "override", you have to write it like this, for example:

a: *5 | int

a: 3

This also works for struct/list members, so you can set defaults for all fields, and stuff like that.

https://cuelang.org/docs/about/

- mature libs for most languages

- VScode plugin + Jsonschema for auto completion / schema checking

- yamllint to detect the languages footguns

- yq to query, update in place, and format while preserving comments and sorting keys from the CLI

another common thing is that sometimes you have to define multiple very similar sections in configuration that cannot be handled with yaml archors, eg I have repeated definition dozen times that changes only in 2 numbers that are deeply in structure and name string, and I need to repeat everything because of that and it's pita to modify all other parameters that need to be kept in sync

therefore I think this format looks really nice, although I'm concerned by loops that can be used there, is there possible to create simple config that takes ages to parse or consume very large amounts of memory?

And there doesn't seem to be any online playground to test

local `My Variable` = 42

Do you happen to have a link to the missing/blank reference page on this?

EDIT: perhaps I misunderstood the question - if it's about whether you can use non-ASCII characters in identifiers without quoting, the answer is "sometimes":

``` local `abde` = 42 // Only works when quoted

local `teʝ` = 42 // Works fine (as expected)

local teʝ2 = 42. // Also works fine ```

It might be interesting to expand the docs to cover the precise rules here without having to resort to ANTLR grammar, as you say.

For example, does

x² = 42 work? Or

move↓?=true

or some emoji

I guess not given your first example (though it's not rendered here properly, looks like 4 ascii letters), which is rather unfortunate as configs could be more readable with symbolic names,

https://pkl-lang.org/main/current/language-reference/index.h..., both links are broken. Another thing is that the doc page should have an additional pages with a single section/page view otherwise it's too hard to find a word in a single huge doc

Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head.

(Mumble, grumble, something about s-expressions...)

But it’s still better than templating yaml.

Worth noting that it is specifically CPython that has been called impossible to sandbox. (2014 discussion: https://news.ycombinator.com/item?id=8280053.) It may be possible to sandbox PyPy. PyPy has a sandboxing feature its website calls a "working prototype" (https://www.pypy.org/features.html#sandboxing). If someone invested in it—potentially a huge effort—it could plausibly become good enough for configuration. But, IMO, Starlark is a better choice here because it was designed for isolation from the start. If you wanted to invest in Python-as-config-for-Python, a good use of your time might be improving Starlark for Python.

For in-house stuff, totally agree, just use the python code itself as the configuration.

Though, even if they weren’t going to provide a server OS, it seems like they could still offer IDE support for the droves of web devs working on Macs a deploying to Linux (like I assume their devs do).

Can I write a loop in this? If? Elvis operator? A simple map lookup?

https://pkl-lang.org/main/current/language-reference/index.h...

> If?

https://pkl-lang.org/main/current/language-reference/index.h...

> Elvis operator?

https://pkl-lang.org/main/current/language-reference/index.h...

> A simple map lookup?

https://pkl-lang.org/main/current/language-reference/index.h...

i.e. you can write code statements and it transpiles down to other formats

Then there is need to generate that new configuration file as things getting complicated.

The current approach (of all these current languages, pkl looks like is the same) is to painfully refactor the ones you want to change to a parameter file, i.e. a manual data/code separation and you template that.

It would be nice just say this configuration file is now a template file with A B C fields as parameters, and load it up in our new configuration file for templating with good trackability and performance.

It is also easy to migrate to other languages, as configuration now can turn into code cheaply.

Apple has done nothing cross platform or open source or community oriented so if they come out with something that's intended to be more general is has no base, no users, no audience of non-Apple developers to land on.

I'm not anti Apple - I love MacOS and Apple is my main machine. I'm just pragmatic about Apple technologies - they are all for usage inside the Apple bubble.

Cups - https://en.wikipedia.org/wiki/CUPS

Swift - https://en.wikipedia.org/wiki/Swift_(programming_language)

Zeroconf - https://en.wikipedia.org/wiki/Bonjour_(software)

I think they're bad, opaque opensource maintainers, but they did release some popular things that have communities on other systems.

I do wish they just contributed to nickel or something else though rather than doing their NIH as usual.

Swift is a language entirely in the control of Apple, mainly targeting Apples platforms. With little to no community engagement.

Bonjour is not really cross platform, and not really open source either as it has lots of strings attached to the license and terms one can use it under.

(I wouldn't say that Apple has done "nothing" -- but to credit them for doing much is also a stretch)

And I think CSS animations and transforms mostly came out of Apple; at any rate, they're very similar to the animations and transforms in UIKit that originally came from NeXT.

Entire timeline of JavaScript engines.

https://egbert.net/blog/articles/javascript-jit-engines-time...

or:

I didn't include Firefox because it's just an NCSA Mosaic fork, not theirs.

The point being, whoever does most of the work and maintenance owns something, not who came up with some early predecessor.

They’re contributing to a ton of OSS that’s NIH:

https://opensource.apple.com/projects/

K8s, spark, cassandra, netty, zookeeper, solr, containerd

Did Nickel exist in 2018? (Someone here said that Pkl did.)

(is there an xkcd for that?)

https://cdn.statcdn.com/Infographic/images/normal/1438.jpeg

you can click it, it'll open link in your browser where you can read what it refers to.