ಈ ಹಿಂದೆ ಪ್ರಕಟವಾದ ಲೇಖನಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಲೇಖನವನ್ನು ಬರೆಯಲಾಗಿದೆ ಆಂಟಿಪೋಡಿಯನ್ ಲೇಖನ.

ಕಳೆದ ಎರಡು-ಪ್ಲಸ್ ವರ್ಷಗಳಲ್ಲಿ ನಾನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಬಿಲ್ಲಿಂಗ್ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ವಿಶೇಷ RADIUS ಸರ್ವರ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು Go ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇನೆ. ದಾರಿಯುದ್ದಕ್ಕೂ, ನಾನು ಭಾಷೆಯ ಜಟಿಲತೆಗಳನ್ನು ಕಲಿಯುತ್ತಿದ್ದೇನೆ. ಕಾರ್ಯಕ್ರಮಗಳು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ಈ ಲೇಖನದ ಉದ್ದೇಶವಲ್ಲ, ಆದರೆ ಗೋ ಬಳಸುವ ಅನುಭವವು ಅದರ ರಕ್ಷಣೆಯಲ್ಲಿ ಕೆಲವು ಪದಗಳಿಗೆ ಅರ್ಹವಾಗಿದೆ. ಗಂಭೀರವಾದ, ಸ್ಕೇಲೆಬಲ್ ಕೋಡ್‌ಗಾಗಿ ಗೋ ಹೆಚ್ಚು ಮುಖ್ಯವಾಹಿನಿಯ ಭಾಷೆಯಾಗುತ್ತಿದೆ. ಭಾಷೆಯನ್ನು Google ನಿಂದ ರಚಿಸಲಾಗಿದೆ, ಅಲ್ಲಿ ಅದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಬಾಟಮ್ ಲೈನ್, UNintelligent ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಗೆ ಗೋ ಭಾಷೆಯ ವಿನ್ಯಾಸವು ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ನಾನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಭಾವಿಸುತ್ತೇನೆ.

ದುರ್ಬಲ ಪ್ರೋಗ್ರಾಮರ್ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆಯೇ?

ದುರ್ಬಲರು ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಾರೆ. ಕಲ್ಪನೆಗಳು ಮತ್ತು ಕನಸುಗಳ ಬಗ್ಗೆ ಬಲವಾದ ಚರ್ಚೆ ...

ಗೋ ಕಲಿಯಲು ತುಂಬಾ ಸುಲಭ, ಆದ್ದರಿಂದ ನೀವು ಯಾವುದೇ ತರಬೇತಿಯಿಲ್ಲದೆ ಕೋಡ್ ಅನ್ನು ಓದಬಹುದು. ಕೋರ್ ಅಲ್ಲದ ತಜ್ಞರು (ವ್ಯವಸ್ಥಾಪಕರು, ಗ್ರಾಹಕರು, ಇತ್ಯಾದಿ) ಜೊತೆಗೆ ಕೋಡ್ ಅನ್ನು ಓದಿದಾಗ ಭಾಷೆಯ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅನೇಕ ಜಾಗತಿಕ ಕಂಪನಿಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ವಿನ್ಯಾಸ ಚಾಲಿತ ಅಭಿವೃದ್ಧಿಯಂತಹ ವಿಧಾನಗಳಿಗೆ ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ.
ಅನನುಭವಿ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಸಹ ಒಂದು ವಾರ ಅಥವಾ ಎರಡು ನಂತರ ಸಾಕಷ್ಟು ಯೋಗ್ಯವಾದ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ನಾನು ಅಧ್ಯಯನ ಮಾಡಿದ ಪುಸ್ತಕ "ಗೋ ಪ್ರೋಗ್ರಾಮಿಂಗ್" (ಮಾರ್ಕ್ ಸಮ್ಮರ್‌ಫೀಲ್ಡ್ ಅವರಿಂದ). ಪುಸ್ತಕವು ತುಂಬಾ ಚೆನ್ನಾಗಿದೆ, ಇದು ಭಾಷೆಯ ಅನೇಕ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ. ಜಾವಾ, ಪಿಎಚ್‌ಪಿಯಂತಹ ಅನಗತ್ಯ ಸಂಕೀರ್ಣ ಭಾಷೆಗಳ ನಂತರ, ಮ್ಯಾಜಿಕ್‌ನ ಕೊರತೆಯು ರಿಫ್ರೆಶ್ ಆಗಿದೆ. ಆದರೆ ಬೇಗ ಅಥವಾ ನಂತರ, ಅನೇಕ ಸೀಮಿತ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಹೊಸ ಕ್ಷೇತ್ರದಲ್ಲಿ ಹಳೆಯ ವಿಧಾನಗಳನ್ನು ಬಳಸುವ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆಯೇ?

ರಾಬ್ ಪೈಕ್ (ಭಾಷೆಯ ಮುಖ್ಯ ವಿಚಾರವಾದಿ) ಗೋ ಭಾಷೆಯನ್ನು ಕೈಗಾರಿಕಾ ಭಾಷೆಯಾಗಿ ರಚಿಸಿದರು, ಅದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭ ಮತ್ತು ಬಳಸಲು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ದೊಡ್ಡ ತಂಡಗಳಲ್ಲಿ ಗರಿಷ್ಠ ಉತ್ಪಾದಕತೆಗಾಗಿ ಭಾಷೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಯಾವುದೇ ಸಂದೇಹವಿಲ್ಲ. ಅನೇಕ ಅನನುಭವಿ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಅವರು ಕಾಣೆಯಾಗಿರುವ ಹಲವು ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ ಎಂದು ದೂರುತ್ತಾರೆ. ಸರಳತೆಯ ಈ ಬಯಕೆಯು ಭಾಷೆಯ ವಿನ್ಯಾಸಕಾರರ ಪ್ರಜ್ಞಾಪೂರ್ವಕ ನಿರ್ಧಾರವಾಗಿತ್ತು ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು ಎಂಬುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಡೆವಲಪರ್‌ಗಳ ಪ್ರೇರಣೆ ಮತ್ತು ಅವರು ಗೋದಲ್ಲಿ ಏನನ್ನು ಸಾಧಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

ಹಾಗಾದರೆ ಅದನ್ನು ಏಕೆ ಸರಳಗೊಳಿಸಲಾಯಿತು? ರಾಬ್ ಪೈಕ್ ಅವರ ಕೆಲವು ಉಲ್ಲೇಖಗಳು ಇಲ್ಲಿವೆ:

ಇಲ್ಲಿ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ನಮ್ಮ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಸಂಶೋಧಕರಲ್ಲ. ಅವರು ನಿಯಮದಂತೆ, ಸಾಕಷ್ಟು ಚಿಕ್ಕವರು, ಅಧ್ಯಯನ ಮಾಡಿದ ನಂತರ ನಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತಾರೆ, ಬಹುಶಃ ಅವರು ಜಾವಾ, ಅಥವಾ C/C++, ಅಥವಾ ಪೈಥಾನ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದ್ದಾರೆ. ಅವರು ಉತ್ತಮ ಭಾಷೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಅವರು ಉತ್ತಮ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ರಚಿಸಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಅದಕ್ಕಾಗಿಯೇ ಭಾಷೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಕಲಿಯಲು ಸುಲಭವಾಗಿರಬೇಕು.

ಅವರು ಪರಿಚಿತರಾಗಿರಬೇಕು, ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ ಸಿ. Google ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ತಮ್ಮ ವೃತ್ತಿಜೀವನವನ್ನು ಮೊದಲೇ ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಕಾರ್ಯವಿಧಾನದ ಭಾಷೆಗಳೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದಾರೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ C ಕುಟುಂಬ. ಹೊಸ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ ತ್ವರಿತ ಉತ್ಪಾದಕತೆಯ ಅವಶ್ಯಕತೆ ಎಂದರೆ ಭಾಷೆ ತುಂಬಾ ಆಮೂಲಾಗ್ರವಾಗಿರಬಾರದು.

ಬುದ್ಧಿವಂತ ಪದಗಳು, ಅಲ್ಲವೇ?

ಸರಳತೆಯ ಕಲಾಕೃತಿಗಳು

ಸೌಂದರ್ಯಕ್ಕೆ ಸರಳತೆಯು ಅಗತ್ಯವಾದ ಸ್ಥಿತಿಯಾಗಿದೆ. ಲೆವ್ ಟಾಲ್ಸ್ಟಾಯ್.

ಯಾವುದೇ ವಿನ್ಯಾಸದಲ್ಲಿ ಅದನ್ನು ಸರಳವಾಗಿ ಇಡುವುದು ಪ್ರಮುಖ ಗುರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಪರಿಪೂರ್ಣ ಯೋಜನೆಯು ಸೇರಿಸಲು ಏನೂ ಇಲ್ಲದಿರುವ ಯೋಜನೆಯಲ್ಲ, ಆದರೆ ತೆಗೆದುಹಾಕಲು ಏನೂ ಇಲ್ಲ. ಸಂಕೀರ್ಣ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು (ಅಥವಾ ವ್ಯಕ್ತಪಡಿಸಲು) ಸಂಕೀರ್ಣ ಸಾಧನದ ಅಗತ್ಯವಿದೆ ಎಂದು ಅನೇಕ ಜನರು ನಂಬುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ಇದು ಅಲ್ಲ. ಉದಾಹರಣೆಗೆ PERL ಭಾಷೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರೋಗ್ರಾಮರ್ ಕನಿಷ್ಠ ಮೂರು ವಿಭಿನ್ನ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಎಂದು ಭಾಷಾ ವಿಚಾರವಾದಿಗಳು ನಂಬಿದ್ದರು. ಗೋ ಭಾಷೆಯ ವಿಚಾರವಾದಿಗಳು ವಿಭಿನ್ನ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡರು; ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ಒಂದು ಮಾರ್ಗ, ಆದರೆ ನಿಜವಾಗಿಯೂ ಒಳ್ಳೆಯದು ಎಂದು ಅವರು ನಿರ್ಧರಿಸಿದರು. ಈ ವಿಧಾನವು ಗಂಭೀರವಾದ ಅಡಿಪಾಯವನ್ನು ಹೊಂದಿದೆ: ಕಲಿಯಲು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ ಮತ್ತು ಮರೆಯಲು ಕಷ್ಟವಾಗುತ್ತದೆ.

ಭಾಷೆಯು ಸೊಗಸಾದ ಅಮೂರ್ತತೆಯನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ಅನೇಕ ವಲಸಿಗರು ದೂರುತ್ತಾರೆ. ಹೌದು, ಇದು ನಿಜ, ಆದರೆ ಇದು ಭಾಷೆಯ ಮುಖ್ಯ ಅನುಕೂಲಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಭಾಷೆಯು ಕನಿಷ್ಟ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ - ಆದ್ದರಿಂದ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಓದಲು ಯಾವುದೇ ಆಳವಾದ ಜ್ಞಾನದ ಅಗತ್ಯವಿಲ್ಲ. ಕೋಡ್‌ನ ಮೌಖಿಕತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ಯಾವುದೇ ಸಮಸ್ಯೆಯಲ್ಲ. ಚೆನ್ನಾಗಿ ಬರೆಯಲಾದ ಗೋಲಾಂಗ್ ಪ್ರೋಗ್ರಾಂ ಸ್ವಲ್ಪ ಅಥವಾ ಯಾವುದೇ ರಚನೆಯೊಂದಿಗೆ ಲಂಬವಾಗಿ ಓದುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಓದುವ ವೇಗವು ಅದನ್ನು ಬರೆಯುವ ವೇಗಕ್ಕಿಂತ ಕನಿಷ್ಠ ಪ್ರಮಾಣದ ಕ್ರಮವಾಗಿದೆ. ಎಲ್ಲಾ ಕೋಡ್ ಏಕರೂಪದ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂದು ನೀವು ಪರಿಗಣಿಸಿದರೆ (ಅಂತರ್ನಿರ್ಮಿತ gofmt ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ ಮಾಡಲಾಗುತ್ತದೆ), ನಂತರ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಸಾಲುಗಳನ್ನು ಓದುವುದು ಸಮಸ್ಯೆಯಲ್ಲ.

ತುಂಬಾ ಅಭಿವ್ಯಕ್ತವಾಗಿಲ್ಲ

ಕಲೆ ತನ್ನ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ನಿರ್ಬಂಧಿಸಿದಾಗ ಅದನ್ನು ಸಹಿಸುವುದಿಲ್ಲ. ನಿಖರತೆ ಅವನ ಜವಾಬ್ದಾರಿಯಲ್ಲ.

ಸರಳತೆಯ ಬಯಕೆಯಿಂದಾಗಿ, ಇತರ ಭಾಷೆಗಳಲ್ಲಿ ಅವರಿಗೆ ಒಗ್ಗಿಕೊಂಡಿರುವ ಜನರು ನೈಸರ್ಗಿಕವಾಗಿ ಗ್ರಹಿಸುವ ರಚನೆಗಳನ್ನು ಗೋ ಹೊಂದಿಲ್ಲ. ಮೊದಲಿಗೆ ಇದು ಸ್ವಲ್ಪ ಅನಾನುಕೂಲವಾಗಬಹುದು, ಆದರೆ ನಂತರ ಪ್ರೋಗ್ರಾಂ ಓದಲು ಹೆಚ್ಚು ಸುಲಭ ಮತ್ತು ಹೆಚ್ಚು ನಿಸ್ಸಂದಿಗ್ಧವಾಗಿದೆ ಎಂದು ನೀವು ಗಮನಿಸಬಹುದು.

ಉದಾಹರಣೆಗೆ, stdin ಅಥವಾ ಆಜ್ಞಾ ಸಾಲಿನ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳಿಂದ ಫೈಲ್ ಅನ್ನು ಓದುವ ಕನ್ಸೋಲ್ ಉಪಯುಕ್ತತೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

    var text string
    for scanner.Scan() {
        text += scanner.Text()
    }

    if err := scanner.Err(); err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

    file, err := os.Open(flags[0])

    if err != nil {
        log.Fatal(err)
    }

    return bufio.NewScanner(file)
}

ಡಿ ಯಲ್ಲಿ ಅದೇ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವು ಸ್ವಲ್ಪ ಚಿಕ್ಕದಾಗಿ ಕಂಡರೂ ಓದಲು ಸುಲಭವಲ್ಲ

import std.stdio, std.array, std.conv;

void main(string[] args)
{
    try
    {
        auto source = args.length > 1 ? File(args[1], "r") : stdin;
        auto text   = source.byLine.join.to!(string);

        writeln(text);
    }
    catch (Exception ex)
    {
        writeln(ex.msg);
    }
}

ನಕಲು ಮಾಡುವುದು ನರಕ

ಮನುಷ್ಯ ತನ್ನೊಳಗೆ ನರಕವನ್ನು ಹೊತ್ತಿದ್ದಾನೆ. ಮಾರ್ಟಿನ್ ಲೂಥರ್.

ಜೆನೆರಿಕ್ಸ್ ಕೊರತೆಯ ವಿಷಯದಲ್ಲಿ ಬಿಗಿನರ್ಸ್ ನಿರಂತರವಾಗಿ ಗೋ ಬಗ್ಗೆ ದೂರು ನೀಡುತ್ತಾರೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಹೆಚ್ಚಿನವರು ನೇರ ಕೋಡ್ ನಕಲು ಬಳಸುತ್ತಾರೆ. ಉದಾಹರಣೆಗೆ, ಪೂರ್ಣಾಂಕಗಳ ಪಟ್ಟಿಯನ್ನು ಒಟ್ಟುಗೂಡಿಸುವ ಕಾರ್ಯ, ಪ್ರತಿ ಡೇಟಾ ಪ್ರಕಾರಕ್ಕೆ ಸರಳವಾದ ನಕಲು-ಅಂಟಿಸುವ ಮೂಲಕ ಕಾರ್ಯವನ್ನು ಬೇರೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ವೃತ್ತಿಪರರು ನಂಬುತ್ತಾರೆ.

package main

import "fmt"

func int64Sum(list []int64) (uint64) {
    var result int64 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int32Sum(list []int32) (uint64) {
    var result int32 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

ಅಂತಹ ನಿರ್ಮಾಣಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಭಾಷೆ ಸಾಕಷ್ಟು ಸಾಧನಗಳನ್ನು ಹೊಂದಿದೆ. ಉದಾಹರಣೆಗೆ, ಜೆನೆರಿಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಉತ್ತಮವಾಗಿರುತ್ತದೆ.

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

ಮತ್ತು, ನಮ್ಮ ಕೋಡ್ ಹಿಂದಿನ ಪ್ರಕರಣಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಉದ್ದವಾಗಿದೆ ಎಂದು ಕಂಡುಬಂದರೂ, ಅದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಎಲ್ಲಾ ಅಂಕಗಣಿತದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಮಗೆ ಕಷ್ಟವಾಗುವುದಿಲ್ಲ.

D ಯಲ್ಲಿನ ಪ್ರೋಗ್ರಾಂ ಗಮನಾರ್ಹವಾಗಿ ಚಿಕ್ಕದಾಗಿ ಕಾಣುತ್ತದೆ ಎಂದು ಹಲವರು ಹೇಳುತ್ತಾರೆ, ಮತ್ತು ಅವರು ಸರಿಯಾಗಿರುತ್ತಾರೆ.

import std.stdio;
import std.algorithm;

void main(string[] args)
{
    [1, 2, 3, 4, 5].reduce!((a, b) => a + b).writeln;
}

ಆದಾಗ್ಯೂ, ಇದು ಕೇವಲ ಚಿಕ್ಕದಾಗಿದೆ, ಆದರೆ ಹೆಚ್ಚು ಸರಿಯಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಡಿ ಅನುಷ್ಠಾನವು ದೋಷ ನಿರ್ವಹಣೆಯ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ.

ನಿಜ ಜೀವನದಲ್ಲಿ, ತರ್ಕದ ಸಂಕೀರ್ಣತೆ ಹೆಚ್ಚಾದಂತೆ, ಅಂತರವು ವೇಗವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಪ್ರಮಾಣಿತ ಭಾಷಾ ಆಪರೇಟರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ವಹಿಸಲಾಗದ ಕ್ರಿಯೆಯನ್ನು ನೀವು ನಿರ್ವಹಿಸಬೇಕಾದಾಗ ಅಂತರವು ಇನ್ನಷ್ಟು ವೇಗವಾಗಿ ಮುಚ್ಚುತ್ತದೆ.

ನಿರ್ವಹಣೆ, ವಿಸ್ತರಣೆ ಮತ್ತು ಓದುವಿಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಗೋ ಭಾಷೆ ಗೆಲ್ಲುತ್ತದೆ, ಆದರೂ ಅದು ಮಾತಿನಲ್ಲಿ ಸೋತಿದೆ.

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ನಮಗೆ ನಿರಾಕರಿಸಲಾಗದ ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆ. ವಿಂಗಡಣೆಯ ಪ್ಯಾಕೇಜ್‌ನಿಂದ ಇದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ಯಾವುದೇ ಪಟ್ಟಿಯನ್ನು ವಿಂಗಡಿಸಲು, ನಾವು ಕೇವಲ sort.Interface ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ.

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

ನೀವು ಯಾವುದೇ ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ ಮತ್ತು grep “interface{}” -R ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿದರೆ, ಎಷ್ಟು ಬಾರಿ ಗೊಂದಲಮಯ ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ. ನಿಕಟ ಮನಸ್ಸಿನ ಒಡನಾಡಿಗಳು ಇದೆಲ್ಲವೂ ಜೆನೆರಿಕ್ ಕೊರತೆಯಿಂದ ಎಂದು ತಕ್ಷಣವೇ ಹೇಳುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ಇದು ಯಾವಾಗಲೂ ಅಲ್ಲ. DELPHI ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ. ಇದೇ ಜೆನೆರಿಕ್‌ಗಳ ಉಪಸ್ಥಿತಿಯ ಹೊರತಾಗಿಯೂ, ಇದು ಅನಿಯಂತ್ರಿತ ಡೇಟಾ ಪ್ರಕಾರಗಳೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ವಿಶೇಷ VARIANT ಪ್ರಕಾರವನ್ನು ಒಳಗೊಂಡಿದೆ. ಗೋ ಭಾಷೆಯೂ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ.

ಫಿರಂಗಿಯಿಂದ ಗುಬ್ಬಚ್ಚಿಗಳವರೆಗೆ

ಮತ್ತು ಸ್ಟ್ರೈಟ್ಜಾಕೆಟ್ ಹುಚ್ಚುತನದ ಗಾತ್ರಕ್ಕೆ ಸರಿಹೊಂದಬೇಕು. ಸ್ಟಾನಿಸ್ಲಾವ್ ಲೆಕ್.

ಜೆನೆರಿಕ್ಸ್ ಅನ್ನು ರಚಿಸಲು ಗೋ ಮತ್ತೊಂದು ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೊಂದಿದೆ ಎಂದು ಅನೇಕ ವಿಪರೀತ ಅಭಿಮಾನಿಗಳು ಹೇಳಿಕೊಳ್ಳಬಹುದು - ಪ್ರತಿಫಲನ. ಮತ್ತು ಅವರು ಸರಿಯಾಗಿರುತ್ತಾರೆ ... ಆದರೆ ಅಪರೂಪದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮಾತ್ರ.

ರಾಬ್ ಪೈಕ್ ನಮಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತಾರೆ:

ಇದು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿದ್ದು ಅದನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಬೇಕು. ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ತಪ್ಪಿಸಬೇಕು.

ವಿಕಿಪೀಡಿಯಾ ನಮಗೆ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಹೇಳುತ್ತದೆ:

ಪ್ರತಿಬಿಂಬವು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯದಲ್ಲಿ ಪ್ರೋಗ್ರಾಂ ತನ್ನದೇ ಆದ ರಚನೆ ಮತ್ತು ನಡವಳಿಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮತ್ತು ಮಾರ್ಪಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರತಿಬಿಂಬದ ಆಧಾರವಾಗಿರುವ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾದರಿಯನ್ನು ಪ್ರತಿಫಲಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಒಂದು ರೀತಿಯ ಮೆಟಾಪ್ರೋಗ್ರಾಮಿಂಗ್ ಆಗಿದೆ.

ಆದಾಗ್ಯೂ, ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ನೀವು ಎಲ್ಲದಕ್ಕೂ ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಇದು:

• ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಬರೆಯುವಲ್ಲಿ ತೊಂದರೆ
• ಪ್ರೋಗ್ರಾಂ ಕಾರ್ಯಗತಗೊಳಿಸುವ ವೇಗ

ಆದ್ದರಿಂದ, ಪ್ರತಿಬಿಂಬವನ್ನು ದೊಡ್ಡ-ಕ್ಯಾಲಿಬರ್ ಆಯುಧದಂತೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಬೇಕು. ಪ್ರತಿಬಿಂಬದ ಚಿಂತನೆಯಿಲ್ಲದ ಬಳಕೆಯು ಓದಲಾಗದ ಪ್ರೋಗ್ರಾಂಗಳು, ನಿರಂತರ ದೋಷಗಳು ಮತ್ತು ಕಡಿಮೆ ವೇಗಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಸ್ನೋಬ್ ಪ್ರೋಗ್ರಾಮರ್ ತನ್ನ ಕೋಡ್ ಅನ್ನು ಇತರ, ಹೆಚ್ಚು ಪ್ರಾಯೋಗಿಕ ಮತ್ತು ಸಾಧಾರಣ ಸಹೋದ್ಯೋಗಿಗಳ ಮುಂದೆ ಪ್ರದರ್ಶಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

Xi ನಿಂದ ಸಾಂಸ್ಕೃತಿಕ ಸಾಮಾನು? ಇಲ್ಲ, ಹಲವಾರು ಭಾಷೆಗಳಿಂದ!

ಅದೃಷ್ಟದ ಜತೆಗೆ ಸಾಲವೂ ವಾರಸುದಾರರಿಗೆ ಬಿಟ್ಟಿದೆ.

ಭಾಷೆ ಸಂಪೂರ್ಣವಾಗಿ ಸಿ ಪರಂಪರೆಯನ್ನು ಆಧರಿಸಿದೆ ಎಂದು ಹಲವರು ನಂಬುತ್ತಾರೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಇದು ಹಾಗಲ್ಲ. ಭಾಷೆಯು ಅತ್ಯುತ್ತಮ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳ ಹಲವು ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ವಾಕ್ಯ

ಮೊದಲನೆಯದಾಗಿ, ವ್ಯಾಕರಣ ರಚನೆಗಳ ಸಿಂಟ್ಯಾಕ್ಸ್ ಸಿ ಭಾಷೆಯ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ಆದಾಗ್ಯೂ, DELPHI ಭಾಷೆಯು ಗಮನಾರ್ಹ ಪ್ರಭಾವವನ್ನು ಹೊಂದಿತ್ತು. ಹೀಗಾಗಿ, ಪ್ರೋಗ್ರಾಂನ ಓದುವಿಕೆಯನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡುವ ಅನಗತ್ಯ ಆವರಣಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಭಾಷೆಯು DELPHI ಭಾಷೆಗೆ ಅಂತರ್ಗತವಾಗಿರುವ “:=” ಆಪರೇಟರ್ ಅನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ. ಪ್ಯಾಕೇಜ್‌ಗಳ ಪರಿಕಲ್ಪನೆಯನ್ನು ADA ಯಂತಹ ಭಾಷೆಗಳಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ. ಬಳಕೆಯಾಗದ ಘಟಕಗಳ ಘೋಷಣೆಯನ್ನು PROLOG ಭಾಷೆಯಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ.

ಶಬ್ದಾರ್ಥ

ಪ್ಯಾಕೇಜುಗಳು DELPHI ಭಾಷೆಯ ಶಬ್ದಾರ್ಥವನ್ನು ಆಧರಿಸಿವೆ. ಪ್ರತಿಯೊಂದು ಪ್ಯಾಕೇಜ್ ಡೇಟಾ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ ಮತ್ತು ಖಾಸಗಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಘಟಕಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಪ್ಯಾಕೇಜ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕನಿಷ್ಠಕ್ಕೆ ಕಡಿಮೆ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ನಿಯೋಗ ವಿಧಾನದ ಮೂಲಕ ಅನುಷ್ಠಾನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು DELPHI ಭಾಷೆಯಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ.

ಸಂಕಲನ

ಒಂದು ತಮಾಷೆ ಇದೆ ಎಂದು ಕಾರಣವಿಲ್ಲದೆ ಅಲ್ಲ: ಸಿ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಸಂಕಲಿಸುವಾಗ ಗೋ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ. ಭಾಷೆಯ ಶಕ್ತಿಗಳಲ್ಲಿ ಒಂದು ಅದರ ಅತಿ ವೇಗದ ಸಂಕಲನವಾಗಿದೆ. ಕಲ್ಪನೆಯನ್ನು ಡೆಲ್ಫಿ ಭಾಷೆಯಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ. ಪ್ರತಿಯೊಂದು Go ಪ್ಯಾಕೇಜ್ DELPHI ಮಾಡ್ಯೂಲ್‌ಗೆ ಅನುರೂಪವಾಗಿದೆ. ಈ ಪ್ಯಾಕೇಜುಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಮರುಸಂಕಲಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಮುಂದಿನ ಸಂಪಾದನೆಯ ನಂತರ, ನೀವು ಸಂಪೂರ್ಣ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಬದಲಿಗೆ ಈ ಬದಲಾದ ಪ್ಯಾಕೇಜುಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಬದಲಾದ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ಪ್ಯಾಕೇಜುಗಳನ್ನು ಮಾತ್ರ ಮರುಸಂಕಲಿಸಿ (ಮತ್ತು ನಂತರವೂ ಸಹ, ಪ್ಯಾಕೇಜ್ ಇಂಟರ್ಫೇಸ್ಗಳು ಬದಲಾಗಿದ್ದರೆ ಮಾತ್ರ).

ಉನ್ನತ ಮಟ್ಟದ ರಚನೆಗಳು

ಭಾಷೆಯು ಅನೇಕ ವಿಭಿನ್ನ ಉನ್ನತ ಮಟ್ಟದ ರಚನೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಅದು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸಿ ನಂತಹ ಕಡಿಮೆ-ಮಟ್ಟದ ಭಾಷೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ.

• ತಂತಿಗಳು
• ಹ್ಯಾಶ್ ಕೋಷ್ಟಕಗಳು
• ಚೂರುಗಳು
• ಡಕ್ ಟೈಪಿಂಗ್ ಅನ್ನು RUBY ನಂತಹ ಭಾಷೆಗಳಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ (ದುರದೃಷ್ಟವಶಾತ್, ಅನೇಕರು ಅದರ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಅಥವಾ ಬಳಸುವುದಿಲ್ಲ).

ಮೆಮೊರಿ ನಿರ್ವಹಣೆ

ಮೆಮೊರಿ ನಿರ್ವಹಣೆ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತ್ಯೇಕ ಲೇಖನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ. C++ ನಂತಹ ಭಾಷೆಗಳಲ್ಲಿ, ನಿಯಂತ್ರಣವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಡೆವಲಪರ್‌ಗೆ ಬಿಟ್ಟರೆ, ನಂತರ DELPHI ನಂತಹ ಭಾಷೆಗಳಲ್ಲಿ, ಉಲ್ಲೇಖ ಎಣಿಕೆಯ ಮಾದರಿಯನ್ನು ಬಳಸಲಾಯಿತು. ಈ ವಿಧಾನದೊಂದಿಗೆ, ಆವರ್ತಕ ಉಲ್ಲೇಖಗಳನ್ನು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅನಾಥ ಸಮೂಹಗಳು ರೂಪುಗೊಂಡವು, ನಂತರ ಅಂತಹ ಸಮೂಹಗಳ (C# ನಂತಹ) ಅಂತರ್ನಿರ್ಮಿತ ಪತ್ತೆಯನ್ನು Go ಹೊಂದಿದೆ. ಇದರ ಜೊತೆಗೆ, ಕಸ ಸಂಗ್ರಾಹಕವು ಪ್ರಸ್ತುತ ತಿಳಿದಿರುವ ಅಳವಡಿಕೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಈಗಾಗಲೇ ಅನೇಕ ನೈಜ-ಸಮಯದ ಕಾರ್ಯಗಳಿಗೆ ಬಳಸಬಹುದು. ವೇರಿಯೇಬಲ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಮೌಲ್ಯವನ್ನು ಸ್ಟಾಕ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಿದಾಗ ಭಾಷೆಯು ಸಂದರ್ಭಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಇದು ಮೆಮೊರಿ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರೋಗ್ರಾಂನ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಏಕಕಾಲಿಕತೆ ಮತ್ತು ಸಮನ್ವಯತೆ

ಭಾಷೆಯ ಸಮಾನಾಂತರತೆ ಮತ್ತು ಸ್ಪರ್ಧಾತ್ಮಕತೆ ಪ್ರಶಂಸೆಗೆ ಮೀರಿದೆ. ಯಾವುದೇ ಕೀಳು ಮಟ್ಟದ ಭಾಷೆಯು ದೂರದಿಂದಲೂ Go ನೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನ್ಯಾಯೋಚಿತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಮಾದರಿಯನ್ನು ಭಾಷೆಯ ಲೇಖಕರು ಕಂಡುಹಿಡಿದಿಲ್ಲ, ಆದರೆ ಉತ್ತಮ ಹಳೆಯ ಎಡಿಎ ಭಾಷೆಯಿಂದ ಸರಳವಾಗಿ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ ಎಂದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ. ಬಹು-ಥ್ರೆಡ್ ಕೋಡ್‌ಗೆ ವಿಶಿಷ್ಟವಾದ ಡೆಡ್‌ಲಾಕ್‌ಗಳು ಮತ್ತು ರೇಸ್ ಪರಿಸ್ಥಿತಿಗಳೊಂದಿಗೆ ಕಡಿಮೆ ಸಂಕೀರ್ಣ ಸಮಸ್ಯೆಗಳ ಕ್ರಮವನ್ನು ಹೊಂದಿರುವಾಗ, ಎಲ್ಲಾ CPU ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಲಕ್ಷಾಂತರ ಸಮಾನಾಂತರ ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಭಾಷೆ ಸಮರ್ಥವಾಗಿದೆ.

ಹೆಚ್ಚುವರಿ ಪ್ರಯೋಜನಗಳು

ಅದು ಲಾಭದಾಯಕವಾಗಿದ್ದರೆ, ಎಲ್ಲರೂ ನಿಸ್ವಾರ್ಥರಾಗುತ್ತಾರೆ.

ಭಾಷೆಯು ನಮಗೆ ಹಲವಾರು ನಿಸ್ಸಂದೇಹವಾದ ಪ್ರಯೋಜನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ:

• ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಿದ ನಂತರ ಒಂದೇ ಎಕ್ಸಿಕ್ಯೂಟಬಲ್ ಫೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಿಯೋಜನೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.
• ಸ್ಟ್ಯಾಟಿಕ್ ಟೈಪಿಂಗ್ ಮತ್ತು ಟೈಪ್ ಇನ್ಫರೆನ್ಸ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯದೆಯೇ ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿನ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯದೆಯೇ ಮಾಡುವ ಕೆಲವು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ನನಗೆ ಗೊತ್ತು ಮತ್ತು ಅವರ ಕೋಡ್‌ನ ಗುಣಮಟ್ಟವು ಗಮನಾರ್ಹವಾಗಿ ಬಳಲುತ್ತಿಲ್ಲ.
• ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೈಬ್ರರಿಯ ಅತ್ಯಂತ ಸರಳವಾದ ಅಡ್ಡ-ಸಂಕಲನ ಮತ್ತು ಅತ್ಯುತ್ತಮ ಪೋರ್ಟಬಿಲಿಟಿ, ಇದು ಕ್ರಾಸ್-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.
• RE2 ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಗಳು ಥ್ರೆಡ್-ಸುರಕ್ಷಿತವಾಗಿರುತ್ತವೆ ಮತ್ತು ಊಹಿಸಬಹುದಾದ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ.
• ಥರ್ಡ್-ಪಾರ್ಟಿ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಿಲ್ಲದೆ ಹೆಚ್ಚಿನ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಮಾಡಲು ಅನುಮತಿಸುವ ಪ್ರಬಲ ಗುಣಮಟ್ಟದ ಲೈಬ್ರರಿ.
• ಭಾಷೆಯು ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬೇಕೆಂಬುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಅದನ್ನು ಕೇಂದ್ರೀಕರಿಸುವಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿದೆ, ಆದರೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪರಿಹರಿಸಲು ಸಾಕಷ್ಟು ಕೆಳಮಟ್ಟದಲ್ಲಿದೆ.
• Go ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಪರಿಕರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ಪರೀಕ್ಷೆಗಳು, ದಸ್ತಾವೇಜನ್ನು, ಪ್ಯಾಕೇಜ್ ನಿರ್ವಹಣೆ, ಶಕ್ತಿಯುತ ಲಿಂಟರ್‌ಗಳು, ಕೋಡ್ ಉತ್ಪಾದನೆ, ರೇಸ್ ಪರಿಸ್ಥಿತಿಗಳ ಪತ್ತೆಕಾರಕ, ಇತ್ಯಾದಿ.
• Go ಆವೃತ್ತಿ 1.11 ಜನಪ್ರಿಯ VCS ಹೋಸ್ಟಿಂಗ್‌ನ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಅಂತರ್ನಿರ್ಮಿತ ಶಬ್ದಾರ್ಥದ ಅವಲಂಬನೆ ನಿರ್ವಹಣೆಯನ್ನು ಪರಿಚಯಿಸಿತು. Go ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ರೂಪಿಸುವ ಎಲ್ಲಾ ಪರಿಕರಗಳು ಈ ಸೇವೆಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು, ನಿರ್ಮಿಸಲು ಮತ್ತು ಅವುಗಳಿಂದ ಒಂದೇ ಸ್ವಪ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಬಳಸುತ್ತವೆ. ಮತ್ತು ಅದು ಅದ್ಭುತವಾಗಿದೆ. ಆವೃತ್ತಿ 1.11 ರ ಆಗಮನದೊಂದಿಗೆ, ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಯೊಂದಿಗಿನ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ.
• ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಭಾಷೆಯ ಮುಖ್ಯ ಆಲೋಚನೆಯಾಗಿರುವುದರಿಂದ, ದೋಷ ನಿರ್ವಹಣೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮಾಡಲು ಭಾಷೆ ಅಭಿವರ್ಧಕರನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ಸರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ, ದೋಷ ನಿರ್ವಹಣೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರೆತುಬಿಡುತ್ತದೆ. ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ ಹೆಚ್ಚಿನ ಡೆವಲಪರ್‌ಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ದೋಷ ನಿರ್ವಹಣೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ, ದೋಷವನ್ನು ಮೇಲ್ಮುಖವಾಗಿ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಬದಲು ಆದ್ಯತೆ ನೀಡುತ್ತಾರೆ.
• ಭಾಷೆಯು ಶಾಸ್ತ್ರೀಯ OOP ವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ ಗೋದಲ್ಲಿ ಯಾವುದೇ ವರ್ಚುವಾಲಿಟಿ ಇಲ್ಲ. ಆದಾಗ್ಯೂ, ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಬಳಸುವಾಗ ಇದು ಸಮಸ್ಯೆಯಲ್ಲ. OOP ಯ ಅನುಪಸ್ಥಿತಿಯು ಆರಂಭಿಕರಿಗಾಗಿ ಪ್ರವೇಶಕ್ಕೆ ತಡೆಗೋಡೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಸಮುದಾಯದ ಪ್ರಯೋಜನಕ್ಕಾಗಿ ಸರಳತೆ

ಸಂಕೀರ್ಣಗೊಳಿಸುವುದು ಸುಲಭ, ಸರಳಗೊಳಿಸುವುದು ಕಷ್ಟ.

ಗೋವನ್ನು ಸರಳವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅದು ಆ ಗುರಿಯಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ. ಟೀಮ್‌ವರ್ಕ್‌ನ ಪ್ರಯೋಜನಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮತ್ತು ಎಂಟರ್‌ಪ್ರೈಸ್-ಮಟ್ಟದ ಭಾಷೆಗಳ ಅಂತ್ಯವಿಲ್ಲದ ವ್ಯತ್ಯಾಸದಿಂದ ಬೇಸತ್ತಿರುವ ಸ್ಮಾರ್ಟ್ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಗಾಗಿ ಇದನ್ನು ಬರೆಯಲಾಗಿದೆ. ಅದರ ಶಸ್ತ್ರಾಗಾರದಲ್ಲಿ ತುಲನಾತ್ಮಕವಾಗಿ ಸಣ್ಣ ಸಿಂಟ್ಯಾಕ್ಟಿಕ್ ರಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದು, ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾವಣೆಗಳಿಗೆ ಒಳಪಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅಭಿವರ್ಧಕರು ಅಭಿವೃದ್ಧಿಗಾಗಿ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತಾರೆ ಮತ್ತು ಭಾಷಾ ಆವಿಷ್ಕಾರಗಳನ್ನು ಅನಂತವಾಗಿ ಅಧ್ಯಯನ ಮಾಡಲು ಅಲ್ಲ.

ಕಂಪನಿಗಳು ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ಸಹ ಪಡೆಯುತ್ತವೆ: ಕಡಿಮೆ ಪ್ರವೇಶ ತಡೆಗೋಡೆ ತ್ವರಿತವಾಗಿ ತಜ್ಞರನ್ನು ಹುಡುಕಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಮತ್ತು ಭಾಷೆಯ ಅಸ್ಥಿರತೆಯು 10 ವರ್ಷಗಳ ನಂತರವೂ ಅದೇ ಕೋಡ್ ಅನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ದೊಡ್ಡ ಮೆದುಳಿನ ಗಾತ್ರವು ಯಾವುದೇ ಆನೆಯನ್ನು ನೊಬೆಲ್ ಪ್ರಶಸ್ತಿ ವಿಜೇತರನ್ನಾಗಿ ಮಾಡಿಲ್ಲ.

ಟೀಮ್ ಸ್ಪಿರಿಟ್‌ಗಿಂತ ವೈಯಕ್ತಿಕ ಅಹಂಕಾರಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುವ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮತ್ತು ಶೈಕ್ಷಣಿಕ ಸವಾಲುಗಳು ಮತ್ತು ಅಂತ್ಯವಿಲ್ಲದ "ಸ್ವಯಂ-ಸುಧಾರಣೆ" ಯನ್ನು ಇಷ್ಟಪಡುವ ಸಿದ್ಧಾಂತಿಗಳಿಗೆ, ಭಾಷೆ ನಿಜವಾಗಿಯೂ ಕೆಟ್ಟದಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಕುಶಲಕರ್ಮಿ ಭಾಷೆಯಾಗಿದ್ದು ಅದು ನಿಮಗೆ ಪಡೆಯಲು ಅವಕಾಶ ನೀಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕೆಲಸದ ಫಲಿತಾಂಶದಿಂದ ಸೌಂದರ್ಯದ ಆನಂದ ಮತ್ತು ಸಹೋದ್ಯೋಗಿಗಳ ಮುಂದೆ ನಿಮ್ಮನ್ನು ವೃತ್ತಿಪರವಾಗಿ ತೋರಿಸಿ (ನಾವು ಬುದ್ಧಿವಂತಿಕೆಯನ್ನು ಈ ಮಾನದಂಡಗಳ ಮೂಲಕ ಅಳೆಯುತ್ತೇವೆ ಮತ್ತು ಐಕ್ಯೂ ಮೂಲಕ ಅಲ್ಲ). ಜೀವನದಲ್ಲಿ ಎಲ್ಲದರಂತೆ, ಇದು ವೈಯಕ್ತಿಕ ಆದ್ಯತೆಗಳ ವಿಷಯವಾಗಿದೆ. ಎಲ್ಲಾ ಉಪಯುಕ್ತ ಆವಿಷ್ಕಾರಗಳಂತೆ, ಭಾಷೆ ಈಗಾಗಲೇ ಸಾರ್ವತ್ರಿಕ ನಿರಾಕರಣೆಯಿಂದ ಸಾಮೂಹಿಕ ಸ್ವೀಕಾರಕ್ಕೆ ಬಹಳ ದೂರ ಸಾಗಿದೆ. ಭಾಷೆ ಅದರ ಸರಳತೆಯಲ್ಲಿ ಚತುರವಾಗಿದೆ, ಮತ್ತು, ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಚತುರ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ!

ಮೂಲ: www.habr.com