ਕਿਉਂ Zig ਇੱਕ ਸਧਾਰਣ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਚੋਣ ਵਜੋਂ ਉਭਰ ਰਿਹਾ ਹੈ

“ਸਧਾਰਣ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ—ਅਤੇ ਇਹ ਮਾਮਲਾ ਕਿਉਂ ਬਣਦਾ ਹੈ

ਲੋ-ਲੇਵਲ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਹ ਕੰਮ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਕੋਡ ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਰਹਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਮੈਮੋਰੀ ਖੁਦ ਰੱਖਦੇ/ਰਿਹਾਂਦੇ ਹੋ, ਬਾਈਟਸ ਦੇ ਖਾਕੇ (layout) ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਅਤੇ ਅਕਸਰ OS, ਹਾਰਡਵੇਅਰ ਜਾਂ C ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਸਿੱਧਾ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹੋ। ਆਮ ਉਦਾਹਰਣਾਂ ਵਿੱਚ embedded firmware, device drivers, game engines, ਤੇ ਘੱਟ-ਲੈਟੈਂਸੀ ਵਾਲੇ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਸ਼ਾਮਿਲ ਹਨ।

ਇੱਥੇ “ਸਧਾਰਣ” ਦਾ ਅਸਲ ਮਤਲਬ

“ਸਧਾਰਣ” ਦਾ ਮਤਲਬ “ਘੱਟ ਸਮਰੱਥਾ” ਜਾਂ “ਕਿਵੇਂ ਸਿੱਖਣ ਲਈ ਆਸਾਨ” ਹੀ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜੋ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ ਅਤੇ ਜੋ ਪ੍ਰੋਗ੍ਰਾਮ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਵਿਚਕਾਰ ਘੱਟ ਢੱਕੇ ਨਿਯਮ ਅਤੇ ਘੱਟ ਮੂਵਿੰਗ ਪਾਰਟਸ ਹੋਣ।

Zig ਨਾਲ, “ਸਧਾਰਣ ਵਿਕਲਪ” ਅਕਸਰ ਤਿੰਨ ਗੱਲਾਂ ਵੱਲ ਇشارة ਕਰਦਾ ਹੈ:

• ਸਿੰਟੈਕਸ ਅਤੇ ਭਾਸ਼ਾਈ ਧਾਰਣਾਵਾਂ: ਘੱਟ ਫੀਚਰ ਸੈੱਟ ਸਿੱਖਣ ਲਈ, ਅਤੇ ਕੋਡ ਨੂੰ ਉਹੀ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਣ ਤੇ ਜੋ ਉਹ ਕਰਦਾ ਹੈ।
• ਟੂਲਿੰਗ ਅਤੇ ਵਰਕਫਲੋ: ਇੱਕ ਇਕੱਲਾ ਟੂਲ ਜੋ ਬਿਲਡ, ਟੇਸਟ, ਫਾਰਮੈਟ ਅਤੇ ਕ੍ਰਾਸ-ਕੰਪਾਈਲਿੰਗ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਬਿਨਾਂ ਬਾਹਰੀ ਟੂਲਾਂ ਦੀ ਲੰਬੀ ਲੜੀ ਬਣਾਏ।
• ਮਾਨਸਿਕ ਮਾਡਲ: ਜ਼ਿਆਦਾ ਸਪੱਸ਼ਟ ਫੈਸਲੇ (ਖਾਸ ਕਰਕੇ ਮੈਮੋਰੀ ਅਤੇ ਐਰਰਾਂ ਨੂੰ ਲੈ ਕੇ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਮਪਾਇਲਰ, ਰਨਟਾਈਮ ਜਾਂ ਬਿਲਡ ਸਿਸਟਮ ਨੇ ਕੀ ਕੀਤਾ, ਇਸ ਦੀ ਅਣਧੁੰਧ ਤਜਵੀਜ਼ ਨਾ ਕਰੋ।

ਇਹ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ (ਚਾਹੇ ਤੁਸੀਂ ਭਾਸ਼ਾ ਵਿਸ਼ੇਸ਼ਗਿਆਨ ਨਾ ਹੋ)

ਸਿਸਟਮ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਕਸਰ “ਅਕਸੀਡੈਂਟਲ ਕੰਪਲੈਕਸਿਟੀ” ਇਕੱਠੀ ਹੋ ਜਾਂਦੀ ਹੈ: ਬਿਲਡ ਨਾਜ਼ੁਕ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਲੇਟਫਾਰਮ ਫਰਕ ਵੱਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਡੀਬੱਗਿੰਗ ਕੁਝ ਪੁਰਾਤਨ ਖੋਜ ਵਾਂਗ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਟੂਲਚੇਨ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨ ਭਾਸ਼ਾ ਸਾਲਾਂ ਲਈ ਸਾਫਟਵੇਅਰ ਦੀ ਰਖ-ਰਖਾਵ ਘਟਾ ਸਕਦੀ ਹੈ।

Zig ਅੱਜ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ

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

ਇਹ ਹਰ ਵਾਰੀ ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਨਹੀਂ ਹੁੰਦਾ—ਆਪਣੇ ਟੀਮ ਕੋਲ ਜੇ Rust/C++ ਟੂਲਿੰਗ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਡੂੰਘਾ ਨਿਵੇਸ਼ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਵੱਡੀ ਖਪਤ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਏਕੋਸਿਸਟਮ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ Zig ਟਿਕਾਣਾ ਨਹੀਂ। Zig ਦੀ ਖੂਬੀ ਹੈ ਸਪਸ਼ਟਤਾ ਅਤੇ ਨਿਯੰਤਰਣ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਵੱਡੇ ਤੀਹ-ਚੱਕਰਾਂ ਦੇ।

Zig ਅਤੇ ਇਸਦੇ ਡਿਜ਼ਾਈਨ ਲਕੜੀਆਂ ਦਾ ਸੰਖੇਪ

Zig ਇੱਕ ਨਵੀਂ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਹੈ ਜੋ mid-2010s ਵਿੱਚ Andrew Kelley ਦੁਆਰਾ ਬਣਾਈ ਗਈ। ਇਸਦਾ ਪ੍ਰਯੋਗਕ ਲਕੜੀ ਮਕਸਦ ਹੈ: ਲੋ-ਲੇਵਲ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਧਾਰਣ ਅਤੇ ਸਿਧਾ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਨੁਕਸਾਨ ਨਾ ਹੋਵੇ। ਇਹ C-ਵਾਂਗ ਇੱਕ ਜਾਣ-ਪਛਾਣ ਵਾਲਾ ਅਨੁਭਵ ਲੈਂਦਾ ਹੈ (ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ, ਮੈਮੋਰੀ ਤੱਕ ਸਿੱਧਾ ਪਹੁੰਚ, ਅਨੁਕੂਲ ਡਾਟਾ ਲੇਆਊਟ), ਪਰ C ਅਤੇ C++ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੀ ਅਕਸੀਡੈਂਟਲ ਕੰਪਲੈਕਸਿਟੀ ਨੂੰ ਘਟਾਉਣ ਦਾ ਲਕੜੀ ਰੱਖਦਾ ਹੈ।

ਮੁੱਖ ਵਿਚਾਰ: ਘੱਟ ਹੈਰਾਨੀਆਂ

Zig ਦੀ ਡਿਜ਼ਾਈਨ explicitness ਅਤੇ predictability 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ। ਖਰਚਾਂ ਨੂੰ abstraction ਦੇ ਪਿੱਛੇ ਛੁਪਾਉਣ ਦੀ ਬਜਾਏ, Zig ਅਜਿਹਾ ਕੋਡ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ ਪੜ੍ਹ ਕੇ ਆਮ ਤੌਰ 'ਤੇ ਪਤਾ ਲਗ ਜਾਵੇ ਕਿ ਕੀ ਹੋਵੇਗਾ:

• ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਕੋਈ ਛੁਪਿਆ ਹੋਇਆ ਮੈਮੋਰੀ ਐਲੋਕੇਸ਼ਨ ਨਹੀਂ।
• ਐਰਰਾਂ ਮੂਲਿਆਂ ਵਾਂਗ ਹਨ ਜੋ ਤੁਸੀਂ ਸਿੱਧਾ ਹੱਲ ਕਰਦੇ ਹੋ, Exceptions ਨਹੀਂ।
• ਭਾਸ਼ਾ "ਮੈਜਿਕ" ਨੂੰ ਘੱਟ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਜੋ ਵਿਵਹਾਰ ਸੋਚਣਯੋਗ ਬਣੇ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ Zig ਸਿਰਫ ਲੋ-ਲੇਵਲ ਵਰਕ ਲਈ ਹੈ—ਇਹ ਕਹਿੰਦੀ ਹੈ ਕਿ ਲੋ-ਲੇਵਲ ਕੰਮ ਨੂੰ ਘੱਟ ਨਾਜ਼ੁਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਹੈ: ਇਰਾਦਾ ਸਪਸ਼ਟ,implicit conversions ਘੱਟ, ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਅਪਰਿਵਰਤਨਸ਼ੀਲ ਵਿਵਹਾਰ।

"ਇੱਕ-ਟੂਲ" ਵਰਕਫਲੋ

ਇਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਟੀਚਾ ਟੂਲਚੇਨ ਨੂੰ ਘੱਟ ਕਰਨਾ ਹੈ। Zig ਕੰਪਾਇਲਰ ਨੂੰ ਸਿਰਫ ਇਕ ਕੰਪਾਇਲਰ ਨਹੀਂ ਮੰਨਦਾ: ਇਹ ਇਕ ਇੰਟੀਗਰੇਟਡ ਬਿਲਡ ਸਿਸਟਮ ਅਤੇ ਟੈਸਟ ਸਹਾਇਤਾ ਵੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਨੂੰ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਵਜੋਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ clone ਕਰ ਕੇ ਘੱਟ ਬਾਹਰੀ ਜਰੂਰਤਾਂ ਨਾਲ ਬਿਲਡ ਕਰ ਸਕੋ।

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

ਭਾਸ਼ਾ ਦੀ ਸਾਦਗੀ: ਘੱਟ ਧਾਰਣਾਵਾਂ, ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਕੋਡ

Zig ਦੀ ਪੇਸ਼ਕਸ਼ "ਮੈਜਿਕ ਸੁਰੱਖਿਆ" ਜਾਂ "ਚਾਲਾਕ abstractions" ਨਹੀਂ ਹੈ। ਇਹ ਸਪਸ਼ਟਤਾ ਹੈ। ਭਾਸ਼ਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਕਿ ਕੋਰ ਵਿਚਾਰਾਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਰੱਖੇ, ਅਤੇ ਮਜਬੂਰ ਕਰਦੀ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਲਿਖੀਆਂ ਜਾਣ। ਟੀਮਾਂ ਲਈ ਜੋ C ਦਾ ਵਿਕਲਪ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਇਹ ਅਕਸਰ ਉਹਨਾਂ ਥਾਵਾਂ ਤੇ ਕੋਡ ਦਾ ਭਲੇ ਸਾਲਾਂ ਬਾਅਦ ਪੜ੍ਹਨਾ ਅਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਰਸਤੇਆਂ ਵਿੱਚ ਡੀਬੱਗਿੰਗ ਹੋਣ 'ਤੇ।

ਕੋਈ ਛੁਪਿਆ ਹੋਇਆ ਕੰਟਰੋਲ ਫਲੋ ਨਹੀਂ

Zig ਵਿੱਚ ਤੁਸੀਂ ਘੱਟ ਆਸ਼ਚਰਜ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਰੱਖਦੇ ਹੋ ਕਿ ਕਿਸੇ ਲਾਈਨ ਕੋਡ ਨੇ ਪਿੱਛੇ ਕੀ ਕਰਵਾਇਆ। ਉਹ ਫੀਚਰ ਜਿਹੜੇ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਅਕਸਰ "ਅਦ੍ਰਿਸ਼" ਵਿਵਹਾਰ ਬਣਾਉਂਦੇ ਹਨ—implicit allocations, exceptions, ਜਾਂ ਗੁੰਝਲਦਾਰ conversion rules—ਉਹ ਇੱਥੇ ਸੀਮਤ ਹਨ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਪੜ੍ਹ ਕੇ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ:

• ਇਹ ਫੰਕਸ਼ਨ ਕਿੱਥੇ early exit ਕਰ ਸਕਦਾ ਹੈ?
• ਇੱਥੇ ਕੀ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ?
• ਕੀ ਡਾਟਾ ਬਣਾਇਆ ਜਾਂ ਮੂਵ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ?

ਐਰਰ ਯੂਨੀਅਨਜ਼: ਪੜ੍ਹਨਯੋਗ ਫੇਲ ਹੈਂਡਲਿੰਗ

Zig Exceptions ਨੂੰ ਟਾਲਦਾ ਹੈ ਅਤੇ ਬਦਲੇ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਮਾਡਲ ਵਰਤਦਾ ਹੈ। ਉੱਚ-ਸਤਰ 'ਤੇ, ਇੱਕ error union ਦਾ ਮਤਲਬ ਹੈ “ਇਹ ਓਪਰੇਸ਼ਨ ਜਾਂ ਤਾਂ ਇੱਕ ਮੁੱਲ ਦੇਵੇਗਾ ਜਾਂ ਇੱਕ ਐਰਰ।”

ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ try ਵੇਖੋਗੇ ਜੋ error ਨੂੰ ਉਪਰ propagate ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ “ਜੇ ਇਹ ਫੇਲ ਹੋਇਆ ਤਾਂ ਰੋਕ ਕੇ error ਵਾਪਸ ਕਰੋ”), ਜਾਂ catch ਜੋ ਇੱਕ ਫੇਲ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ਤੇ ਹੱਲ ਕਰਦਾ ਹੈ। ਮੁੱਖ ਲਾਭ ਇਹ ਹੈ ਕਿ ਫੇਲ ਪੱਥ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ ਅਤੇ ਕੰਟਰੋਲ ਫਲੋ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਰਹਿੰਦਾ ਹੈ—ਇਹ ਲੋ-ਲੇਵਲ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਲਈ ਅਤੇ ਉਸ ਕਿਸੇ ਲਈ ਜੋ Zig ਤੇ Rust ਦੀ ਤੁਲਨਾ ਕਰ ਰਿਹਾ ਹੈ, ਮਦਦਗਾਰ ਹੈ।

ਇਕ ਛੋਟਾ ਕੋਰ, ਘੱਟ ਖਾਸ ਕੇਸ

Zig ਇੱਕ ਕਸਰ-ਭਰਿਆ ਫੀਚਰ ਸੈੱਟ ਲਿਆਉਂਦੀ ਹੈ ਜਿਸਦੇ ਨਿਯਮ ਲਗਾਤਾਰ ਹਨ। ਜਦੋਂ ਨਿਯਮਾਂ 'ਤੇ ਘੱਟ "exception" ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਘੱਟ ਐਜ-ਕੇਸ ਯਾਦ ਰੱਖਦੇ ਹੋ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਅਸਲ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਸਮੱਸਿਆ—ਸਹੀਪਨ, ਤੇਜ਼ੀ, ਅਤੇ ਸਪਸ਼ਟ ਇਰਾਦੇ—ਤੇ ਲਗਾ ਸਕਦੇ ਹੋ।

ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ: ਸਪਸ਼ਟ ਨਿਯੰਤਰਣ ਬਿਨਾਂ ਅਚਾਨਕ ਲਾਗਤਾਂ ਦੇ

Zig ਇੱਕ ਸਾਫ਼ ਵਪਾਰ ਕਰਦੀ ਹੈ: ਤੁਹਾਨੂੰ ਪੂਰਵ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਿੱਧੇ ਮਾਨਸਿਕ ਮਾਡਲ ਮਿਲਦੇ ਹਨ, ਪਰ ਮੈਮੋਰੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰੀ ਤੁਹਾਡੇ ਉੱਤੇ ਹੈ। ਇੱਥੇ ਕੋਈ ਛੁਪਿਆ ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਨਹੀਂ ਹੈ ਜੋ ਪ੍ਰੋਗ੍ਰਾਮ ਰੋਕੇ, ਅਤੇ ਕੋਈ ਆਟੋਮੈਟਿਕ ਲਾਈਫਟਾਇਮ ਟਰੈਕਿੰਗ ਨਹੀਂ ਹੈ ਜੋ ਸ਼ਾਂਤਿ ਨਾਲ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲ ਦੇਵੇ। ਜੇ ਤੁਸੀਂ ਮੈਮੋਰੀ allocate ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਨਿਰਣੈ ਵੀ ਕਰੋਗੇ ਕਿ ਕਿਸne ਰੀਲੀਜ਼ ਕਰਨੀ ਹੈ, ਕਦੋਂ, ਅਤੇ ਕਿਸ ਹਾਲਤ 'ਚ।

ਇਰਾਦਾਪੂਰਵਕ ਮੈਨੁਅਲ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ

Zig ਵਿੱਚ “ਮੈਨੁਅਲ” ਦਾ ਮਤਲਬ “ਗੰਦਾ” ਨਹੀਂ ਹੁੰਦਾ। ਭਾਸ਼ਾ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ, ਪੜ੍ਹਨਯੋਗ ਚੋਣਾਂ ਵੱਲ ਧਕਲਦੀ ਹੈ। ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਕਸਰ ਇੱਕ allocator ਦੇ ਤੌਰ ਤੇ argument ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਿ ਇਹ ਸਪਸ਼ਟ ਹੋਵੇ ਕਿ ਕੋਈ ਕੋਡ allocation ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹ ਕਿੰਨਾ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਵਿਜ਼ੀਬਿਲਟੀ ਦਾ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਾਲ-ਸਾਈਟ 'ਤੇ ਖਰਚੇ ਬਾਰੇ ਸੋਚ ਸਕੋ, profiling ਦੇ ਬਾਅਦ ਹੈਰਾਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ।

allocator ਪੈਟਰਨ: ਮੈਮੋਰੀ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ, ਇਹ ਚੁਣੋ

“ਹੀਪ” ਨੂੰ ਡਿਫਾਲਟ ਮੰਨਣ ਦੀ ਬਜਾਏ, Zig ਤੈਨੂੰ ਇਕ ਐਲੋਕੇਸ਼ਨ ਰਣਨੀਤੀ ਚੁਣਨ ਦੀ ਪ੍ਰੇਰਨਾ ਦਿੰਦੀ:

• General-purpose heap allocators: ਲੰਬੇ ਜੀਵਨ ਵਾਲੀਆਂ ਅਤੇ ਲਚਕੀਲੀਆਂ allocations ਲਈ
• Arena allocators: “ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ allocate ਕਰੋ ਅਤੇ ਇਕੱਠੇ free ਕਰੋ” ਵਰਕਲੋਡਾਂ ਲਈ (parsing, request handling)
• Fixed buffers: ਜਦੋਂ ਤੁਸੀਂ ਸਖ਼ਤ ਸੀମਾਵਾਂ ਅਤੇ ਜ਼ੀਰੋ ਰਨਟਾਈਮ ਐਲੋਕੇਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ

ਕਿਉਂਕਿ allocator ਇੱਕ ਪਹਿਲ-ਕਲਾਸ ਪੈਰਾਮੀਟਰ ਹੈ, ਰਣਨੀਤੀ ਬਦਲਣਾ ਅਕਸਰ ਇੱਕ ਰੀਫੈਕਟਰ ਹੈ, ਪੂਰਾ rewrite ਨਹੀਂ। ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ allocator ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਅਸਲੀ ਵਰਕਲੋਡ ਸਮਝ ਆਉਣ 'ਤੇ arena ਜਾਂ fixed buffer 'ਤੇ ਲਿਜਾ ਸਕਦੇ ਹੋ।

GC ਭਾਸ਼ਾਵਾਂ ਅਤੇ Rust ਨਾਲ ਤੁਲਨਾ

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 ਨੂੰ ਅਪਣਾਉਣ ਦੇ।

Comptime: ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਰ ਬਿਨਾਂ ਪ੍ਰਯੋਗਕ ਮੈਟਾਫਰੋਗ੍ਰੈਮਿੰਗ

Zig ਦਾ comptime ਇੱਕ ਸਧਾਰਣ ਵਿਚਾਰ ਹੈ ਜਿਸਦਾ ਵੱਡਾ ਫਾਇਦਾ ਹੈ: ਤੁਸੀਂ ਕੁਝ ਕੋਡ ਕੰਪਾਈਲੇਸ਼ਨ ਦੌਰਾਨ ਚਲਾ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਹੋਰ ਕੋਡ ਜਨਰੇਟ ਕੀਤਾ ਜਾ ਸਕੇ, ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕੇ, ਜਾਂ ਉਹ ਅਨੁਮਾਨਾਂ validate ਕੀਤੀਆਂ ਜਾ ਸਕਣ ਪਹਿਲਾਂ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮ ਸ਼ਿਪ ਹੋਵੇ। C/C++ preprocessor ਦੇ ਟੈਕਸਟ-ਅਧਾਰਿਤ ਬਦਲੇ, ਤੁਸੀਂ ਆਮ Zig ਸਿੰਟੈਕਸ ਅਤੇ ਆਮ Zig ਟਾਈਪਸ ਵਰਤ ਰਹੇ ਹੋ—ਸਿਰਫ਼ ਪਹਿਲਾਂ ਨਿਭਾਏ ਜਾਂਦੇ ਹੋ।

comptime ਨਾਲ ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ (ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ)

ਕੋਡ ਜਨਰੇਟ ਕਰੋ: compile-time ਜਾਣੇ ਜਾਣ ਵਾਲੇ ਇਨਪੁੱਟਸ (ਜਿਵੇਂ CPU ਫੀਚਰ, ਪ੍ਰੋਟੋਕੋਲ ਵਰਜਨ, ਜਾਂ ਫੀਲਡਸ ਦੀ ਲਿਸਟ) ਦੇ ਆਧਾਰ 'ਤੇ ਟਾਈਪਸ, ਫੰਕਸ਼ਨ ਜਾਂ ਲੁੱਕਅੱਪ ਟੇਬਲ ਬਣਾਓ।

ਕਨਫਿਗਾਂ ਵੈਲਿਡੇਟ ਕਰੋ: ਗਲਤ ਵਿਕਲਪਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਫੜ ਲਓ—ਜਿਸ ਨਾਲ "ਇਹ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ" ਦਾ ਮਤਲਬ ਅਸਲ ਵਿੱਚ ਹੋਵੈ।

ਕਿਉਂ ਇਹ preprocessor-ਸਟਾਈਲ ਹੈਕਸ ਨੂੰ ਬਦਲਦਾ ਹੈ

C/C++ macros ਬਲਕ текста 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਆਸਾਨ ਹੁੰਦੀ ਹੈ। Zig comptime ਇਸਨੂੰ ਟਾਲਦਾ ਹੈ ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਭਾਸ਼ਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ: scope ਨਿਯਮ, ਟਾਈਪਸ, ਅਤੇ ਟੂਲਿੰਗ ਸਭ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

ਸੁਰੱਖਿਅਤ compile-time ਚੈੱਕ ਦੇ ਉਦਾਹਰਣ

ਇਥੇ ਕੁੱਝ ਆਮ ਪੈਟਰਨ ਹਨ:

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 ਨਹੀਂ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ।

C ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ: ਹਕੀਕਤੀ ਇਨਕ੍ਰੀਮੈਂਟਲ ਮਾਈਗਰੇਸ਼ਨ ਰਾਹ

Zig ਦੀ ਪੇਸ਼ਕਸ਼ "ਸڀ ਕੁਝ ਰੀਰਾਈਟ ਕਰੋ" ਨਹੀਂ ਹੈ। ਇਸਦੀ ਇੱਕ ਵੱਡੀ ਖੂਬੀ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਮੌਜੂਦਾ C ਕੋਡ ਨੂੰ ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ Zig ਵਿੱਚ ਇੱਕ-ਇਕ ਮਾਪਦੰਡਕਾਰਾਂ/ਫਾਇਲਾਂ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਕਿਸੇ ਬੜੇ ਬਣਾੜੇ ਮਾਈਗਰੇਸ਼ਨ ਦੇ।

C ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰੋ (ਅਤੇ ਮੌਜੂਦਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਰਤ ਜਾਰੀ ਰੱਖੋ)

Zig ਬਿਨਾਂ ਵੱਡੇ ceremony ਦੇ C ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ zlib, OpenSSL, SQLite ਜਾਂ platform SDKs ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਦੇ ਰਹਿ ਸਕਦੇ ਹੋ ਤੇ ਨਵੇਂ ਲੋਜਿਕ Zig ਵਿੱਚ ਲਿਖ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਰਿਸਕ ਘੱਟ ਰਹਿੰਦਾ ਹੈ: ਤੁਹਾਡੀਆਂ ਪਰਖੀ ਹੋਈਆਂ C ਡਿਪੈਂਡੈਂਸੀਜ਼ ਆਪਣੀ ਜਗ੍ਹਾ ਰਹਿੰਦੀਆਂ ਹਨ, ਜਦਕਿ ਨਵੇਂ ਹਿੱਸੇ Zig ਵਿੱਚ ਬਣਦੇ ਹਨ।

ਉਹੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ Zig ਉਹ ਫੰਕਸ਼ਨਾਂ export ਵੀ ਕਰ ਸਕਦਾ ਹੈ ਜੋ C ਕਾਲ ਕਰ ਸਕੇ। ਇਸ ਨਾਲ Zig ਨੂੰ ਮੌਜੂਦਾ C/C++ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਪ੍ਰੈਕਟਿਕਲ ਰਾਹ ਮਿਲਦੀ ਹੈ, ਬਦਲਿਆਂ ਵਜੋਂ ਪੂਰਾ ਰੀਰਾਈਟ ਨਾ ਕਰਨਾ ਪਵੇ।

build ਦੇ ਦੌਰਾਨ C headers import ਕਰੋ

ਹ<Data truncated for brevity>