Hacker News Reader

Comment by derefr | Hacker News Reader

Does anyone actually enjoy using these systems that encourage you to embed programming-language X code in programming-language Y heredocs?

I always find actually doing that — and then maintaining the results over time — to be quite painful: you don't get syntax highlighting inside the string; you can no longer search your worktree reliably using extension-based filtering; etc.

I personally find the workflow much more sane if/when you just have a separate file (e.g. `foo.zig`) for the guest-language code, and then your host-language code references it.

View on HN

I've done some assembly in C, and for big functions, yeah, I want it in its own file, but smaller things often make sense to embed. I'm not sure if I'd like my nif code embedded into my erl files (assuming this works for Erlang as well), but it could conceivably make the nasty bit of boilerplate around ERL_NIF_INIT in the NIF (which I have to do in C anyway) and exit(nif_library_not_loaded) in the erl go away, which would be nice.

It's certainly possible to get syntax highlighting on the embedded code, but you'll need to work with your syntax highlighter; it certainly helps if you're not the only person using it.

But then again, I worked without syntax highlighting for years, so I'm happy when it works, but when it doesn't, I'm ok with that too.

I’m not too familiar with Elixir, but I definitely prefer building libraries in Zig and then consuming them in Python, TS, whatever over embedding them inside another language directly.

That being said, you can get IDE language support for embedded code if you use eMacs or vim (and probably other editors as well). As I mentioned I still vastly prefer separating it personally, especially if you don’t necessarily expect your Python or Typescript programmers to be knowledgeable about Zig (or C).

Syntax highlighting here can work correctly, actually.

Also, I'm not sure why it's not better documented in Zigler, but you can also write the code in a separate file just fine.

Links for anyone curious.

> Syntax highlighting here can work correctly, actually.

Highlighting shown here in the 2021 ElixirConf talk posted elsewhere in the comments:

https://youtu.be/lDfjdGva3NE?t=2064

> I'm not sure why it's not better documented in Zigler

Here's the docs for it (though buried in the 'advanced' section)

https://hexdocs.pm/zigler/Zig.html#module-importing-external...

I initially agree

But, if all you do is write elixir wrappers around the zig function, to completely hide the foreign language functions, keeping both the wrapper and implementation in the same file, even if two different languages doesn't seem horrible, but again, keeping them in two file doesn't seem like a huge difference too

I think its really a matter of taste, both options viable

Actually literate programming might be a tool to get you syntax highlighting back. You could write one block of code in one language and the other one in another language and make one include the other in some place. Both blocks annotated to be their specific language, inside the prose. Emacs for example syntax highlights each block according to its corresponding programming language. It also allows you to edit blocks in separate buffers. Another way could be to switch the syntax highlighting of ones editor temporarily, but then syntax of the surrounding prose and other block might interfere.

> Does anyone actually enjoy using these systems that encourage you to embed programming-language X code in programming-language Y heredocs?

Isn’t that essentially any web application?

Reply on news.ycombinator.com