5 ms·

Any code you compile can now execute arbitrary syscalls, shell out to git, interact with the user's terminal, host a web service or whatever else as you build i

by bhawks 6y ago

Any code you compile can now execute arbitrary syscalls, shell out to git, interact with the user's terminal, host a web service or whatever else as you build it and then write the results to your final executable code? While most ecosystems are moving to hermetic, reproducible builds this is going full steam on the other direction. Goodbye 'it works on my machine' hello 'it works on Jane's machine when Ryan builds it on Tuesdays. Oh Ryan WFH on Tuesday so it gets built on his home machine!' I wanted to like this but it seems to have gone way too far. It is a college project gone wild.

Reelin 6y ago
If you do any codegen can't all of that already happen though? Many (most?) build systems can already execute more or less arbitrary logic. Reproducible builds are only guaranteed if you actually verify the signature of the output. There's also runtime reflection in most dynamic languages, and don't forget self modifying code! No technical restriction can prevent people from writing bad code at the end of the day because bad code is really a social issue.
- bhawks 6y ago
  The difference is that code generating build actions are necessarily and explicitly called out in build systems - with the opportunity to observe their declared dependencies and sandbox their execution. In circle compiling any cxx file executes arbitrary code and emits different results. There's no way to reason about what will happen during the build without manual inspection and that really doesn't scale past trivial projects. I'd imagine most static analysis and ide tools would be significantly hindered understanding circle code. It is concerning that one of the first dozen examples of the language show how the compiler can request input from the terminal mid-compilation. Amazingly powerful feature put forward without any commentary about how / when it should be used or not used - let alone if it should exist at all. As I said it feels like a college experiment - it doesn't feel like they asked how these features would make it easier to write clear, understandable, maintainable code - they just implemented them.
  - ekelsen 6y ago
    I think reading through all the examples https://github.com/seanbaxter/circle/blob/master/examples/README.md#abstract https://github.com/seanbaxter/circle/blob/master/examples/RE... makes it clear that the author has put quite a deal of thought into how these features make it easier to write clear, understandable and maintainable code. Even the example you point to goes to say: "Let's use the integrated interpreter to define a useful build tool. Software is the subject of constant revisions, and it's useful to mark a distributable with the exact version of the source-control archive it was built with." It's clear (to me) that the developer is not advocating using terminal input in the middle of a build. I haven't used terminal input since I was a child; I don't think the developer expects anyone to take that as a serious example.
adev_ 6y ago
> code you compile can now execute arbitrary syscalls, shell out to git, interact with the user's terminal, host a web service or whatever else as you build it and then write the results to your final executable code? There is no way you can get 100% reproducible builds without using an isolated sandbox with 'modern build tools' anyway (npm, cargo, pip, etc etc). They love to depend on hidden files in your home directory or download some random staff in your back. This will be no different.

by bhawks 6y ago

Reelin 6y ago

If you do any codegen can't all of that already happen though? Many (most?) build systems can already execute more or less arbitrary logic. Reproducible builds are only guaranteed if you actually verify the signature of the output. There's also runtime reflection in most dynamic languages, and don't forget self modifying code! No technical restriction can prevent people from writing bad code at the end of the day because bad code is really a social issue.

bhawks 6y ago
The difference is that code generating build actions are necessarily and explicitly called out in build systems - with the opportunity to observe their declared dependencies and sandbox their execution. In circle compiling any cxx file executes arbitrary code and emits different results. There's no way to reason about what will happen during the build without manual inspection and that really doesn't scale past trivial projects. I'd imagine most static analysis and ide tools would be significantly hindered understanding circle code. It is concerning that one of the first dozen examples of the language show how the compiler can request input from the terminal mid-compilation. Amazingly powerful feature put forward without any commentary about how / when it should be used or not used - let alone if it should exist at all. As I said it feels like a college experiment - it doesn't feel like they asked how these features would make it easier to write clear, understandable, maintainable code - they just implemented them.
- ekelsen 6y ago
  I think reading through all the examples https://github.com/seanbaxter/circle/blob/master/examples/README.md#abstract https://github.com/seanbaxter/circle/blob/master/examples/RE... makes it clear that the author has put quite a deal of thought into how these features make it easier to write clear, understandable and maintainable code. Even the example you point to goes to say: "Let's use the integrated interpreter to define a useful build tool. Software is the subject of constant revisions, and it's useful to mark a distributable with the exact version of the source-control archive it was built with." It's clear (to me) that the developer is not advocating using terminal input in the middle of a build. I haven't used terminal input since I was a child; I don't think the developer expects anyone to take that as a serious example.

adev_ 6y ago

> code you compile can now execute arbitrary syscalls, shell out to git, interact with the user's terminal, host a web service or whatever else as you build it and then write the results to your final executable code? There is no way you can get 100% reproducible builds without using an isolated sandbox with 'modern build tools' anyway (npm, cargo, pip, etc etc). They love to depend on hidden files in your home directory or download some random staff in your back. This will be no different.