[latchkey]

It is amazing to me that people call Java verbose when you have things like this to declare a simple variable:

  variable "service" {
    type = string
    description = "Name of the service"
  }

HCL isn't a bonus, it is a hinderance. If you're going to build something like this, you might as well just use TypeScript or Python as your backend language.

Beyond that, this just looks like yet another task executor... as you say, like make. At which point, you might as well just use a task executor. If make is not your liking, how about https://github.com/casey/just

[kunley]

I agree with you that HCL sucks when it comes to variables.

Other thing that is funny: no user-defined functions; being unable to use function calls in string interpolations, but allowing variables... so it is like saying: we have this parser and at some points it allows expressions, at some other point not. This seems wrong.

At the same time I agree with or at least understand original author's intent to squeeze HCL to maxinum. There is something appealing in HCL's visual form, at least when defining resources. Maybe it's just (almost) simplest form of defining such structures that can exists.

This is why I started to work on my own format for configuration, visually similar but with different model of computation.

Here is the first attempt: https://github.com/wkhere/bcl

Disclaimer: I named it BCL, 'B' stands for Basic, to somehow relate to HCL and make it easily pronounced. But later I discovered that another BCL is used as Google to configure the Borg platform and seems to be massively hated ;) So I look for a better name..

Project seems to be a bit stalled since few weeks, but that's illusory, as I have a rewrite with a non-yacc parser almost ready in the other branch. Then I will code parsing nested structures and at that point it will become really neat. Plus, an add of implementation in several other languages I usually code.

Please stay tuned if you like it.. or tell me what's wrong with it if you don't ;)

[srevinsaju]

One primary design goal togomak had from the beginning was concurrency. All tasks run concurrently, unless a `depends_on` argument is mentioned. `just` didn't support that when I was initially building togomak, but there is a feature coming in soon which I am looking forward to: https://github.com/casey/just/pull/1562 .

While I was building togomak, I read through Dagger [1], Earthly [2], Concourse CI [3], Jest and Make along with the stuff I was already working with - Jenkins, GitHub actions and GitLab CI. Dagger [1] is really great, I like its design - it supports writing pipelines in Python, Typescript, Go and a few more languages. togomak tries to abstract away a lot of it. Such as dependency management (in the case of python, the requirement of a python interpreter, and its package managers, etc). togomak is just a single statically-linked binary.

[1]: https://dagger.io/ [2]: https://earthly.dev/ [3]: https://concourse-ci.org/

[marcosnils]

Hey there! Dagger employee here. Congrats on the launch, it's grateful to see other people trying to collaborate on this space.

> Such as dependency management (in the case of python, the requirement of a python interpreter, and its package managers, etc). togomak is just a single statically-linked binary.

Not sure if you've been following the latest updates about Dagger, but since the latest 0.9 release we have a preview feature where all the SDK tooling runs within Dagger itself as a container so they're not required to be installed in the host machine anymore. We've also added support for Dagger Modules which allows you to package and distribute pipelines a-la terraform. Our docs are still not updated yet but if you join our Discord server, you can find all the information there.

Cheers!

[dpedu]

I think you're looking at this basic snippet and taking it for something it's not. Not shown in this example and considered best practice are:

- Defining and validating data structures passed in; type doesn't have to be a basic type, it can be complex objects

- Default value

- Input validation criteria

So, with a real world example this is still going to be less verbose than the java equivalents.

[latchkey]

Sorry, won't back down that HCL is junk. When it is easier to not do best practices in examples, then you're off on the wrong foot to begin with.

[dpedu]

I could point out how it's way, way easier in java programs, since we're picking on java, to skip over doing things like this. Or I could point out how the bar to do things correctly is lower in this hcl example than the equivalent java. Or I could point out how the things I named as best practices can look in the real world, which seems to be the best course of discussion since unfamiliarity seems to be an issue here:

You have a type defined, it's just string. There's no default, which means it's a required input. Required inputs obviously can't have a default. Arbitrary strings are a perfectly acceptable input and without seeing how that variable is actually used, I can't speculate about validation criteria and it is very reasonable that for arbitrary strings there are none.

[srevinsaju]

It's also interesting that this is also a valid variable definition which does the same thing, but without the bells and whistles:

  variable "name" {}