ਇਸ ਲੇਖ ਵਿੱਚ ਵੇਖੋ ਕਿ Zig ਕਿਉਂ ਲੋ-ਲੇਵਲ ਸਿਸਟਮ ਕੰਮ ਲਈ ਸਧਾਰਣ ਵਿਕਲਪ ਵਜੋਂ ਧਿਆਨ ਖਿੱਚ ਰਿਹਾ ਹੈ: ਬੋਝ-ਮੁਕਤ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ, ਪ੍ਰਯੋਗਕ ਟੂਲਿੰਗ, ਸ਼ਾਨਦਾਰ C ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ, ਅਤੇ ਆਸਾਨ ਕ੍ਰਾਸ-ਕੰਪਾਈਲਿੰਗ।

ਲੋ-ਲੇਵਲ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਹ ਕੰਮ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਕੋਡ ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਰਹਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਮੈਮੋਰੀ ਖੁਦ ਰੱਖਦੇ/ਰਿਹਾਂਦੇ ਹੋ, ਬਾਈਟਸ ਦੇ ਖਾਕੇ (layout) ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਅਤੇ ਅਕਸਰ OS, ਹਾਰਡਵੇਅਰ ਜਾਂ C ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਸਿੱਧਾ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹੋ। ਆਮ ਉਦਾਹਰਣਾਂ ਵਿੱਚ embedded firmware, device drivers, game engines, ਤੇ ਘੱਟ-ਲੈਟੈਂਸੀ ਵਾਲੇ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਸ਼ਾਮਿਲ ਹਨ।
“ਸਧਾਰਣ” ਦਾ ਮਤਲਬ “ਘੱਟ ਸਮਰੱਥਾ” ਜਾਂ “ਕਿਵੇਂ ਸਿੱਖਣ ਲਈ ਆਸਾਨ” ਹੀ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜੋ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ ਅਤੇ ਜੋ ਪ੍ਰੋਗ੍ਰਾਮ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਵਿਚਕਾਰ ਘੱਟ ਢੱਕੇ ਨਿਯਮ ਅਤੇ ਘੱਟ ਮੂਵਿੰਗ ਪਾਰਟਸ ਹੋਣ।
Zig ਨਾਲ, “ਸਧਾਰਣ ਵਿਕਲਪ” ਅਕਸਰ ਤਿੰਨ ਗੱਲਾਂ ਵੱਲ ਇشارة ਕਰਦਾ ਹੈ:
ਸਿਸਟਮ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਕਸਰ “ਅਕਸੀਡੈਂਟਲ ਕੰਪਲੈਕਸਿਟੀ” ਇਕੱਠੀ ਹੋ ਜਾਂਦੀ ਹੈ: ਬਿਲਡ ਨਾਜ਼ੁਕ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਲੇਟਫਾਰਮ ਫਰਕ ਵੱਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਡੀਬੱਗਿੰਗ ਕੁਝ ਪੁਰਾਤਨ ਖੋਜ ਵਾਂਗ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਟੂਲਚੇਨ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨ ਭਾਸ਼ਾ ਸਾਲਾਂ ਲਈ ਸਾਫਟਵੇਅਰ ਦੀ ਰਖ-ਰਖਾਵ ਘਟਾ ਸਕਦੀ ਹੈ।
Zig ਉਹਨਾਂ ਗ੍ਰੀਨਫੀਲਡ ਯੂਟਿਲਿਟੀਜ਼, ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਚੰਗਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੁੱਚੀ C ਇੰਟਰਓਪਰੇਬਿਲਟੀ ਜਾਂ ਭਰੋਸੇਯੋਗ ਕ੍ਰਾਸ-ਕੰਪਾਈਲਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇਹ ਹਰ ਵਾਰੀ ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਨਹੀਂ ਹੁੰਦਾ—ਆਪਣੇ ਟੀਮ ਕੋਲ ਜੇ Rust/C++ ਟੂਲਿੰਗ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਡੂੰਘਾ ਨਿਵੇਸ਼ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਵੱਡੀ ਖਪਤ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਏਕੋਸਿਸਟਮ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ Zig ਟਿਕਾਣਾ ਨਹੀਂ। Zig ਦੀ ਖੂਬੀ ਹੈ ਸਪਸ਼ਟਤਾ ਅਤੇ ਨਿਯੰਤਰਣ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਵੱਡੇ ਤੀਹ-ਚੱਕਰਾਂ ਦੇ।
Zig ਇੱਕ ਨਵੀਂ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਹੈ ਜੋ mid-2010s ਵਿੱਚ Andrew Kelley ਦੁਆਰਾ ਬਣਾਈ ਗਈ। ਇਸਦਾ ਪ੍ਰਯੋਗਕ ਲਕੜੀ ਮਕਸਦ ਹੈ: ਲੋ-ਲੇਵਲ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਧਾਰਣ ਅਤੇ ਸਿਧਾ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਨੁਕਸਾਨ ਨਾ ਹੋਵੇ। ਇਹ C-ਵਾਂਗ ਇੱਕ ਜਾਣ-ਪਛਾਣ ਵਾਲਾ ਅਨੁਭਵ ਲੈਂਦਾ ਹੈ (ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ, ਮੈਮੋਰੀ ਤੱਕ ਸਿੱਧਾ ਪਹੁੰਚ, ਅਨੁਕੂਲ ਡਾਟਾ ਲੇਆਊਟ), ਪਰ C ਅਤੇ C++ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੀ ਅਕਸੀਡੈਂਟਲ ਕੰਪਲੈਕਸਿਟੀ ਨੂੰ ਘਟਾਉਣ ਦਾ ਲਕੜੀ ਰੱਖਦਾ ਹੈ।
Zig ਦੀ ਡਿਜ਼ਾਈਨ explicitness ਅਤੇ predictability 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ। ਖਰਚਾਂ ਨੂੰ abstraction ਦੇ ਪਿੱਛੇ ਛੁਪਾਉਣ ਦੀ ਬਜਾਏ, Zig ਅਜਿਹਾ ਕੋਡ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ ਪੜ੍ਹ ਕੇ ਆਮ ਤੌਰ 'ਤੇ ਪਤਾ ਲਗ ਜਾਵੇ ਕਿ ਕੀ ਹੋਵੇਗਾ:
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ Zig ਸਿਰਫ ਲੋ-ਲੇਵਲ ਵਰਕ ਲਈ ਹੈ—ਇਹ ਕਹਿੰਦੀ ਹੈ ਕਿ ਲੋ-ਲੇਵਲ ਕੰਮ ਨੂੰ ਘੱਟ ਨਾਜ਼ੁਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਹੈ: ਇਰਾਦਾ ਸਪਸ਼ਟ,implicit conversions ਘੱਟ, ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਅਪਰਿਵਰਤਨਸ਼ੀਲ ਵਿਵਹਾਰ।
ਇਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਟੀਚਾ ਟੂਲਚੇਨ ਨੂੰ ਘੱਟ ਕਰਨਾ ਹੈ। Zig ਕੰਪਾਇਲਰ ਨੂੰ ਸਿਰਫ ਇਕ ਕੰਪਾਇਲਰ ਨਹੀਂ ਮੰਨਦਾ: ਇਹ ਇਕ ਇੰਟੀਗਰੇਟਡ ਬਿਲਡ ਸਿਸਟਮ ਅਤੇ ਟੈਸਟ ਸਹਾਇਤਾ ਵੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਨੂੰ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਵਜੋਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ clone ਕਰ ਕੇ ਘੱਟ ਬਾਹਰੀ ਜਰੂਰਤਾਂ ਨਾਲ ਬਿਲਡ ਕਰ ਸਕੋ।
Zig portability ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣਾਈ ਗਈ ਹੈ, ਜੋ ਕਿ ਇਸ ਇਕੱਲੇ-ਟੂਲ ਅਪ੍ਰੋਚ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮਿਲਦੀ ਹੈ: ਇੱਕੋ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਮਾਹੌਲਾਂ ਲਈ ਬਿਲਡ, ਟੈਸਟ ਅਤੇ ਟਾਰਗੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
Zig ਦੀ ਪੇਸ਼ਕਸ਼ "ਮੈਜਿਕ ਸੁਰੱਖਿਆ" ਜਾਂ "ਚਾਲਾਕ abstractions" ਨਹੀਂ ਹੈ। ਇਹ ਸਪਸ਼ਟਤਾ ਹੈ। ਭਾਸ਼ਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਕਿ ਕੋਰ ਵਿਚਾਰਾਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਰੱਖੇ, ਅਤੇ ਮਜਬੂਰ ਕਰਦੀ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਲਿਖੀਆਂ ਜਾਣ। ਟੀਮਾਂ ਲਈ ਜੋ C ਦਾ ਵਿਕਲਪ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਇਹ ਅਕਸਰ ਉਹਨਾਂ ਥਾਵਾਂ ਤੇ ਕੋਡ ਦਾ ਭਲੇ ਸਾਲਾਂ ਬਾਅਦ ਪੜ੍ਹਨਾ ਅਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਰਸਤੇਆਂ ਵਿੱਚ ਡੀਬੱਗਿੰਗ ਹੋਣ 'ਤੇ।
Zig ਵਿੱਚ ਤੁਸੀਂ ਘੱਟ ਆਸ਼ਚਰਜ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਰੱਖਦੇ ਹੋ ਕਿ ਕਿਸੇ ਲਾਈਨ ਕੋਡ ਨੇ ਪਿੱਛੇ ਕੀ ਕਰਵਾਇਆ। ਉਹ ਫੀਚਰ ਜਿਹੜੇ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਅਕਸਰ "ਅਦ੍ਰਿਸ਼" ਵਿਵਹਾਰ ਬਣਾਉਂਦੇ ਹਨ—implicit allocations, exceptions, ਜਾਂ ਗੁੰਝਲਦਾਰ conversion rules—ਉਹ ਇੱਥੇ ਸੀਮਤ ਹਨ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਪੜ੍ਹ ਕੇ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ:
Zig Exceptions ਨੂੰ ਟਾਲਦਾ ਹੈ ਅਤੇ ਬਦਲੇ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਮਾਡਲ ਵਰਤਦਾ ਹੈ। ਉੱਚ-ਸਤਰ 'ਤੇ, ਇੱਕ error union ਦਾ ਮਤਲਬ ਹੈ “ਇਹ ਓਪਰੇਸ਼ਨ ਜਾਂ ਤਾਂ ਇੱਕ ਮੁੱਲ ਦੇਵੇਗਾ ਜਾਂ ਇੱਕ ਐਰਰ।”
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ try ਵੇਖੋਗੇ ਜੋ error ਨੂੰ ਉਪਰ propagate ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ “ਜੇ ਇਹ ਫੇਲ ਹੋਇਆ ਤਾਂ ਰੋਕ ਕੇ error ਵਾਪਸ ਕਰੋ”), ਜਾਂ catch ਜੋ ਇੱਕ ਫੇਲ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ਤੇ ਹੱਲ ਕਰਦਾ ਹੈ। ਮੁੱਖ ਲਾਭ ਇਹ ਹੈ ਕਿ ਫੇਲ ਪੱਥ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ ਅਤੇ ਕੰਟਰੋਲ ਫਲੋ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਰਹਿੰਦਾ ਹੈ—ਇਹ ਲੋ-ਲੇਵਲ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਲਈ ਅਤੇ ਉਸ ਕਿਸੇ ਲਈ ਜੋ Zig ਤੇ Rust ਦੀ ਤੁਲਨਾ ਕਰ ਰਿਹਾ ਹੈ, ਮਦਦਗਾਰ ਹੈ।
Zig ਇੱਕ ਕਸਰ-ਭਰਿਆ ਫੀਚਰ ਸੈੱਟ ਲਿਆਉਂਦੀ ਹੈ ਜਿਸਦੇ ਨਿਯਮ ਲਗਾਤਾਰ ਹਨ। ਜਦੋਂ ਨਿਯਮਾਂ 'ਤੇ ਘੱਟ "exception" ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਘੱਟ ਐਜ-ਕੇਸ ਯਾਦ ਰੱਖਦੇ ਹੋ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਅਸਲ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਸਮੱਸਿਆ—ਸਹੀਪਨ, ਤੇਜ਼ੀ, ਅਤੇ ਸਪਸ਼ਟ ਇਰਾਦੇ—ਤੇ ਲਗਾ ਸਕਦੇ ਹੋ।
Zig ਇੱਕ ਸਾਫ਼ ਵਪਾਰ ਕਰਦੀ ਹੈ: ਤੁਹਾਨੂੰ ਪੂਰਵ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਿੱਧੇ ਮਾਨਸਿਕ ਮਾਡਲ ਮਿਲਦੇ ਹਨ, ਪਰ ਮੈਮੋਰੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰੀ ਤੁਹਾਡੇ ਉੱਤੇ ਹੈ। ਇੱਥੇ ਕੋਈ ਛੁਪਿਆ ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਨਹੀਂ ਹੈ ਜੋ ਪ੍ਰੋਗ੍ਰਾਮ ਰੋਕੇ, ਅਤੇ ਕੋਈ ਆਟੋਮੈਟਿਕ ਲਾਈਫਟਾਇਮ ਟਰੈਕਿੰਗ ਨਹੀਂ ਹੈ ਜੋ ਸ਼ਾਂਤਿ ਨਾਲ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲ ਦੇਵੇ। ਜੇ ਤੁਸੀਂ ਮੈਮੋਰੀ allocate ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਨਿਰਣੈ ਵੀ ਕਰੋਗੇ ਕਿ ਕਿਸne ਰੀਲੀਜ਼ ਕਰਨੀ ਹੈ, ਕਦੋਂ, ਅਤੇ ਕਿਸ ਹਾਲਤ 'ਚ।
Zig ਵਿੱਚ “ਮੈਨੁਅਲ” ਦਾ ਮਤਲਬ “ਗੰਦਾ” ਨਹੀਂ ਹੁੰਦਾ। ਭਾਸ਼ਾ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ, ਪੜ੍ਹਨਯੋਗ ਚੋਣਾਂ ਵੱਲ ਧਕਲਦੀ ਹੈ। ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਕਸਰ ਇੱਕ allocator ਦੇ ਤੌਰ ਤੇ argument ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਿ ਇਹ ਸਪਸ਼ਟ ਹੋਵੇ ਕਿ ਕੋਈ ਕੋਡ allocation ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹ ਕਿੰਨਾ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਵਿਜ਼ੀਬਿਲਟੀ ਦਾ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਾਲ-ਸਾਈਟ 'ਤੇ ਖਰਚੇ ਬਾਰੇ ਸੋਚ ਸਕੋ, profiling ਦੇ ਬਾਅਦ ਹੈਰਾਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ।
“ਹੀਪ” ਨੂੰ ਡਿਫਾਲਟ ਮੰਨਣ ਦੀ ਬਜਾਏ, Zig ਤੈਨੂੰ ਇਕ ਐਲੋਕੇਸ਼ਨ ਰਣਨੀਤੀ ਚੁਣਨ ਦੀ ਪ੍ਰੇਰਨਾ ਦਿੰਦੀ:
ਕਿਉਂਕਿ allocator ਇੱਕ ਪਹਿਲ-ਕਲਾਸ ਪੈਰਾਮੀਟਰ ਹੈ, ਰਣਨੀਤੀ ਬਦਲਣਾ ਅਕਸਰ ਇੱਕ ਰੀਫੈਕਟਰ ਹੈ, ਪੂਰਾ rewrite ਨਹੀਂ। ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ allocator ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਅਸਲੀ ਵਰਕਲੋਡ ਸਮਝ ਆਉਣ 'ਤੇ arena ਜਾਂ fixed buffer 'ਤੇ ਲਿਜਾ ਸਕਦੇ ਹੋ।
GC ਭਾਸ਼ਾਵਾਂ ਵਿਕਾਸਕਾਰ ਦੀ ਸੌਖਤਾ ਲਈ Optimaize ਕਰਦੀਆਂ ਹਨ: ਮੈਮੋਰੀ ਆਟੋਮੈਟਿਕ ਰਿਕਲੇਮ ਹੁੰਦੀ ਹੈ, ਪਰ ਲੈਟੈਂਸੀ ਅਤੇ ਪੀਕ ਮੈਮੋਰੀ ਦੀ ਭਵਿੱਖਬਾਣੀ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀ ਹੈ।
Rust compile-time safety ਲਈ optimize ਕਰਦਾ ਹੈ: ownership ਅਤੇ borrowing ਕਈ ਬੱਗਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ, ਪਰ ਇਹ ਧਾਰਣਾਤਮਕ ਝੰਝਟ ਵੀ ਜੋੜ ਸਕਦੇ ਹਨ।
Zig pragmatic ਮੱਧ-ਮੰਚ 'ਚ ਬੈਠਦਾ ਹੈ: ਘੱਟ ਨਿਯਮ, ਘੱਟ ਛੁਪਿਆ ਵਿਵਹਾਰ, ਅਤੇ allocation ਫੈਸਲਿਆਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਨ 'ਤੇ ਜ਼ੋਰ—ਤਾਂ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਅਗਾਅ ਹੈ।
ਇੱਕ ਕਾਰਨ ਜੋ Zig ਨੂੰ ਰੋਜ਼ਾਨਾ ਸਿਸਟਮ ਕੰਮ ਵਿੱਚ “ਸਧਾਰਣ” ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ, ਉਹ ਇਹ ਹੈ ਕਿ ਭਾਸ਼ਾ ਇੱਕ ਐਸਾ ਟੂਲ ਲੈ ਕੇ ਆਉਂਦੀ ਹੈ ਜੋ ਸਭ ਤੋਂ ਆਮ ਵਰਕਫਲੋ ਕਵਰ ਕਰਦਾ ਹੈ: ਬਿਲਡ ਕਰਨਾ, ਟੈਸਟ ਕਰਨਾ, ਅਤੇ ਹੋਰ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਟਾਰਗੇਟ ਕਰਨਾ। ਤੁਸੀਂ ਬਹੁਤ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹੋ ਜੋ ਕਿਸੇ ਬਿਲਡ ਟੂਲ, ਟੈਸਟ ਰਨਰ, ਅਤੇ ਕ੍ਰਾਸ-ਕੰਪਾਈਲਰ ਨੂੰ ਜੁੜਦਾ ਵੇਲੇ ਲੱਗਦਾ।
ਜਿਆਦਾਤਰ ਪ੍ਰੋਜੈਕਟ build.zig ਫਾਇਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਜੋ ਦੱਸਦੀ ਹੈ ਤੁਸੀਂ ਕੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ (executable, library, tests) ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਕੰਫਿਗਰ ਕਰਨਾ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਸਭ ਕੁਝ zig build ਰਾਹੀਂ ਚਲਾਉਂਦੇ ਹੋ, ਜੋ ਨਾਮਤ.steps ਦਿੰਦਾ ਹੈ।
ਆਮ ਕਮਾਂਡਾਂ ਉਦਾਹਰਣ ਵਰਗੀਆਂ ਲੱਗਦੀਆਂ ਹਨ:
zig build
zig build run
zig build test
ਇਹ ਮੁੱਖ ਲੂਪ ਹੈ: ਵਾਰੀ-ਵਾਰੀ ਕੰਮ ਇਕ ਵਾਰੀ ਪਰिभਾਸ਼ਤ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ Zig ਇੰਸਟਾਲਡ ਕਿਸੇ ਵੀ ਮਸ਼ੀਨ 'ਤੇ ਲਗਾਤਾਰ ਚਲਾਓ। ਛੋਟੇ ਯੂਟਿਲਿਟੀਜ਼ ਲਈ, ਤੁਸੀਂ ਬਿਨਾਂ build script ਦੇ ਵੀ ਸਿੱਧਾ ਕੰਪਾਈਲ ਕਰ ਸਕਦੇ ਹੋ:
zig build-exe src/main.zig
zig test src/main.zig
Zig ਵਿੱਚ cross-compilation ਨੂੰ ਵੱਖਰਾ "ਸੈਟਅੱਪ" ਨਹੀਂ ਸਮਝਿਆ ਜਾਂਦਾ। ਤੁਸੀਂ ਇੱਕ target ਅਤੇ (ਚਾਹੇ ਤਾਂ) optimization mode ਪਾਸ ਕਰਦੇ ਹੋ, ਅਤੇ Zig ਆਪਣੀ bundled tooling ਨਾਲ ਠੀਕ ਕਰਦਾ ਹੈ।
zig build -Dtarget=x86_64-windows-gnu
zig build -Dtarget=aarch64-linux-musl -Doptimize=ReleaseSmall
ਇਹ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ, embedded ਕੰਪੋਨੈਂਟ, ਜਾਂ ਵੱਖ-ਵੱਖ Linux distros 'ਤੇ ਚਲਾਉਂਦੀਆਂ ਸਰਵਿਸਿਜ਼ ਤਿਆਰ ਕਰਦੀਆਂ ਹਨ—ਕਿਉਂਕਿ Windows ਜਾਂ musl-linked ਬਿਲਡ ਬਣਾਉਣਾ ਤੁਹਾਡੇ ਲੋਕਲ ਡਿਵ ਸਬੰਧੀ ਬਿਲਡ ਵਰਗ ਹੀ ਰੋਟੀਨ ਹੋ ਸਕਦਾ ਹੈ।
Zig ਦੀ dependency ਕਹਾਣੀ build system ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ। Dependencies ਇੱਕ ਪ੍ਰੋਜੈਕਟ manifesto (ਅਕਸਰ build.zig.zon) ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਸਮੱਗਰੀ ਹੈਸ਼ਾਂ ਦੇ ਨਾਲ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੋ ਲੋਗ ਇੱਕੋ ਇੱਕ revision ਬਿਲਡ ਕਰਨ ਤੇ ਉਹੀ inputs ਫੈਚ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਸੁਰਤ ਨਤੀਜੇ ਮਿਲ ਸਕਦੇ ਹਨ, Zig artifacts cache ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਦੁਹਰਾਈ ਹੋਈ ਕੌਸ਼ਿਸ਼ ਘੱਟ ਹੋਵੇ।
ਇਹ "ਮੈਜਿਕ ਦੁਹਰਾਏਯੋਗਤਾ" ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਪਰੋਜੈਕਟਾਂ ਨੂੰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਦੁਹਰਾਏ ਯੋਗ ਬਿਲਡ ਵੱਲ ਧਕਲਦਾ ਹੈ—ਬਿਨਾਂ ਇਕ ਵੱਖਰੇ dependency manager ਨੂੰ ਅਪਣਾਉਣ ਦੇ।
Zig ਦਾ comptime ਇੱਕ ਸਧਾਰਣ ਵਿਚਾਰ ਹੈ ਜਿਸਦਾ ਵੱਡਾ ਫਾਇਦਾ ਹੈ: ਤੁਸੀਂ ਕੁਝ ਕੋਡ ਕੰਪਾਈਲੇਸ਼ਨ ਦੌਰਾਨ ਚਲਾ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਹੋਰ ਕੋਡ ਜਨਰੇਟ ਕੀਤਾ ਜਾ ਸਕੇ, ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕੇ, ਜਾਂ ਉਹ ਅਨੁਮਾਨਾਂ validate ਕੀਤੀਆਂ ਜਾ ਸਕਣ ਪਹਿਲਾਂ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮ ਸ਼ਿਪ ਹੋਵੇ। C/C++ preprocessor ਦੇ ਟੈਕਸਟ-ਅਧਾਰਿਤ ਬਦਲੇ, ਤੁਸੀਂ ਆਮ Zig ਸਿੰਟੈਕਸ ਅਤੇ ਆਮ Zig ਟਾਈਪਸ ਵਰਤ ਰਹੇ ਹੋ—ਸਿਰਫ਼ ਪਹਿਲਾਂ ਨਿਭਾਏ ਜਾਂਦੇ ਹੋ।
ਕੋਡ ਜਨਰੇਟ ਕਰੋ: compile-time ਜਾਣੇ ਜਾਣ ਵਾਲੇ ਇਨਪੁੱਟਸ (ਜਿਵੇਂ CPU ਫੀਚਰ, ਪ੍ਰੋਟੋਕੋਲ ਵਰਜਨ, ਜਾਂ ਫੀਲਡਸ ਦੀ ਲਿਸਟ) ਦੇ ਆਧਾਰ 'ਤੇ ਟਾਈਪਸ, ਫੰਕਸ਼ਨ ਜਾਂ ਲੁੱਕਅੱਪ ਟੇਬਲ ਬਣਾਓ।
ਕਨਫਿਗਾਂ ਵੈਲਿਡੇਟ ਕਰੋ: ਗਲਤ ਵਿਕਲਪਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਫੜ ਲਓ—ਜਿਸ ਨਾਲ "ਇਹ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ" ਦਾ ਮਤਲਬ ਅਸਲ ਵਿੱਚ ਹੋਵੈ।
C/C++ macros ਬਲਕ текста 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਆਸਾਨ ਹੁੰਦੀ ਹੈ। Zig comptime ਇਸਨੂੰ ਟਾਲਦਾ ਹੈ ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਭਾਸ਼ਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ: scope ਨਿਯਮ, ਟਾਈਪਸ, ਅਤੇ ਟੂਲਿੰਗ ਸਭ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
ਇਥੇ ਕੁੱਝ ਆਮ ਪੈਟਰਨ ਹਨ:
const std = @import(\"std\");
pub fn buildConfig(comptime port: u16, comptime enable_tls: bool) type {
if (port == 0) @compileError(\"port must be non-zero\");
if (enable_tls and port == 80) @compileError(\"TLS usually shouldn't run on port 80\");
return struct {
pub const Port = port;
pub const TlsEnabled = enable_tls;
};
}
ਇਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕ configuration "type" ਬਣਾਉਂਦੇ ਹੋ ਜੋ validated constants ਰੱਖਦਾ ਹੈ। ਜੇ ਕੋਈ ਗਲਤ value ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕੰਪਾਇਲਰ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਨਾਲ ਰੁਕ ਜਾਂਦਾ ਹੈ—ਕੋਈ runtime checks ਨਹੀਂ, ਕੋਈ ਛੁਪਿਆ macro logic ਨਹੀਂ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ।
Zig ਦੀ ਪੇਸ਼ਕਸ਼ "ਸڀ ਕੁਝ ਰੀਰਾਈਟ ਕਰੋ" ਨਹੀਂ ਹੈ। ਇਸਦੀ ਇੱਕ ਵੱਡੀ ਖੂਬੀ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਮੌਜੂਦਾ C ਕੋਡ ਨੂੰ ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ Zig ਵਿੱਚ ਇੱਕ-ਇਕ ਮਾਪਦੰਡਕਾਰਾਂ/ਫਾਇਲਾਂ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਕਿਸੇ ਬੜੇ ਬਣਾੜੇ ਮਾਈਗਰੇਸ਼ਨ ਦੇ।
Zig ਬਿਨਾਂ ਵੱਡੇ ceremony ਦੇ C ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ zlib, OpenSSL, SQLite ਜਾਂ platform SDKs ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਦੇ ਰਹਿ ਸਕਦੇ ਹੋ ਤੇ ਨਵੇਂ ਲੋਜਿਕ Zig ਵਿੱਚ ਲਿਖ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਰਿਸਕ ਘੱਟ ਰਹਿੰਦਾ ਹੈ: ਤੁਹਾਡੀਆਂ ਪਰਖੀ ਹੋਈਆਂ C ਡਿਪੈਂਡੈਂਸੀਜ਼ ਆਪਣੀ ਜਗ੍ਹਾ ਰਹਿੰਦੀਆਂ ਹਨ, ਜਦਕਿ ਨਵੇਂ ਹਿੱਸੇ Zig ਵਿੱਚ ਬਣਦੇ ਹਨ।
ਉਹੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ Zig ਉਹ ਫੰਕਸ਼ਨਾਂ export ਵੀ ਕਰ ਸਕਦਾ ਹੈ ਜੋ C ਕਾਲ ਕਰ ਸਕੇ। ਇਸ ਨਾਲ Zig ਨੂੰ ਮੌਜੂਦਾ C/C++ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਪ੍ਰੈਕਟਿਕਲ ਰਾਹ ਮਿਲਦੀ ਹੈ, ਬਦਲਿਆਂ ਵਜੋਂ ਪੂਰਾ ਰੀਰਾਈਟ ਨਾ ਕਰਨਾ ਪਵੇ।
ਹ<Data truncated for brevity>
ਇਸ ਸੰਦਰਭ ਵਿੱਚ “ਸਧਾਰਣ” ਦਾ ਮਤਲਬ ਹੈ ਜੋ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ ਅਤੇ ਜੋ ਕਾਰਜ ਹੋ ਰਿਹਾ ਹੈ, ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਘੱਟ ਛੁਪੇ ਨਿਯਮ। Zig ਇਹਨਾਂ ਹਿੱਸਿਆਂ ਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ:
ਇਹ ਪੇਸ਼ਕਸ਼ ਪ੍ਰਿਡਿਕਟਬਿਲਟੀ ਅਤੇ ਰਖ-ਰਖਾਵ ਲਈ ਹੈ, ਨਾ ਕਿ “ਘੱਟ ਸਮਰੱਥਾ” ਲਈ।
Zig ਅਕਸਰ ਉਹਨਾਂ ਪਰੋਜੈਕਟਾਂ ਲਈ ਉਚਿਤ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਸਖਤ ਨਿਯੰਤਰਣ, ਪ੍ਰੀਡਿਕਟਬਲ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਦੀ ਰਖ-ਰਖਾਵ ਚਾਹੀਦੀ ਹੈ:
Zig ਮੈਨੁਅਲ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਵਰਤਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਅਨੁਸ਼ਾਸਿਤ ਅਤੇ ਵਿਜ਼ੀਬਲ ਬਣਾਉਂਦਾ ਹੈ। ਆਮ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਜੋ ਕੰਮ ਐਲੋਕੇਟ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਇੱਕ allocator ਲੈਂਦਾ ਹੈ, ਤਾਂ ਕਿ ਕਾਲਰ ਸਮਝ ਸਕੇ ਇਹ ਕਿਤਨਾ ਖਰਚ ਕਰ ਸਕਦਾ ਹੈ।
ਪ੍ਰਾਥਮਿਕ ਨਤੀਜਾ: ਜੇ ਕੋਈ ਫੰਕਸ਼ਨ allocator ਲੈਂਦਾ ਹੈ, ਤ ਫੰਕਸ਼ਨ ਵਿੱਚ ਐਲੋਕੇਸ਼ਨ ਹੋ ਸਕਦੀ ਹੈ—ਇਸ ਲਈ ਮਾਲਕੀਅਤ ਅਤੇ ਫ੍ਰੀ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।
Zig ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ “allocator parameter” ਪੈਟਰਨ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਰੇਕ ਵਰਕਲੋਡ ਲਈ ਰਣਨੀਤੀ ਚੁਣ ਸਕੋ:
ਇਸ ਨਾਲ allocation ਰਣਨੀਤੀ ਬਦਲਣਾ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਰੀਫੈਕਟਰ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਿਕਵਰਾਈਟ।
Zig ਐਰਰਾਂ ਨੂੰ ਕਿਵੇਂ ਦੇਖਦਾ ਹੈ: ਐਰਰ ਯੂਨੀਅਨਜ਼ ਰਾਹੀਂ—ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇਕ ਅਪਰੇਸ਼ਨ ਜਾਂ ਤਾਂ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਾਂ ਇੱਕ error। ਦੋ ਆਮ ਓਪਰੇਟਰ ਹਨ:
try: ਜੇ error ਆਇਆ ਤਾਂ ਉਪਰਲੇ ਕੋਲ propagate ਕਰ ਦੇਵੇcatch: locally error ਸੰਭਾਲੋ (ਸ਼ਾਇਦ fallback ਨਾਲ)ਕਿਉਂਕਿ ਫੇਲ ਹੋਣਾ ਟਾਈਪ ਅਤੇ ਸਿੰਟੈਕਸ ਦਾ ਹਿੱਸਾ ਹੈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਪੜ੍ਹ ਕੇ ਸਾਰੇ ਫੇਲ ਪੱਥ ਵੇਖ ਸਕਦੇ ਹੋ।
Zig ਆਪਣੇ ਨਾਲ ਇੱਕ ਇਕੱਠੇ ਵਰਕਫਲੋ ਵਾਲਾ ਟੂਲ ਲਿਆਉਂਦਾ:
zig build — build.zig ਵਿੱਚ ਤੱਕੜੇ ਕਦਮ ਚਲਾਉਣ ਲਈzig build test ਜਾਂ zig test file.zig — ਟੈਸਟ ਚਲਾਉਣ ਲਈzig fmt — ਫਾਰਮੇਟਿੰਗ ਲਈਪ੍ਰਾਇਕਟਿਕਲ ਲਾਭ: ਘੱਟ ਬਾਹਰੀ ਟੂਲ ਇੰਸਟਾਲ ਕਰਨੇ, ਅਤੇ ਘੱਟ ਸਬ-ਾਜ਼ ਆਧਾਰਿਤ ਸਕ੍ਰਿਪਟਾਂ।
Cross-compiling ਰੋਜ਼ਮਰਾ ਰੀਤ ਹੈ: ਤੁਸੀਂ ਇਕ target ਪਾਸ ਕਰਦੇ ਹੋ ਅਤੇ Zig ਆਪਣੇ ਬੰਡਲ ਕੀਤੇ ਟੂਲ ਦੇ ਨਾਲ ਠੀਕ ਬਿਲਡ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਣ:
zig build -Dtarget=x86_64-windows-gnuzig build -Dtarget=aarch64-linux-muslਇਹ ਉਹਨਾਂ ਲਈ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਲਾਭਕਾਰੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ OS/CPU/libc ਜੋੜਿਆਂ ਲਈ ਦੁਹਰਾਏ ਯੋਗ ਬਿਲਡ ਚਾਹੀਦੇ ਹਨ ਬਿਨਾਂ ਵੱਖ-ਵੱਖ ਟੂਲਚੇਨਾਂ ਸੰਭਾਲਣ ਦੇ।
comptime ਤੁਹਾਨੂੰ ਕੁਝ ਕੋਡ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਚਲਾਉਣ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਹੋਰ ਕੋਡ ਜਨਰੇਟ ਕੀਤਾ ਜਾ ਸਕੇ, ਫੰਕਸ਼ਨ ਵਿਸ਼ੇਸ਼ਿਤ ਕੀਤੇ ਜਾ ਸਕਣ, ਜਾਂ ਬਾਇਨਰੀ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਧਾਰਨਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕੇ।
ਆਮ ਵਰਤੋਂ:
@compileError ਨਾਲ ਗਲਤ ਵਿਵਸਥਾਵਾਂ ਨੂੰ ਤੁਰੰਤ ਫੇਲ ਕਰਨਾਇਹ preprocessor-ਅੰਦਾਜ਼ ਹੈਕਸ ਦੀ ਬਜਾਏ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਾਰੇ ਆਮ Zig ਸਿੰਟੈਕਸ ਅਤੇ ਟਾਈਪਸ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ।
Zig C ਨਾਲ ਦੋ-ਤਰਫ਼ਾ ਤੌਰ 'ਤੇ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਕਰਦਾ ਹੈ:
@cImport ਨਾਲ headers ਇੰਪੋਰਟ ਕਰੋ ਤਾਂ ਕਿ binding ਅਸਲ headers ਤੋਂ ਆਵੇਇਸ ਨਾਲ ਇੰਕ੍ਰੀਮੈਂਟਲ ਅਪਣਾਉਣ ਸੌਖਾ ਬਣਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ-ਇਕ ਮੋਡੀਊਲ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਕੋਡਬੇਸ ਨੂੰ ਰੀਰਾਈਟ ਕੀਤੇ।
Zig ਹਰ ਹਾਲਤ ਲਈ ਨਹੀਂ ਹੈ। ਇਹ ਕਮਜ਼ੋਰ ਪਾਸੇ ਹਨ:
ਉਸ ਲਈ practical ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ Zig ਨੂੰ ਇੱਕ ਸੀਮਿਤ ਕੰਪੋਨੈਂਟ 'ਤੇ ਪਾਇਲਟ ਕਰੋ ਅਤੇ ਫਿਰ ਫੈਸਲਾ ਕਰੋ।