30 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਗਰੇਡਨ ਹੋਅਰ ਅਤੇ ਰਸਟ: ਮੈਮੋਰੀ-ਸੁਰੱਖਿਅਤ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਵਿੱਚ ਬਦਲਾਅ
2006 'ਚ Graydon Hoare ਦੇ ਪ੍ਰਯੋਗ ਤੋਂ ਲੈ ਕੇ ਅੱਜ ਦੇ Rust ਇਕੋਸਿਸਟਮ ਤੱਕ—ਦੇਖੋ ਕਿ ਕਿਵੇਂ ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਤੋਂ ਬਿਨਾਂ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਨੇ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੀ ਸੋਚ ਬਦਲੀ।
2006 'ਚ Graydon Hoare ਦੇ ਪ੍ਰਯੋਗ ਤੋਂ ਲੈ ਕੇ ਅੱਜ ਦੇ Rust ਇਕੋਸਿਸਟਮ ਤੱਕ—ਦੇਖੋ ਕਿ ਕਿਵੇਂ ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਤੋਂ ਬਿਨਾਂ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਨੇ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੀ ਸੋਚ ਬਦਲੀ।
ਇਹ ਲੇਖ ਇਕ ਕੇਂਦ੍ਰਿਤ ਉਤਪੱਤੀ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ: ਕਿਵੇਂ Graydon Hoare ਦਾ ਨਿੱਜੀ ਪ੍ਰਯੋਗ Rust ਵਿੱਚ ਬਦਲਿਆ, ਅਤੇ ਕਿਉਂ Rust ਦੇ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਨੇ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਲਈ ਉਮੀਦਾਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ।
“ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ” ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਅਤੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਖ਼ਤਰੇ ਦੇ ਨੇੜੇ ਹੁੰਦੀ ਹੈ। ਇਹ browser, ਗੇਮ ਇੰਜਣ, ਓਐਸ ਕੰਪੋਨੈਂਟ, ਡੇਟਾਬੇਸ, ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਐਮਬੇਡਡ ਸਾਫਟਵੇਅਰ ਵਰਗੀਆਂ ਜਗ੍ਹਾਂ 'ਤੇ ਮਿਲਦੀ ਹੈ—ਜਿੱਥੇ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ:
ਰਿਵਾਇਤੀ ਤੌਰ 'ਤੇ ਇਹ ਤਿਕੜਮੀ C ਅਤੇ C++ ਵੱਲ ਧakel ਦਿੰਦੀ ਸੀ, ਨਾਲ ਹੀ ਕਠੋਰ ਨਿਯਮ, ਰਿਵਿਊ ਅਤੇ ਟੂਲਿੰਗ ਜੋ ਮੈਮੋਰੀ-ਸੰਬੰਧੀ ਬੱਗਾਂ ਨੂੰ ਘਟਾਉਂਦੇ।
Rust ਦਾ ਸਿਰਲੇਖ ਵਾਅਦਾ ਆਸਾਨੀ ਨਾਲ ਕਹਿਣ ਵਾਲਾ ਹੈ ਪਰ ਪੂਰਾ ਕਰਨ ਲਈ ਮੁਸ਼ਕਲ:
ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਦੇ ਬਗੈਰ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ।
Rust ਆਮ ਫੇਲੀਆਂ—use-after-free, double-free ਅਤੇ ਬਹੁਤ ਸਰੇ data races—ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਤਰਿਕਾ ਰਨਟਾਈਮ ਰੁਕਣ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਦੀ ਥਾਂ, Rust ownership ਅਤੇ borrowing ਰਾਹੀਂ ਕੰਪਾਇਲ ਸਮੇਂ ਤੇ ਇਹ ਕੰਮ ਵਧੇਰੇ ਭਾਰ ਦਿੰਦਾ ਹੈ।
ਤੁਸੀਂ ਇਤਿਹਾਸ (ਪਹਿਲੇ ਵਿਚਾਰਾਂ ਤੋਂ Mozilla ਦੀ ਸ਼ਾਮਿਲਗੀ ਤੱਕ) ਅਤੇ ਮੁੱਖ ਸੰਕਲਪ (ownership, borrowing, lifetimes, safe vs unsafe) ਸਧਾਰਣ ਭਾਸ਼ਾ 'ਚ ਪੜ੍ਹੋਗੇ।
ਜੋ ਨਹੀਂ ਮਿਲੇਗਾ: ਪੂਰਾ Rust ਟਿਊਟੋਰਿਅਲ, ਸੰਪੂਰਨ syntax ਦੀ ਯਾਤਰਾ, ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਸੈਟਅੱਪ ਦੇ ਕਦਮ-ਦਰ-ਕਦਮ ਨਿਰਦੇਸ਼। ਇਹ ਪੋਸਟ Rust ਦੇ ਡਿਜ਼ਾਈਨ ਦੇ “ਕਿਉਂ” ਨੂੰ ਸਮਝਾਉਂਦੀ ਹੈ, ਕਾਫੀ ਉਦਾਹਰਣਾਂ ਨਾਲ ਤਾਂ ਜੋ ਵਿਚਾਰ ਪੰਜਾਬ ਤਾਂ ਹੋ ਜਾਣ।
ਲੇਖਕ ਦੀ ਟਿੱਪਣੀ: ਪੂਰਾ ਲੇਖ ~3,000 ਸ਼ਬਦ ਦੇ ਆਸ-ਪਾਸ ਟਾਰਗੇਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋਸੇ ਛੋਟੇ ਉਦਾਹਰਣਾਂ ਲਈ ਥਾਂ ਛੱਡਦਾ ਹੈ ਬਿਨਾਂ ਇਸਨੂੰ ਇੱਕ ਰੈਫਰੈਂਸ ਮੈਨੂਅਲ ਬਣਾਏ।
Rust ਕਿਸੇ ਕਮੇਟੀ-ਡਿਜ਼ਾਈਨ ਕੀਤੀ “ਅਗਲੀ C++” ਵਾਂਗ ਨਹੀਂ ਸ਼ੁਰੂ ਹੋਇਆ। ਇਹ 2006 ਵਿੱਚ Graydon Hoare ਦੇ ਨਿੱਜੀ ਪ੍ਰਯੋਗ ਵਜੋਂ ਆਗਿਆ—ਇਹ ਕੰਮ ਉਸਨੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੀਤਾ ਜਦ ਤੱਕ ਇਹ ਵਿਆਪਕ ਧਿਆਨ ਖਿੱਚਣ ਲੱਗਾ। ਇਹ ਸ਼ੁਰੂਆਤ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਪਹਿਲੇ ਫੈਸਲੇ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਤਕਲੀਫਾਂ ਦੂਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਰਗੇ ਦਿਸਦੇ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਭਾਸ਼ਾ ਸਿਧਾਂਤ ‘ਚ ਜਿੱਤਣ ਲਈ।
Hoare ਵੇਖ ਰਿਹਾ ਸੀ ਕਿ ਗਾਰਬੇਜ ਕਲੇਕਟਰ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹਿੰਦੇ ਹੋਏ ਕਿਵੇਂ ਘੱਟ-ਸਤਰੀ, ਤੇਜ਼ ਸਾਫਟਵੇਅਰ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਇਸੇ ਨਾਲ C ਅਤੇ C++ ਵਿੱਚ ਆਮ ਕਰੈਸ਼ ਅਤੇ ਸੁਰੱਖਿਆ ਬੱਗਾਂ ਦੇ ਮੁੱਖ ਕਾਰਨਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ। ਟੈਂਸ਼ਨ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਲਈ ਜਾਣੀ-ਪਹਚਾਣੀ ਹੈ:
Rust ਦੀ “ਗਾਰਬੇਜ ਬਿਨਾਂ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ” ਦਿਸ਼ਾ ਪਹਿਲਾਂ ਮਾਰਕੀਟਿੰਗ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਡਿਜ਼ਾਈਨ ਨਿਸ਼ਾਨਾ ਸੀ: ਸਿਸਟਮ ਕੰਮ ਲਈ ਉਚਿਤ ਪ੍ਰਦਰਸ਼ਨ ਰੱਖੋ, ਪਰ ਬਹੁਤ ਸਾਰੀਆਂ ਮੈਮੋਰੀ-ਬੱਗ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਦਰਅੰਦਾਜ਼ ਕਰਨਾ ਔਖਾ ਕਰੋ।
ਪ੍ਰਸ਼ਨ ਵਾਜਬ ਹੈ: ਇਹ “ਸਿਰਫ਼ C/C++ ਲਈ ਵਧੀਆ ਕੰਪਾਇਲਰ” ਕਿਉਂ ਨਹੀਂ ਸੀ? static analysis, sanitizers ਅਤੇ safer libraries ਕਈ ਮੁੱਦੇ ਰੋਕਦੇ ਹਨ, ਪਰ ਐਨ ਨੇ ਗਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਮੂਲ ਭਾਸ਼ਾ ਪੈਟਰਨਾਂ ਉਹ ਹਨ ਜੋ ਬਾਹਰੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਰੀਖਣ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ।
Rust ਨੇ ਮੁੱਖ ਨਿਯਮ ਭਾਸ਼ਾ ਅਤੇ ਟਾਈਪ ਸਿਸਟਮ ਵਿੱਚ ਲਾ ਦਿੱਤੇ ਤਾਂ ਕਿ ਸੁਰੱਖਿਆ ਇੱਕ ਡਿਫਾਲਟ ਨਤੀਜਾ ਬਣ ਜਾਵੇ, ਫਿਰ ਵੀ ਸਪਸ਼ਟ escape hatches ਰੱਖੇ ਰਹਿੰਦੇ ਹਨ ਜਿੱਥੇ ਮਨੁੱਖੀ ਨਿਰਣੇ ਲਾਜਮੀ ਹੋਣ।
Rust ਦੇ ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਬਾਰੇ ਕੁਝ ਵਿਵਰਣ ਅਨੇਕ ਵਾਰ ਬਿਆਨਕਥਨਾਂ ਵਜੋਂ ਫੈਲਦੇ ਹਨ। ਇਸ ਉਤਪੱਤੀ ਕਹਾਣੀ ਨੂੰ ਦੱਸਦੇ ਵੇਲੇ ਇਹ ਮਦਦਗਾਰ ਹੈ ਕਿ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਦਰਜ ਕੀਤੇ ਹੋਏ ਮੋੜ—ਜਿਵੇਂ 2006 ਦੀ ਸ਼ੁਰੂਆਤ ਅਤੇ Mozilla Research ਵਿੱਚ ਬਾਅਦ ਦੀ ਦਾਖਲ—ਅਲੱਗ ਕੀਤੇ ਜਾਣ।
ਮੂਲ ਸਰੋਤਾਂ ਲਈ, ਪਹਿਲੀ Rust ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਅਤੇ ਡਿਜ਼ਾਈਨ ਨੋਟ, Graydon Hoare ਦੀਆਂ ਗੱਲਾਂ/ਇੰਟਰਵਿਊਜ਼ ਅਤੇ Mozilla/Servo-ਯੁੱਗ ਦੀਆਂ ਪੋਸਟਾਂ ਵੇਖੋ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਲਿਆ ਗਿਆ ਅਤੇ ਲਕੜੀ ਕਿਵੇਂ ਰੂਪ ਰੇਖਿਤ ਕੀਤੀ ਗਈ। ਹੋਰ ਪੜ੍ਹਾਈ ਲਈ ਦੇਖੋ /blog।
ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਕਸਰ ਹਾਰਡਵੇਅਰ ਦੇ ਨੇੜੇ ਕੰਮ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਨੇੜੇਪਣ ਹੀ ਕੋਡ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸੰਸਾਧਨ-ਕੁਸ਼ਲ ਬਣਾਉਂਦਾ ਹੈ। ਪਰ ਇਨ੍ਹਾਂ ਹੀ ਕਾਰਨਾਂ ਕਰਕੇ ਮੈਮੋਰੀ ਗਲਤੀਆਂ ਬਹੁਤ ਨੁਕਸਾਨਦੇਹ ਹੁੰਦੀਆਂ ਹਨ।
ਕੁਝ ਕਲਾਸਿਕ ਬੱਗ ਹਮੇਸ਼ਾਂ ਮੁੜ ਕੇ ਆਉਂਦੇ ਹਨ:
ਇਹ ਗਲਤੀਆਂ ਹਮੇਸ਼ਾਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਹਫ਼ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕਿਸੇ ਵਿਲੱਖਣ timing ਜਾਂ ਇਨਪੁਟ ਦੇ ਕਾਰਨ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਟੈਸਟਿੰਗ ਤੁਹਾਡੇ ਦੁਆਰਾ ਚੈੱਕ ਕੀਤੀਆਂ ਘਟਨਾਵਾਂ ਲਈ ਕਮ ਕਰਦੀ ਹੈ। ਮੈਮੋਰੀ ਬੱਗ ਅਕਸਰ ਉਨ੍ਹਾਂ ਕੇਸਾਂ ਵਿੱਚ ਛੁਪੇ ਰਹਿੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਟੈਸਟ ਕੀਤੇ: ਅਜਿਹੇ ਇਨਪੁਟ, ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ, ਹੌਲੀ timing ਤਬਦੀਲੀਆਂ, ਜਾਂ ਨਵੇਂ ਕੰਪਾਇਲਰ ਵਰਜਨ। ਉਹ ਨਾ-ਨਿਰਣਾਯਕ (non-deterministic) ਵੀ ਹੋ ਸਕਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਮਲਟੀ-ਥ੍ਰੈਡਡ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ—ਜਿਸ ਕਰਕੇ ਲਾਗ ਜਾਂ ਡੀਬੱਗਰ ਜੋੜਨ 'ਤੇ ਬੱਗ ਲੁਕ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਮੈਮੋਰੀ ਗਲਤ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸੁਥਰਾ ਏਰਰ ਨਹੀਂ ਮਿਲਦਾ। ਤੁਸੀਂ ਕਰਪਟ ਸਟੇਟ, ਅਣਪੇਸ਼ਾ ਕਰੈਸ਼ ਅਤੇ ਅਜਿਹੀਆਂ ਸੁਰੱਖਿਆ ਕਮੀਆਂ ਮਿਲਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਮਲਾਕਰ ਲੱਭਦੇ ਹਨ। ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਗੜਬੜਾਂ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਸ਼ਕਤੀ ਲਾਉਣੀ ਪੈਂਦੀ ਹੈ ਜੋ ਦੁਹਰਾਉਣਾ ਮੁਸ਼ਕਲ ਅਤੇ ਨਿਰਾਕਰਨ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਨੀਵ-ਸਤਰੀ ਸੌਫਟਵੇਅਰ ਹਮੇਸ਼ਾਂ ਭਾਰੀ ਰਨਟਾਈਮ ਚੇਕਾਂ ਜਾਂ ਲਗਾਤਾਰ ਮੈਮੋਰੀ ਸਕੈਨ ਦੀ ਕੀਮਤ ਨਹੀਂ ਭਰ ਸਕਦਾ। ਲਕੜੀ ਵਾਂਗ, ਲਕੜੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ—ਕੌਣ ਇਸ ਨੂੰ ਰੱਖਦਾ ਹੈ, ਕੌਣ ਸਾਂਝਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ ਵਾਪਸ ਕਰਨਾ ਹੈ। ਰਿਵਾਇਤੀ ਤੌਰ 'ਤੇ ਭਾਸ਼ਾਵਾਂ ਉਹ ਨਿਯਮ ਮਨੁੱਖੀ ਅਨੁਸ਼ਾਸਨ 'ਤੇ ਛੱਡ ਦੇਂਦੀਆਂ ਸਨ। Rust ਦੀ ਸ਼ੁਰੂਆਤ ਇਸ ਟਰੇਡ-ਆਫ਼ ਨੂੰ ਚੁਣੌਤੀ ਦੇਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।
ਗਾਰਬੇਜ ਕਲੇਕਸ਼ਨ (GC) ਉਹ ਆਮ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਭਾਸ਼ਾਵਾਂ ਮੈਮੋਰੀ ਬੱਗਾਂ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ। ਰਨਟਾਈਮ ਇਹ ਟਰੇਕ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਓਬਜੈਕਟ ਇਹਨਾਂ ਵਿਚੋਂ ਪਹੁੰਚ ਯੋਗ ਹਨ ਅਤੇ ਬਾਕੀ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਰੀਕਲੇਮ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ use-after-free, double-free ਅਤੇ ਕਈ ਲੀਕਸ ਰੋਕੀਆਂ ਜਾਣਦੀਆਂ ਹਨ।
GC “ਖਰਾਬ” ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਪ੍ਰੋਗਰਾਮ ਦੀ ਪ੍ਰਦਰਸ਼ਨ ਪਹੁੰਚ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜਿਆਦਾਤਰ ਕਲੇਕਟਰ ਕਿਸੇ ਸੰਯੋਗ ਤੋਂ ਇਹ ਲਿਆਉਂਦੇ ਹਨ:
ਕਈ ਐਪਲੀਕੇਸ਼ਨ—ਵੈੱਬ ਬੈਕਐਂਡ, ਕਾਰੋਬਾਰ ਸੌਫਟਵੇਅਰ, ਟੂਲਿੰਗ—ਲਈ ਇਹ ਲਾਗਤ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦੀ ਹੈ। ਆਧੁਨਿਕ GC ਬਹੁਤ ਚੰਗੇ ਹਨ ਅਤੇ ਉਹ ਵਿਕਾਸਕਰਤਿਆਂ ਦੀ ਉਦਯੋਗਿਕਤਾ ਵਧਾਉਂਦੇ ਹਨ।
ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਵਿੱਚ worst-case ਵਿਹਾਰ ਅਕਸਰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਬਰਾਊਜ਼ਰ ਇੰਜਣ ਨੂੰ ਸਮੂਥ ਰੇਂਡਰਿੰਗ ਚਾਹੀਦੀ ਹੈ; ਇੱਕ ਐਂਬੇੱਡਡ ਕੰਟਰੋਲਰ ਕੋਲ ਕਠੋਰ ਟਾਈਮਿੰਗ ਸੀਮਾ ਹੋ ਸਕਦੀ ਹੈ; ਘੱਟ-ਲੇਟੈਂਸੀ ਸਰਵਰ ਨੂੰ ਲੋਡ ਹੇਠਾਂ tail latency tight ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਮਾਹੌਲਾਂ ਵਿੱਚ “ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼” ਆਮ ਤੌਰ 'ਤੇ “ਲਗਾਤਾਰ ਪੇਸ਼ਗੋਈਯੋਗ” ਨਾਲੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।
Rust ਦਾ ਵੱਡਾ ਵਾਅਦਾ ਸੀ: C/C++-ਜਿਹੀ ਨਿਯੰਤਰਣ ਰੱਖਦਿਆਂ ਵੀ ਗਾਰਬੇਜ ਕਲੇਕਟਰ 'ਤੇ ਨਿਰਭਰ ਹੋਏ ਬਗੈਰ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ देਓ। ਮਕਸਦ ਪੇਸ਼ਗੋਈਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਲੱਭਣਾ ਹੈ—ਉਸੇ ਸਮੇਤ ਸੁਰੱਖਿਅਤ ਕੋਡ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਣਾ।
ਇਹ ਦਲੀਲ ਇਹ ਨਹੀਂ ਕਿ GC ਘੱਟ ਮਿਆਰੀ ਹੈ। ਇਹ ਇੱਕ ਇਸ ਬੇਟ ਸੀ ਕਿ ਇੱਕ ਵੱਡਾ ਅਤੇ ਮਹੱਤਵਪੂਰਣ ਮਿਡਲ-ਗ੍ਰਾਊਂਡ ਹੈ: ਸੋਫਟਵੇਅਰ ਜੋ ਨੀਵ-ਸਤਰੀ ਨਿਯੰਤਰਣ ਅਤੇ ਆਧੁਨਿਕ ਸੁਰੱਖਿਆ ਗੈਰੰਟੀਜ਼ ਚਾਹੁੰਦਾ ਹੈ।
ਓਨਰਸ਼ਿਪ Rust ਦਾ ਸਧਾਰਣ ਪਰ ਵੱਡਾ ਵਿਚਾਰ ਹੈ: ਹਰ ਵੈਲਯੂ ਦਾ ਇੱਕ ਇਕਲੋਤਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ ਜੋ ਜਾਂਚਦਾ ਹੈ ਕਿ ਜਦੋਂ ਉਹ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ ਤਾਂ ਉਸਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਜਾਵੇ।
ਇਹ ਇਕ ਨਿਯਮ C ਅਤੇ C++ ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਦੇ ਮਨ ਵਿੱਚ ਵਿਆਪਤ “ਕੌਣ ਇਹ ਮੈਮੋਰੀ ਫ੍ਰੀ ਕਰੇਗਾ?” ਦੀ ਕਾਫ਼ੀ ਹਿਸਾਬ ਕਿਤਾਬ ਹਟਾ ਦਿੰਦਾ। Rust cleanup ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕਾਪੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਆਜ਼ਾਦ ਨਕਲ ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਮੂਵ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੂਲ ਨੂੰ ਹਵਾਲਾ ਕਰ ਦਿੰਦੇ ਹੋ—ਮੂਵ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣਾ ਵੈਰੀਏਬਲ ਉਸ ਨੂੰ ਵਰਤ ਨਹੀਂ ਸਕਦਾ।
Rust ਬਹੁਤ ਸਾਰੇ heap-ਅਲੋਕੇਟੇਡ ਵੈਲਯੂਜ਼ (ਜਿਵੇਂ strings, buffers, vectors) ਨੂੰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ moved ਵਜੋਂ ਸਲੱਘਦਾ ਹੈ। ਬੇਸਰੋਕੀ ਕਾਪੀ ਮਹੰਗੀ ਵੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵੀ ਗੱਲ, ਜੇ ਦੋ ਵੈਰੀਏਬਲ ਇੱਕੋ allocation ਨੂੰ ਮਾਲਕੀ ਦੱਸਣ ਲੱਗਣ ਤਾਂ ਗਲਤੀਆਂ ਆਸਾਨ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਇਹ خیال ਛੋਟੀ pseudo-code ਵਿੱਚ:
buffer = make_buffer()
ownerA = buffer // ownerA owns it
ownerB = ownerA // move ownership to ownerB
use(ownerA) // not allowed: ownerA no longer owns anything
use(ownerB) // ok
// when ownerB ends, buffer is cleaned up automatically
ਕਿਉਂਕਿ ਹਮੇਸ਼ਾਂ ਇੱਕ ਹੀ ਮਾਲਕ ਹੁੰਦਾ ਹੈ, Rust ਠੀਕ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਸ ਵੇਲੇ ਇੱਕ ਵੈਲਯੂ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਜਦੋਂ ਉਸ ਦਾ ਮਾਲਕ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਚੱਲ ਜਾਏ। ਇਸ ਦਾ ਮਤਲਬ ਆਟੋਮੈਟਿਕ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਹੈ (ਤੁਸੀਂ ਹਰ ਜਗ੍ਹਾ free() ਨਹੀਂ ਬੋਲਦੇ) ਬਗੈਰ ਕਿਸੇ ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਦੀ ਲੋੜ ਤੋਂ।
ਇਹ ਓਨਰਸ਼ਿਪ ਨਿਯਮ ਕਈ ਆਮ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ:
Rust ਦਾ ownership ਮਾਡਲ ਸਿਰਫ਼ ਸੁਰੱਖਿਆ ਆਦਤਾਂ ਨੂੰ ਉੱਤਸਾਹ ਨਹੀਂ ਦਿੰਦਾ—ਉਹ ਕਈ ਅਣਸੁਰੱਖਿਅਤ ਹਾਲਤਾਂ ਨੂੰ ਅਪਰੇਪਟੇਬਲ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ ਬਾਕੀ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਬੁਨਿਆਦ ਹੈ।
ਓਨਰਸ਼ਿਪ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੌਣ ਵੈਲਯੂ ਨੂੰ own ਕਰਦਾ ਹੈ। Borrowing ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਹੋਰ ਕੋਡ ਉਸ ਵੈਲਯੂ ਨੂੰ ਹਰਜਾਈ ਸਮੇਂ ਲਈ ਕਿਵੇਂ ਵਰਤ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਮਾਲਕੀ ਲੈਣ ਦੇ।
ਜਦੋਂ ਤੁਸੀਂ Rust ਵਿੱਚ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ borrow ਕਰਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਉਸ ਦੀ ਇੱਕ reference ਮਿਲਦੀ ਹੈ। ਮੂਲ ਮਾਲਕ ਹੀ ਮੈਮੋਰੀ ਦੀ cleaning ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਰਹਿੰਦਾ ਹੈ; borrower ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਇਸਨੂੰ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਲੈਂਦਾ ਹੈ।
Rust ਵਿੱਚ ਦੋ ਕਿਸਮ ਦੇ borrows ਹਨ:
&T): ਕੇਵਲ ਪੜ੍ਹਨ ਲਈ ਐਕਸੈਸ।&mut T): ਪੜ੍ਹਨ-ਲੇਖਨ (read-write) ਲਈ ਐਕਸੈਸ।Rust ਦਾ ਕੇਂਦਰੀ borrowing ਨਿਯਮ ਆਸਾਨੀ ਨਾਲ ਕਹਿਣ ਵਾਲਾ ਅਤੇ ਅਮਲ ਵਿੱਚ ਸ਼ਕਤੀਸ਼ালী ਹੈ:
ਇਹ ਨਿਯਮ ਇੱਕ ਆਮ ਗਲਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ: ਕੋਈ ਹਿੱਸਾ ਡੇਟਾ ਪੜ੍ਹ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੂਜਾ हिस्सा ਉਸਨੂੰ ਤਹਿ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ reference ਸਿਰਫ਼ ਤਦੋਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਕਦੇ ਵੀ ਉਸ ਚੀਜ਼ ਤੋਂ ਲੰਮਾ ਸਮਾਂ ਜੀਊ ਨਾ ਕਰੇ ਜਿਸ ਦੀ ਉਹ ਹਵਾਲਾ ਹੈ। Rust ਇਸ ਅਵਧੀ ਨੂੰ ਲਾਈਫਟਾਈਮ ਕਹਿੰਦਾ ਹੈ—ਉਸ ਸਮੇਂ ਦੀ ਖਿੱਚ ਜਦੋਂ ਤੱਕ reference ਵੈਧ ਰਹਿੰਦੀ ਹੈ।
ਤੁਹਾਨੂੰ formalਤਮੀਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ: ਇੱਕ reference ਮਾਲਕ ਦੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਨਹੀਂ ਟਿਕ ਸਕਦੀ।
Rust ਇਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਕੰਪਾਇਲ ਸਮੇਂ borrow checker ਰਾਹੀਂ ਅਮਲ ਕਰਵਾਉਂਦਾ ਹੈ। ਮੈਮੋਰੀ ਦੀ ਗਲਤ ਵਰਤੋਂ ਦੀ ਉਮੀਦ ਕਰਨ ਦੀ ਬਜਾਏ, Rust ਉਨ੍ਹਾਂ ਕੋਡਾਂ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ ਜੋ ਮੈਮੋਰੀ ਦੇ ਗਲਤ ਉਪਯੋਗ ਨੂੰ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਸਾਂਝੇਕਿਤ ਦਸਤਾਵੇਜ਼ ਬਾਰੇ ਸੋਚੋ:
Concurrency ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ “ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ ਚਲਦਾ ਹੈ” ਵਾਲੀ ਗਲਤੀ ਲੁਕ ਜਾਂਦੀ ਹੈ। ਜਦ ਦੋ ਥ੍ਰੈਡ ਇੱਕੋ ਸਮੇਂ ਚੱਲਦੇ ਹਨ, ਉਹ ਅਚਾਨਕ ਢੰਗ ਨਾਲ ਅਪਰਸਪਰ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਉਹ ਸਾਂਝਾ ਡੇਟਾ ਵਰਤ ਰਹੇ ਹੋਣ।
ਡੇਟਾ ਰੇਸ ਉਸ ਵਕਤ ਹੁੰਦੀ ਹੈ ਜਦੋਂ:
ਨਤੀਜਾ ਸਿਰਫ਼ “ਗਲਤ ਨਤੀਜਾ” ਹੀ ਨਹੀਂ; ਡੇਟਾ ਰੇਸ ਸਟੇਟ ਕਰਪਟ ਕਰ ਸਕਦੀ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਥੇ ਤੱਕ ਕਿ ਉਹ ਅੰਤਰਾਲੀ ਹੋ ਸਕਦੇ ਹਨ—ਲਾਗ ਸ਼ਾਮਿਲ ਕਰਨ ਜਾਂ ਡੀਬੱਗਰ ਚਲਾਉਣ 'ਤੇ ਬੱਗ ਗਾਇਬ ਹੋ ਸਕਦੀ ਹੈ।
Rust ਇੱਕ ਅਣਛੁਹੀ ਸਥਿਤੀ ਲੈਂਦਾ: ਹਰ ਪ੍ਰੋਗ੍ਰਾਮਰ 'ਤੇ ਹਰ ਵਾਰੀ ਨਿਯਮ ਯਾਦ ਰੱਖਣ ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ, Rust ਬਹੁਤ ਸਾਰੇ unsafe concurrency ਪੈਟਰਨਾਂ ਨੂੰ safe ਕੋਡ ਵਿੱਚ ਪੁਰੀ ਤਰ੍ਹਾਂ ਅਭਿਵਿਆਕਤ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦਾ ਹੈ।
ਉੱਚ-ਸਤਰ 'ਤੇ, Rust ਦੀ ownership-ਅਤੇ-borrowing ਨਿਯਮਾਂ ਸਿੰਗਲ-ਥ੍ਰੈਡਡ ਕੋਡ 'ਤੇ ਹੀ ਨਹੀਂ ਰੁਕਦੀਆਂ। ਉਹ ਇਹ ਨਿਨਿਸ਼ਚਿਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਚੀਜ਼ ਰਥੇ ਉੱਤੇ ਸਾਂਝੀ ਕਰ ਰਹੇ ਹੋ। ਜੇ ਕੰਪਾਇਲਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਸਾਂਝਾ ਐਕਸੈਸ ਸਹੀ ਢੰਗ ਨਾਲ ਕੋਆਰਡੀਨੇਟ ਹੈ, ਤਾਂ ਇਹ ਕੋਡ ਕੰਪਾਇਲ ਨਹੀਂ ਹੋਵੇਗਾ।
ਇਹੀ ਲੋਕੀ ਭਾਸ਼ਾ ਵਿਚ “Rust ਵਿੱਚ safe concurrency” ਦਾ ਅਰਥ ਹੈ: ਤੁਸੀਂ ਫਿਰ ਵੀ concurrent ਪ੍ਰੋਗਰਾਮ ਲਿਖ ਸਕਦੇ ਹੋ, ਪਰ “ਦੋ ਥ੍ਰੈਡ ਇੱਕੋ ਚੀਜ਼ ਲਿਖ ਦਿੱਤੀ” ਕਿਸਮ ਦੀਆਂ ਗਲਤੀਆਂ ਕੰਪਾਇਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੜ ਲਈਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਦੋ ਥ੍ਰੈਡ ਇੱਕੋ ਕਾਊਂਟਰ ਨੂੰ ਇੰਕਰੀਮੈਂਟ ਕਰ ਰਹੇ ਹਨ:
Rust ਨੀਵ-ਸਤਰੀ concurrency ਤਰਕੀਬਾਂ ਨੂੰ ਮਨਾਹੀ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ quarantine ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਚਮੁੱਚ ਕੁਝ ਅਜਿਹਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਕੰਪਾਇਲਰ ਸਾਰਥਕ ਤੌਰ 'ਤੇ ਸਬੂਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ unsafe ਬਲੌਕ ਵਰਤ ਸਕਦੇ ਹੋ—ਇਹ ਇੱਕ ਚੇਤਾਵਨੀ-ਟੈਗ ਵਾਂਗ ਹੈ: “ਇੱਥੇ ਮਨੁੱਖੀ ਜਿੰਮੇਵਾਰੀ ਲਾਜ਼ਮੀ ਹੈ।” ਇਹ ਵੰਡ ਕੋਡਬੇਸ ਦੇ ਵੱਡੇ ਹਿੱਸੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਤੱਤ-ਸਤਰੀ ਤਾਕਤ ਜਿੱਥੇ ਲੋੜੀਂਦੀ ਹੈ ਉਥੇ ਵੀ ਮਿਲਦੀ ਹੈ।
Rust ਦੀ ਸੁਰੱਖਿਆ ਦੀ شہرت ਕੁਝ ਹੱਦ ਤੱਕ ਪੂਰੀ ਨਹੀਂ ਦਿਖਾਉਂਦੀ—ਅਸਲ ਗੱਲ ਇਹ ਹੈ ਕਿ Rust ਸੁਰੱਖਿਆ ਅਤੇ ਅਨਸੁਰੱਖਿਅਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦਰਮਿਆਨ ਦੀ ਹੱਦ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ—ਅਤੇ ਆਡੀਟ ਕਰਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਅਧਿਕਤਰੀ Rust ਕੋਡ “safe Rust” ਹੈ। ਇੱਥੇ ਕੰਪਾਇਲਰ ਨਿਯਮ ਲਗਾਂਦਾ ਹੈ ਜੋ ਆਮ ਮੈਮੋਰੀ ਬੱਗ ਰੋਕਦੇ ਹਨ: use-after-free, double free, dangling pointers ਅਤੇ data races। ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਤਰਕ ਦੀਆਂ ਗਲਤੀਆਂ ਲਿਖ ਸਕਦੇ ਹੋ, ਪਰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਫੀਚਰਾਂ ਰਾਹੀਂ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਨੂੰ ਸਰਲਤਾਪੂਰਵਕ ਭੰਗ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਇੱਕ ਮੁੱਖ ਗੱਲ: safe Rust “ਧੀਮਾ Rust” ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਹਾਈ-ਪਰਫਾਰਮੈਂਸ ਪ੍ਰੋਗਰਾਮ ਪੂਰੇ safe Rust ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਕੰਪਾਇਲਰ ਇਕ ਵਾਰੀ ਨਿਯਮਾਂ ’ਤੇ ਭਰੋਸਾ ਕਰ ਡਾਲੇ ਤਾਂ ਇਹ ਅਗਰੈਸੀਵ ਅਪਟਿਮਾਈਜ਼ ਕਰ ਸਕਦਾ ਹੈ।
unsafe ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਕਈ ਵਾਰ ਨੀਵ-ਸਤਰੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਉਹ ਸਮਰੱਥਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੰਪਾਇਲਰ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਆਮ ਵਜ੍ਹਾਂ:
unsafe ਵਰਤਣਾ ਸਾਰੇ ਚੇਕਾਂ ਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰਦਾ—ਇਹ ਸਿਰਫ਼ ਕੁਝ ਚਲਾਂ ਨੂੰ ਆਗਿਆ ਦਿੰਦਾ (ਜਿਵੇਂ raw pointers ਨੂੰ dereference ਕਰਨਾ) ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਮਨਾਹੀ ਹੁੰਦੀਆਂ ਹਨ।
Rust ਤੁਹਾਨੂੰ unsafe functions ਅਤੇ ਬਲੌਕਾਂ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਨਿਸ਼ਾਨੀਤ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਜੋਖਮ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਸਾਫ਼ دکھਾਈ ਦਿੰਦਾ ਹੈ। ਆਮ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਛੋਟਾ “unsafe core” ਲੈ ਕੇ ਉਸਨੂੰ ਇੱਕ safe API ਵਿੱਚ ਰੈਪ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਕਿ ਕੋਡਬੇਸ ਦਾ ਵੱਧਤਰ ਹਿੱਸਾ safe Rust ਵਿੱਚ ਹੀ ਰਹੇ।
unsafe ਨੂੰ ਇੱਕ طاقتਵਰ ਸੰਦ ਵਾਂਗ ਸੋਚੋ:
ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਵੇ ਤਾਂ unsafe Rust ਨੀਵ-ਸਤਰੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਵਾਲੇ ਹਿੱਸਿਆਂ ਲਈ ਨਿਯੰਤਰਿਤ ਇੰਟਰਫੇਸ ਬਣ ਜਾਂਦਾ ਹੈ—ਬਿਨਾਂ ਇਹਨਾਂ ਨੇ Rust ਦੀਆਂ ਬਾਕੀ ਸੁਰੱਖਿਆ ਲਾਭਾਂ ਨੂੰ ਖਤਮ ਕੀਤਾ ਹੋਵੇ।
Rust is not just clever on paper; it became real because Mozilla put the ideas under pressure.
Mozilla Research performance-critical browser components ਵਿੱਚ security bugs ਘਟਾਉਣ ਦੇ ਤਰੀਕੇ ਲੱਭ ਰਹੀ ਸੀ। ਬਰਾਊਜ਼ਰ ਇੰਜਣ ਬਹੁਤ ਜਟਿਲ ਹੁੰਦੇ ਹਨ: ਉਹ ਅਣ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਨੂੰ parse ਕਰਦੇ, ਵੱਡੀ ਮੈਮੋਰੀ ਸੰਭਾਲਦੇ ਅਤੇ ਉੱਚ concurrency 'ਚ ਚੱਲਦੇ। ਇਸਤੋਂ memory-safety flaws ਅਤੇ race conditions ਆਮ ਅਤੇ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ।
Rust ਨੂੰ support ਕਰਨ ਨਾਲ Mozilla ਦੇ ਲਕੜੀ: ਸਿਸਟਮ-ਸਤਰੀ ਦੀ ਰਫ਼ਤਾਰ ਰੱਖਦੇ ਹੋਏ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਦੀਆਂ vulnerabilities ਘਟਾਉਣ। Mozilla ਦੀ ਸ਼ਾਂਮਿਲਗੀ ਨੇ ਵੱਡੀ ਦੁਨੀਆਂ ਨੂੰ ਸੁਚੇਤ ਕੀਤਾ ਕਿ Rust ਸਿਰਫ਼ Graydon Hoare ਦੀ ਨਿੱਜੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਭਾਸ਼ਾ ਹੈ ਜਿਸਨੂੰ ਦੁਨੀਆ ਦੇ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਕੋਡਬੇਸਾਂ 'ਤੇ ਟੈਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
Servo—ਪਰਯੋਗਾਤਮਕ ਬਰਾਊਜ਼ਰ ਇੰਜਣ—Rust ਨੂੰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਅਜ਼ਮਾਉਣ ਲਈ ਇਕ ਮੁੱਖ ਥਾਂ ਬਣਿਆ। ਮਕਸਦ ਬਰਾਊਜ਼ਰ ਬਾਜ਼ਾਰ ਜਿੱਤਣਾ ਨਾ ਸੀ; Servo ਇੱਕ ਲੈਬ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਸੀ ਜਿੱਥੇ ਭਾਸ਼ਾ ਫੀਚਰ, ਕੰਪਾਇਲਰ diagnostics ਅਤੇ ਟੂਲਿੰਗ ਨੂੰ ਅਸਲੀ-ਦਬਾਅ ਦੇ ਨਾਲ ਮੁਲਿਆੰਕਣ ਕੀਤਾ ਜਾ ਸਕੇ: build times, cross-platform ਸਮਰਥਨ, ਡਿਵੈਲਪਰ ਅਨੁਭਵ, ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪੈਰੱਲਲਿਸਮ ਹੇਠ correctness।
Servo ਨੇ ਭਾਸ਼ਾ ਦੇ ਆਸਪਾਸ ਇਕੋਸਿਸਟਮ—ਲਾਇਬ੍ਰੇਰੀਜ਼, ਬਿਲਡ ਟੂਲਿੰਗ, ਰਿਵਾਜ਼ ਅਤੇ ਡੀਬੱਗਿੰਗ ਅਭਿਆਸ—ਨੂੰ ਵੀ ਰੂਪ ਦਿੱਤਾ ਜੋ ਟੋਯ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਅੱਗੇ ਜਾ ਕੇ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ।
ਅਸਲੀ-ਜਗਤ ਪ੍ਰੋਜੈਕਟ ਇਕ ਐਸਾ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ ਨੱਕਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜਦੋਂ ਇੰਜੀਨੀਅਰ friction ਮਹਿਸੂਸ ਕਰਦੇ—ਅਸਪਸ਼ਟ error messages, ਲੋੜੀਂਦਾ ਲਾਇਬ੍ਰੇਰੀ ਹਿੱਸਾ, ਅਜਿਹੇ ਅਨੁਕੂਲ ਪੈਟਰਨ—ਉਹ ਦਰਦ ਦੇ ਬਿੰਦੂ ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੇ। ਸਮੇਂ ਦੇ ਨਾਲ ਇਹ ਨਿਰੰਤਰ ਦਬਾਅ Rust ਨੂੰ ਇੱਕ promising ਧਾਰਨਾ ਤੋਂ ਇੱਕ ਐਸੇ ਚੀਜ਼ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ ਜਿਸ ਉਤੇ ਟੀਮਾਂ ਭਰੋਸਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਇਸ ਫੇਜ਼ ਤੋਂ ਬਾਅਦ Rust ਦੇ ਵਿਆਪਕ ਵਿਕਾਸ ਦੀ ਖੋਜ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/rust-memory-safety-without-gc ਦੇਖੋ।
Rust ਇਕ ਮਿੱਡਲ-ਗ੍ਰਾਊਂਡ ਵਿੱਚ ਬੈਠਦਾ ਹੈ: ਇਹ ਉਹ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਨਿਯੰਤਰਣ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ ਜੋ C ਅਤੇ C++ ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਉਹਨਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਬੱਗ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ ਜੋ ਉਹ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਮਨੁੱਖੀ ਅਨੁਸ਼ਾਸਨ, ਟੈਸਟਿੰਗ ਅਤੇ ਕਿਸਮਤ 'ਤੇ ਛੱਡ ਦੇਂਦੀਆਂ ਹਨ।
C ਅਤੇ C++ ਵਿੱਚ ਡਿਵੈਲਪਰ ਮੈਮੋਰੀ ਸਿੱਧਾ ਮੈਨੇਜ ਕਰਦੇ—allocate, free, ਅਤੇ pointers ਨੂੰ ਵੈਧ ਰੱਖਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ। ਇਹ ਫ਼ਰਾਂਤਸ਼ੀਲ ਹੈ ਪਰ use-after-free, double-free, buffer overflows ਅਤੇ subtle lifetime bugs ਆਸਾਨ ਬਣ ਜਾਂਦੇ ਹਨ। ਕੰਪਾਇਲਰ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ।
Rust ਇਸ ਰਿਸ਼ਤੇ ਨੂੰ ਉਲਟ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਹੇਠਲੇ-ਸਤਰੀ ਕੰਟਰੋਲ ਮਿਲਦਾ ਹੈ (stack vs heap ਫੈਸਲੇ, predictable layouts, ownership transfers), ਪਰ ਕੰਪਾਇਲਰ ਇਹ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਇੱਕ ਵੈਲਯੂ ਦਾ ਮਾਲਕ ਹੈ ਅਤੇ references ਕਿੰਨੀ ਦੇਰ ਲਈ ਜੀਊਣਗੇ। Rust ਕਹਿੰਦਾ: “ਪੋਇੰਟਰਾਂ ਨਾਲ ਸਾਵਧਾਨ ਰਹਿਣ ਦੀ ਬਜਾਏ, ਕੰਪਾਇਲਰ ਨੂੰ ਸੁਰੱਖਿਆ ਦਾ ਸਬੂਤ ਦਿਓ,” ਅਤੇ safe Rust ਨੂੰ ਉਹਨਾਂ ਗਾਰੰਟੀਜ਼ ਨੂੰ ਤੋੜਨ ਵਾਲਾ ਕੋਡ ਕੰਪਾਇਲ ਨਹੀਂ ਹੋਣ ਦੇਂਦਾ।
GC ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ (ਜਿਵੇਂ Java, Go, C# ਜਾਂ ਕਈ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ) ਹੱਥੋਂ-ਹੱਥ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਸਹੂਲਤ ਦੇਂਦੀਆਂ ਹਨ: objects ਜਦੋਂ unreachable ਹੋ ਜਾਂਦੇ ਹਨ ਤਦੋਂ ਆਪਣੇ ਆਪ ਫ੍ਰੀ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਵਿਕਾਸਕਰਤਿਆਂ ਦੀ ਉਤਪਾਦਕਤਾ 'ਚ ਵੱਡਾ ਜ਼ਰੀਆ ਬਣਦਾ ਹੈ।
Rust ਦਾ ਵਾਅਦਾ—“ਗਾਰਬੇਜ ਬਿਨਾਂ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ”—ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ GC ਦੀ ਰਨਟਾਈਮ ਕੀਮਤ ਨਹੀਂ ਭਰਣੀ ਪੈਂਦੀ, ਜੋ ਲੇਟੈਂਸੀ, ਮੈਮੋਰੀ ਫੁੱਟਪ੍ਰਿੰਟ, startup ਸਮਾਂ ਜਾਂ ਸੰਸਾਧਨ-ਸੰਕੁਚਿਤ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਟਰੇਡ-ਆਫ਼ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ownership ਨੂੰ ਸਪਸ਼ਟ ਮਾਡਲ ਕਰੋ ਅਤੇ ਕੰਪਾਇਲਰ ਨੂੰ ਇਹ ਲਾਗੂ ਕਰਵਾਉਣ ਦਿਓ।
Rust ਸ਼ੁਰੂ ਵਿੱਚ ਔਖਾ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕ ਨਵਾਂ ਮਾਨਸਿਕ ਮਾਡਲ ਸਿਖਾਵਾਂਦਾ ਹੈ: ਤੁਸੀਂ ownership, borrowing ਅਤੇ lifetimes ਦੇ ਤਰੀਕੇ ਨਾਲ ਸੋਚਦੇ ਹੋ, ਨਾ ਕਿ ਸਿਰਫ਼ “ਇਕ pointer ਦੇ ਕੇ ਉਮੀਦ ਕਰਨਾ ਕਿ ਠੀਕ ਰਹੇਗਾ”। ਪਹਿਲੀ ਮੁਸ਼ਕਿਲ ਆਮ ਤੌਰ 'ਤੇ ਸਾਂਝੇ ਸਟੇਟ ਜਾਂ ਜਟਿਲ object ਗ੍ਰਾਫ ਮਾਡਲ ਕਰਨ ਵੇਲੇ ਆਉਂਦੀ ਹੈ।
Rust ਅਕਸਰ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਚਮਕਦਾ ਹੈ ਜੋ ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ-ਮਹੱਤਵਪੂਰਨ ਸਾਫਟਵੇਅਰ ਬਣਾਉਂਦੀਆਂ ਹਨ—ਬ੍ਰਾਊਜ਼ਰ, ਨੈੱਟਵਰਕਿੰਗ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ, ਐਂਬੇੱਡਡ, ਜਾਂ ਕਠੋਰ ਭਰੋਸੇਯੋਗਤਾ ਵਾਲੇ ਬੈਕਐਂਡਸ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ ਤਾਂ GC ਭਾਸ਼ਾ ਅਜੇ ਵੀ ਵਧੀਆ ਫ਼ਿਟ ਹੋ ਸਕਦੀ ਹੈ।
Rust ਹਰ ਥਾਂ ਦੀ ਬਦਲੀ ਨਹੀਂ ਹੈ; ਪਰ ਜਦੋਂ ਤੁਸੀਂ C/C++-ਜਿਹੀ ਪ੍ਰਦਰਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਉੱਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਸੁਰੱਖਿਆ ਗਾਰੰਟੀਜ਼ ਵੀ, ਤਾਂ Rust ਇੱਕ ਮਜ਼ਬੂਤ ਵਿਕਲਪ ਹੈ।
Rust ਨੇ ਧਿਆਨ ਖਿੱਚਿਆ ਕਿਉਂਕਿ ਇਹ “ਇੱਕ ਸੁਹਣਾ C++” ਹੋਣ ਦਾ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਨੇ ਵਾਤਾਵਰਣ ਨੂੰ ਇਹ ਜ਼ੋਰ ਦਿੱਤਾ ਕਿ ਨੀਵ-ਸਤਰੀ ਕੋਡ ਇਕੱਠੇ ਤੌਰ 'ਤੇ ਤੇਜ਼, ਮੈਮੋਰੀ-ਸੁਰੱਖਿਅਤ ਅਤੇ ਖਰਚਿਆਂ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋ ਸਕਦਾ ਹੈ।
Rust ਤੋਂ ਪਹਿਲਾਂ, ਟੀਮਾਂ ਅਮੂਮਨ ਮੈਮੋਰੀ ਬਗਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਕੀਮਤ ਸਮਝ ਕੇ ਸਹਾਰਦੀਆਂ ਅਤੇ ਫਿਰ ਟੈਸਟ, ਕੋਡ ਰਿਵਿਊ ਅਤੇ ਬਾਦ ਦੇ ਠੀਕ-ਮੁਕਾਮ 'ਤੇ ਉਨ੍ਹਾਂ ਦਾ ਨਿਧਾਨ ਕਰਦੀਆਂ। Rust ਨੇ ਇੱਕ ਵੱਖਰਾ ਬੇਟ ਲਾਈ: ਆਮ ਨਿਯਮਾਂ (ਡੇਟਾ ਦਾ ਮਾਲਕ ਕੌਣ, ਕੌਣ ਮਿਊਟੇਟ ਕਰ ਸਕਦਾ, ਕਦੋਂ reference ਵੈਧ ਹੈ) ਨੂੰ ਭਾਸ਼ਾ ਵਿੱਚ ਐਨਕੋਡ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਕਿ ਕੁਝ ਬੱਗਾਂ ਕਮਪਾਇਲ ਹੀ ਨਾ ਹੋਣ ਪਾਏਂ।
ਇਹ ਤਬਦੀਲੀ ਮਾਨਤਾ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ “ਪੂਰਨ ਹੋਵੋ” ਦੀ ਮੰਗ ਨਹੀਂ ਕੀਤੀ—ਇਸ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਹੋਣ ਲਈ ਪੁੱਛਿਆ ਅਤੇ ਫਿਰ ਕੰਪਾਇਲਰ ਨੇ ਉਸ ਸਪਸ਼ਟਤਾ ਨੂੰ ਲਾਗੂ ਕੀਤਾ।
Rust ਦਾ ਪ੍ਰਭਾਵ ਕਈ ਨਿਸ਼ਾਨਿਆਂ ਵਿੱਚ ਦਰਸਦਾ ਹੈ: ਉਹ ਕੰਪਨੀਆਂ ਜਿਹੜੀਆਂ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਸੌਫਟਵੇਅਰ ਭੇਜਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਦੀ ਵਧ ਰਹੀ ਦਿਲਚਸਪੀ; ਯੂਨੀਵਰਸਿਟੀ ਕੋਰਸਾਂ ਵਿੱਚ ਵੱਧ ਹਿੱਸਾ; ਅਤੇ ਟੂਲਿੰਗ ਜਿਸਦਾ ਅਨੁਭਵ Research ਪ੍ਰੋਜੈਕਟ ਦੇ ਬਦਲੇ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਦੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ (package management, formatting, linting ਅਤੇ ਡੌਕਯੂਮੇੰਟੇਸ਼ਨ ਵਰਕਫਲੋਜ਼)।
ਇਸਦਾ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕਿ Rust ਹਰ ਵਿਸ਼ੇ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ—ਪਰ ਇਹ ਮਤਲਬ ਹੈ ਕਿ safety-by-default ਹੁਣ ਇੱਕ ਹਕੀਕਤ-ਯੋਗ ਉਮੀਦ ਬਣ ਗਈ ਹੈ, ਕਿਸੇ ਲਕਜ਼ਰੀ ਦੇ ਤੌਰ 'ਤੇ ਨਹੀਂ।
Rust ਨੂੰ ਅਕਸਰ ਇਹਨਾਂ ਲਈ ਮੁਲਿਆੰਕਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
“ਨਵਾਂ ਮਿਆਰ” ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਸਿਸਟਮ Rust ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖ ਦਿੱਤਾ ਜਾਵੇ। ਮਤਲਬ ਇਹ ਹੈ: ਮਿਆਰ ਉੱਪਰ ਚਲਿਆ ਗਿਆ—ਟੀਮਾਂ ਹੁਣ ਅਕਸਰ ਪੁੱਛਦੀਆਂ ਹਨ, ਕਿੰਝ ਅਸੀਂ ਮੈਮੋਰੀ-ਅਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਕਿਉਂ ਸਵੀਕਾਰ ਕਰੀਏ ਜਦੋਂ ਸਾਨੂੰ ਲੋੜ ਨਹੀਂ? ਭਾਵੇਂ Rust ਨਹੀਂ ਵਰਤਿਆ ਜਾਵੇ, ਇਸਦਾ ਮਾਡਲ ਇੱਕੋਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ APIs, ਸਪਸ਼ਟ invariants ਅਤੇ ਬਿਹਤਰ ਟੂਲਿੰਗ ਵੱਲ ਧੱਕਿਆ ਹੈ।
ਹੋਰ ਇੰਜੀਨੀਅਰਿੰਗ ਬੈਕਸਟોરીਜ਼ ਲਈ /blog ਖੋਜੋ।
Rust ਦੀ ਉਤਪੱਤੀ ਕਹਾਣੀ ਇੱਕ ਸਧਾਰਣ ਰੇਖਾ ਰੱਖਦੀ ਹੈ: ਇਕ ਨਿੱਜੀ ਸਾਈਡ-ਪ੍ਰੋਜੈਕਟ (Graydon Hoare ਦਾ Rust ਨਾਲ ਪ੍ਰਯੋਗ) ਨੇ ਇੱਕ ਜ਼ੁੰਝਾਲੀ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਸਮੱਸਿਆ ਨਾਲ ਟਕਰਾ ਕੇ ਉਸਦਾ ਹੱਲ ਲੱਭਿਆ, ਜੋ ਕਿ ਸਖਤ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਦੋਹਾਂ ਸੀ।
Rust ਨੇ ਇਕ ਟਰੇਡ-ਆਫ਼ ਨੂੰ ਦੁਬਾਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਿਸਨੂੰ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਅਣਟੱਲ-ਯੋਗ ਮੰਨਦੇ ਸਨ:
ਵਾਸਤਵिक ਬਦਲਾਅ ਇਹ ਨਹੀਂ ਕਿ “Rust ਜ਼ਰੂਰੀ ਹੈ।” ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਭਾਸ਼ਾ ਦੀ ਡਿਫਾਲਟ ਗੁਣ ਹੋ ਸਕਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਕੋਡ-ਰਿਵਿਊ ਅਤੇ ਟੈਸਟਿੰਗ ਰਾਹੀਂ ਸੁਰੱਖਿਆ ਦੀ ਕੋਸ਼ਿਸ਼।
ਜੇ ਤੁਸੀਂ ਰੁਚੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਵੱਡਾ ਰੀਰਾਈਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ:
ਅਹਿਸਾਸੀ ਰਾਹ: ਇੱਕ “ਥਿਨ ਸਲਾਇਸ” ਟੀਚਾ ਲਿਆਓ—ਜਿਵੇਂ “ਫਾਇਲ ਪੜੋ, ਬਦਲ ਕਰੋ, ਨਿਕਾਸ ਕਰੋ”—ਤੇ ਧਿਆਨ ਸਾਫ਼ ਕੋਡ ਲਿਖਣ ਤੇ ਕੇਂਦ੍ਰਿਤ ਕਰੋ ਨਾ ਕਿ ਚਤੁਰ ਕੋਡ ਤੇ।
ਪੂਰੇ ਉਤਪਾਦ ਵਿੱਚ ਇਕ Rust ਕੰਪੋਨੈਂਟ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਦੌਰਾਨ, ਚਾਰੂ-ਪਾਸੇ ਵਾਲੇ ਹਿੱਸੇ ਤੇਜ਼ੀ ਨਾਲ (ਅੈਡਮਿਨ UI, ਡੈਸ਼ਬੋਰਡ, ਕੰਟਰੋਲ ਪਲੇਨ) ਰੱਖੋ, ਜਦੋਂ ਕਿ ਕੋਰ ਸਿਸਟਮ ਲਾਜਿਕ ਨੂੰ ਕੜੀ ਅਨੁਸ਼ਾਸਨ ਨਾਲ ਰੱਖੋ। ਐਸੇ glue ਵਿਕਾਸ ਲਈ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਛੇਤੀ ਸਹਾਇਤਾ ਦੇ ਸਕਦੇ ਹਨ—ਚੈਟ-ਡ੍ਰਿਵਨ ਵਰਕਫਲੋ ਰਾਹੀਂ React ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ ਅਤੇ PostgreSQL schema ਤਿਆਰ ਕਰਨਾ ਤੇਜ਼ ਕਰਦੇ ਹਨ, ਫਿਰ source export ਕਰਕੇ ਆਪਣੇ Rust ਸੇਵਾ ਨਾਲ ਸਾਫ਼ ਬਾਊਂਡਰੀ 'ਤੇ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਦੂਜੀ ਪੋਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਭ ਤੋਂ ਮਦਦਗਾਰ ਕੀ ਹੋਵੇਗਾ?
ਆਪਣਾ ਸੰਦਰਭ ਭੇਜੋ (ਤੁਸੀਂ ਕੀ ਬਣਾਉਂਦੇ ਹੋ, ਹੁਣ ਕਿਹੜੀ ਭਾਸ਼ਾ ਵਰਤਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਕਿਸ ਗੱਲ ਲਈ optimize ਕਰ ਰਹੇ ਹੋ), ਮੈਂ ਅਗਲਾ ਭਾਗ ਉਸ ਮੁਤਾਬਕ ਤਿਆਰ ਕਰਾਂਗਾ।
ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਹ ਕੰਮ ਹੈ ਜੋ ਹਾਰਡਵੇਅਰ ਦੇ ਨੇੜੇ ਅਤੇ ਉਤਪਾਦ ਦੇ ਉੱਚ-ਖ਼ਤਰੇ ਵਾਲੇ ਹਿੱਸਿਆਂ 'ਤੇ ਹੋਦਾ ਹੈ—ਜਿਵੇਂ browser engines, ਡੇਟਾਬੇਸ, OS ਕੰਪੋਨੈਂਟ, ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ embedded ਸਾਫਟਵੇਅਰ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੇਡਿਕਟੇਬਲ ਪ੍ਰਦਰਸ਼ਨ, ਨੀਵ-ਸਤਰ ਦੀ ਮੈਮੋਰੀ/ਨਿਯੰਤਰਣ, ਅਤੇ ਉੱਚ ਭਰੋਸੇਯੋਗਤਾ ਮੰਗਦਾ ਹੈ, ਜਿੱਥੇ ਕਰੈਸ਼ਿੰਸ ਅਤੇ ਸੁਰੱਖਿਆ ਬੱਗ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ।
ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ Rust ਆਮ ਮੈਮੋਰੀ ਬੱਗ (ਜਿਵੇਂ use-after-free ਅਤੇ double-free) ਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਰਨਟਾਈਮ ਗਾਰਬੇਜ ਕਲੇਕਟਰ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ ਦੇ।
ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਦੇ ਬਦਲੇ, Rust ਕੰਪਾਇਲ ਸਮੇਂ 'ਤੇ ਕਈ ਸੁਰੱਖਿਆ ਚੇਕ ਕਰਵਾਉਂਦਾ ਹੈ—ਉਨ੍ਹਾ ਨੂੰ ownership ਅਤੇ borrowing ਨਿਯਮਾਂ ਰਾਹੀਂ ਪ੍ਰਭਾਵੀ ਬਣਾਉਂਦਾ ਹੈ।
ਸੰਸਥਾਵਿਕ ਸੰਦਾਂ ਜਿਵੇਂ sanitizers ਅਤੇ static analyzers ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਫੜ ਸਕਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਭਾਸ਼ਾ pointer ਅਤੇ lifetime ਪੈਟਰਨਾਂ ਨੂੰ ਆਜ਼ਾਦੀ ਨਾਲ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਸੰਦ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦੇ।
Rust ਜ਼ਰੂਰੀ ਨਿਯਮਾਂ ਨੂੰ ਭਾਸ਼ਾ ਅਤੇ ਟਾਈਪ ਸਿਸਟਮ ਵਿੱਚ ਸ਼ਾਮِل ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਕੰਪਾਇਲਰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਕਈ ਸ਼੍ਰੇਣੀਆਂ ਦੀਆਂ ਬੱਗਾਂ ਨੂੰ ਰੋਕ ਸਕੇ, ਫਿਰ ਵੀ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਖੁੱਲ੍ਹੇ ਰਾਹ (escape hatches) ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।
GC ਰਨਟਾਈਮ ਥੋੜ੍ਹਾ ਓਵਰਹੈੱਡ ਲਿਆਉਂਦੀ ਹੈ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਕੁਝ ਸਿਸਟਮ ਵਰਕਲੋਡਾਂ ਲਈ ਘੱਟ ਅਣਪਛਾਤੀ ਲੇਟੈਂਸੀ (ਜਿਵੇਂ ਰੁਕਾਵਟਾਂ ਜਾਂ ਗਾਰਬੇਜ ਵਰਕ) ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।
ਬ੍ਰਾਊਜ਼ਰਾਂ, ਰੀਅਲ-ਟਾਈਮ ਨਿਯੰਤਰਕਾਂ ਜਾਂ ਘੱਟ ਲੇਟੈਂਸੀ ਸਰਵਿਸਜ਼ ਵਰਗੀਆਂ ਡੋਮੇਨਾਂ ਵਿੱਚ worst-case ਵਿਹਾਰ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ Rust ਇਸੇ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਪਰ ਜ਼ਿਆਦਾ ਅਣਪਛਾਤੀ ਵਿਹਾਰ ਤੋਂ ਬਿਨਾਂ।
ਓਨਰਸ਼ਿਪ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਹਰ ਵੈਲਯੂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ “ਮਾਲਕ” ਹੁੰਦਾ ਹੈ ਜੋ ਉਹਦੇ ਖਤਮ ਹੋਣ 'ਤੇ ਉਸਨੂੰ ਸਾਫ਼ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਮਾਲਕ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਵੈਲਯੂ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਸ ਨਾਲ cleanup ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੂਰਨਭਰ ਨਹੀਂ ਰਹਿੰਦੀ ਅਤੇ ਦੋਹਰੇ-ਮਾਲਕ ਜਾਂ ਗਲਤ ਫ੍ਰੀ ਕਰਨ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਟਲ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ move ਉਹ ਵੈਲਯੂ ਇੱਕ ਵੈਰੀਏਬਲ ਤੋਂ ਦੂਜੇ ਵਾਰੀਏਬਲ ਨੂੰ ਹਵਾਲਾ ਕਰ ਦਿੰਦਾ ਹੈ; move ਦੇ ਬਾਅਦ ਪਹਿਲਾ ਵੈਰੀਏਬਲ ਉਸ ਵੈਲਯੂ ਨੂੰ ਵਰਤ ਨਹੀਂ ਸਕਦਾ।
ਇਸ ਤਰ੍ਹਾਂ ਇਹ ਅਕਸਰ
Borrowing ਨਾਲ ਕਿਸੇ ਵੈਲਯੂ ਦੀ ਅਸਥਾਈ ਵਰਤੋਂ ਲਈ reference ਮਿਲਦੀ ਹੈ ਬਿਨਾਂownership ਹਟਾਏ।
ਮੁੱਖ ਨਿਯਮ: ਬਹੁਤ ਸਾਰੇ ਪਾਠਕ (readers) ਜਾਂ ਇੱਕ ਲੇਖਕ (writer)—ਤੁਸੀਂ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਵਧੇਰੇ shared references (&T) ਰੱਖ ਸਕਦੇ ਹੋ ਜਾਂ ਇੱਕ mutable reference (&mut T), ਪਰ ਦੋਹਾਂ ਇਕੱਠੇ ਨਹੀਂ। ਇਹ mutation-while-reading ਅਤੇ aliasing ਦੀਆਂ ਅਕਸਰ ਆਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਲਾਈਫਟਾਈਮ ਦਾ ਮਤਲਬ ਹੈ ਕਿ reference ਕਿੰਨੀ ਦੇਰ ਲਈ ਵੈਧ ਹੈ। Rust ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਕੋਈ ਵੀ reference ਉਸ ਡੇਟਾ ਤੋਂ ਬਾਅਦ ਨਹੀਂ ਰਿਹੇ ਜਿਸ ਤੇ ਉਹ ਨਿਰਭਰ ਹੁੰਦੀ ਹੈ।
borrow checker ਕੰਪਾਇਲ ਸਮੇਂ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ dangling references ਨਿਰਯਾਤ (reject) ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਪਹਿਲਾਂ ਕਿ ਕੋਡ ਚਲੇ।
ਡੇਟਾ ਰੇਸ ਉਸ ਸਮੇਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕਈ ਹੋਰ ਥ੍ਰੈਡ ਇੱਕੋ ਹੀ ਮੈਮੋਰੀ ਨੂੰ ਇਕੱਠੇ ਪਹੁੰਚਦੇ ਹਨ, ਘੱਟੋ-ਘੱਟ ਇੱਕ ਲਿਖਦਾ ਹੋਵੇ, ਅਤੇ ਕੋਈ ਸਮਨਵਯ (ਜਿਵੇਂ ਲਾਕ) ਨਾ ਹੋਵੇ।
Rust ਦੇ ownership/borrowing ਨਿਯਮ concurrency 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਬੇਸਮਝੀ ਵਾਲੇ ਸ਼ੇਅਰਿੰਗ ਪੈਟਰਨ safe ਕੋਡ ਵਿੱਚ ਅਭਿਵਿਆਕਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਜਾਂ نامੰਮਕ ਹੁੰਦਾ ਹੈ—ਜਿਸ ਨਾਲ ਤੁਸੀਂ واضح synchronization ਜਾਂ message passing ਪੱਕਾ ਕਰਦੇ ਹੋ।
ਅਧਿਕਤਰ ਕੋਡ safe Rust ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਕੰਪਾਇਲਰ ਉਹ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜੋ ਆਮ ਮੈਮੋਰੀ ਬੱਗਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ।
unsafe ਇੱਕ ਖੁੱਲ੍ਹਾ ਰਾਹ ਹੈ ਜਿੰਨ੍ਹਾਂ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਕੰਪਾਇਲਰ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ—ਜਿਵੇਂ FFI ਕੋਲ ਕਾਲਾਂ ਜਾਂ ਕੁਝ ਨੀਵ-ਸਤਰੀ ਤੇਜ਼ਤਾ-ਲੋੜੀਂਦੇ ਕੇਸ।
unsafe ਬਲੌਕ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਥਾਨਕ ਰੱਖਣਾ, ਸਪਸ਼ਟ ਟਿੱਪਣੀਆਂ ਦੇਣਾ ਅਤੇ ਵਾਧੂ ਰਿਵਿਊ/ਟੈਸਟਿੰਗ ਲਾਗੂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਜੋ ਵੀ ਜੋਖਮ ਹੁੰਦਾ ਹੈ ਉਹ ਅਪਣੇ ਹਦ ਤੱਕ ਨਿੱਜੀ ਰੂਪ ਵਿੱਚ ਕਰਾਏ ਜਾ ਸਕੇ।