They have created yet another bespoke language for their one tool...
Even worse, they took CUE and created their own dialect while retaining the file extension. Their files are no longer valid CUE (if you use their "std" library and maybe some other things). Then they go on to say you're better off not knowing CUE, which I suspect will bite them in the arse.
I'd recommend thinking long and hard before considering this tool. Hope they pivot and I can re-evaluate them then, but they are off to a bad start.
The user-facing file is called "Acornfile", with no extension at all. We do not use .cue for anything a user would see. You're looking at files that are an internal implementation detail (and are valid CUE).
Having looked at the product more, I can see how people are getting confused. You expose CUE without saying it. As more people continue to adopt CUE, they will see the CUE in acornfiles. It's obvious to anyone familiar with the syntax.
There are several other issues with Acorn that seem to go the opposite way the market is going. I'll not relay them here because the other places we've conversed make it seem like you don't want any feedback critical of your product.
As I said the other two places you posted about this, we spent a lot of time testing starting with vanilla CUE and concluded less would be more. You disagree, that's fine.
Again if there's an Acornfile still called .cue somewhere, it's an oversight. You've pointed out an actual example now, so it's been removed.
The best way to approach criticism is with curiosity rather than defensiveness, especially when it is from the community around a technology you are building on. One does not simply remove the file extension to remove the association, users will see through it.
The packaging multiple images into one is unintuitive to me, especially when packaging a database with an app. What does this mean generally with image pulling and loading in kubernetes? Why is this a good idea for databases? Today we think of them as separate running entities. We have one database service, which multiple applications talk to today. How does Acorn work within / related to how we currently think about running services today. The docs leave one wanting and wondering.
https://kubevela.io/ is an alternative that has been around longer, exposes CUE naturally, and builds on open standards for app packs. I'd recommend this open-source product.
Agree. Yet another CUE based app platform that reminds me of KubeVela, while the later makes more sense in terms of overall experience:
1. For users, it's just a single pane of glass app definition, no CUE, no any other creepy language to learn.
2. For extenders/customizers, it's about standard CUE modules and tools, no CRD/controller stuff, just plain templating.
9 comments
[ 2.5 ms ] story [ 25.4 ms ] threadEven worse, they took CUE and created their own dialect while retaining the file extension. Their files are no longer valid CUE (if you use their "std" library and maybe some other things). Then they go on to say you're better off not knowing CUE, which I suspect will bite them in the arse.
I'd recommend thinking long and hard before considering this tool. Hope they pivot and I can re-evaluate them then, but they are off to a bad start.
Having looked at the product more, I can see how people are getting confused. You expose CUE without saying it. As more people continue to adopt CUE, they will see the CUE in acornfiles. It's obvious to anyone familiar with the syntax.
There are several other issues with Acorn that seem to go the opposite way the market is going. I'll not relay them here because the other places we've conversed make it seem like you don't want any feedback critical of your product.
Again if there's an Acornfile still called .cue somewhere, it's an oversight. You've pointed out an actual example now, so it's been removed.