ලිපිය ලියා ඇත්තේ කලින් පළ කළ ලිපියකට ප්‍රතිචාරයක් වශයෙනි antipodean ලිපිය.

සංවර්ධිත බිල්පත් පද්ධතියක් සහිත විශේෂිත RADIUS සේවාදායකයක් ක්‍රියාත්මක කිරීමට පසුගිය වසර දෙකේ වැඩි කාලය තුළ මම Go භාවිතා කරමි. ඒ අතරම, මම භාෂාවේ සංකීර්ණතා ඉගෙන ගන්නවා. වැඩසටහන් ඉතා සරල වන අතර මෙම ලිපියේ අරමුණ නොවේ, නමුත් Go භාවිතා කිරීමේ අත්දැකීම එහි ආරක්ෂාව සඳහා වචන කිහිපයක් ලැබිය යුතුය. Go බරපතල, පරිමාණය කළ හැකි කේතය සඳහා වැඩි වැඩියෙන් ප්‍රධාන ධාරාවේ භාෂාවක් වෙමින් පවතී. භාෂාව Google විසින් නිර්මාණය කරන ලද අතර එය සක්‍රියව භාවිතා වේ. පහළට, මම අවංකවම සිතන්නේ Go භාෂාවේ සැලසුම UNintelligent වැඩසටහන්කරුවන්ට නරක බවයි.

දුර්වල ක්‍රමලේඛකයින් සඳහා නිර්මාණය කර තිබේද?

දුර්වලයන් ගැටළු ගැන කතා කරයි. අදහස් සහ සිහින ගැන ප්‍රබල කතා...

Go ඉගෙන ගැනීමට ඉතා පහසු වන අතර, ඔබට කිසිදු පුහුණුවක් නොමැතිව කේතය කියවිය හැකි තරම් පහසු වේ. භාෂාවේ මෙම විශේෂාංගය බොහෝ ගෝලීය සමාගම්වල භාවිතා වේ, කේතය මූලික නොවන විශේෂඥයින් (කළමනාකරුවන්, ගනුදෙනුකරුවන්, ආදිය) සමඟ එක්ව කියවන විට. Design Driven Development වැනි ක්‍රමවේද සඳහා මෙය ඉතා පහසු වේ.
නවක ක්‍රමලේඛකයින් පවා සතියකට හෝ දෙකකට පසු තරමක් හොඳ කේතයක් නිෂ්පාදනය කිරීමට පටන් ගනී. මම ඉගෙන ගත්ත පොත තමයි "Go Programming" (Mark Summerfield විසින්). පොත ඉතා හොඳයි, එය භාෂාවේ බොහෝ සූක්ෂ්මතා ස්පර්ශ කරයි. ජාවා, පීඑච්පී වැනි අනවශ්‍ය ලෙස සංකීර්ණ භාෂාවලින් පසුව, මැජික් නොමැතිකම ප්‍රබෝධමත් වේ. නමුත් ඉක්මනින් හෝ පසුව, බොහෝ සීමිත ක්‍රමලේඛකයින්ට නව ක්ෂේත්‍රයක පැරණි ක්‍රම භාවිතා කිරීමේ අදහස ඇත. මෙය ඇත්තෙන්ම අවශ්යද?

Rob Pike (භාෂාවේ ප්‍රධාන දෘෂ්ටිවාදියා) Go භාෂාව නිර්මාණය කළේ පහසුවෙන් තේරුම් ගත හැකි සහ භාවිතයට ඵලදායී ලෙස කාර්මික භාෂාවක් ලෙසය. විශාල කණ්ඩායම්වල උපරිම ඵලදායිතාව සඳහා භාෂාව නිර්මාණය කර ඇති අතර ඒ ගැන සැකයක් නැත. බොහෝ නවක ක්‍රමලේඛකයින් මැසිවිලි නඟන්නේ ඔවුන් අතුරුදහන් වූ බොහෝ විශේෂාංග ඇති බවයි. සරලත්වය සඳහා වූ මෙම ආශාව භාෂාවේ නිර්මාණකරුවන් විසින් දැනුවත් තීරණයක් වූ අතර, එය අවශ්‍ය වූයේ මන්දැයි සම්පූර්ණයෙන් අවබෝධ කර ගැනීම සඳහා, සංවර්ධකයින්ගේ අභිප්‍රේරණය සහ ඔවුන් Go හි සාක්ෂාත් කර ගැනීමට උත්සාහ කළ දේ අප තේරුම් ගත යුතුය.

එසේනම් එය එතරම් සරල කළේ ඇයි? මෙන්න රොබ් පයික්ගේ උපුටා දැක්වීම් කිහිපයක්:

මෙහි ඇති ප්‍රධාන කරුණ නම් අපගේ ක්‍රමලේඛකයින් පර්යේෂකයන් නොවන බවයි. ඔවුන්, රීතියක් ලෙස, තරමක් තරුණ, ඉගෙනීමෙන් පසු අප වෙත පැමිණ, සමහර විට ඔවුන් Java, හෝ C/C++, හෝ Python ඉගෙන ගත්තා. එයාලට ලොකු භාෂාවක් තේරෙන්නේ නෑ, ඒත් එක්කම අපිට ඕනේ එයාලට හොඳ Software හදන්න. භාෂාව තේරුම් ගැනීමට සහ ඉගෙන ගැනීමට පහසු විය යුත්තේ එබැවිනි.

ඔහු හුරුපුරුදු විය යුතුය, දළ වශයෙන් C ට සමාන ය. Google හි වැඩ කරන ක්‍රමලේඛකයින් ඔවුන්ගේ වෘත්තීය ජීවිතය කලින් ආරම්භ කරන අතර බොහෝ දුරට පරිපාටිමය භාෂා, විශේෂයෙන්ම C පවුල ගැන හුරුපුරුදුය. නව ක්‍රමලේඛන භාෂාවක ඉක්මන් ඵලදායිතාවයක් අවශ්‍ය වන්නේ භාෂාව ඉතා රැඩිකල් නොවිය යුතු බවයි.

ප්‍රඥාවන්ත වචන නේද?

සරලත්වයේ කෞතුක වස්තු

සරල බව සුන්දරත්වය සඳහා අවශ්ය කොන්දේසියකි. ලෙව් ටෝල්ස්ටෝයි.

එය සරලව තබා ගැනීම ඕනෑම නිර්මාණයක වැදගත්ම ඉලක්කයකි. ඔබ දන්නා පරිදි, පරිපූර්ණ ව්‍යාපෘතියක් යනු එකතු කිරීමට කිසිවක් නොමැති ව්‍යාපෘතියක් නොව, ඉවත් කිරීමට කිසිවක් නොමැති ව්‍යාපෘතියකි. බොහෝ අය විශ්වාස කරන්නේ සංකීර්ණ ගැටළු විසඳීමට (හෝ ප්රකාශ කිරීමට පවා) සංකීර්ණ මෙවලමක් අවශ්ය බවයි. කෙසේ වෙතත්, එය නොවේ. අපි උදාහරණයක් ලෙස PERL භාෂාව ගනිමු. භාෂා දෘෂ්ටිවාදීන් විශ්වාස කළේ ක්‍රමලේඛකයෙකුට එක් ගැටළුවක් විසඳීමට අවම වශයෙන් විවිධ ක්‍රම තුනක්වත් තිබිය යුතු බවයි. ගෝ භාෂාවේ දෘෂ්ටිවාදින් වෙනත් මාර්ගයක් ගත්හ; ඉලක්කය සපුරා ගැනීම සඳහා එක් මාර්ගයක්, නමුත් ඇත්තෙන්ම හොඳ මාර්ගයක් ප්රමාණවත් බව ඔවුහු තීරණය කළහ. මෙම ප්රවේශය බරපතල පදනමක් ඇත: එකම මාර්ගය ඉගෙන ගැනීමට පහසු වන අතර අමතක කිරීමට අපහසු වේ.

බොහෝ සංක්‍රමණිකයන් පැමිණිලි කරන්නේ භාෂාවේ අලංකාර වියුක්තයන් අඩංගු නොවන බවයි. ඔව්, මෙය සත්යයකි, නමුත් මෙය භාෂාවේ ප්රධාන වාසි වලින් එකකි. භාෂාවේ අවම මැජික් අඩංගු වේ - එබැවින් වැඩසටහන කියවීමට ගැඹුරු දැනුමක් අවශ්‍ය නොවේ. කේතයේ වාචිකත්වය සම්බන්ධයෙන් ගත් කල, මෙය කිසිසේත්ම ගැටළුවක් නොවේ. හොඳින් ලියා ඇති Golang වැඩසටහනක් කුඩා හෝ ව්‍යුහයක් නොමැතිව සිරස් අතට කියවයි. මීට අමතරව, වැඩසටහනක් කියවීමේ වේගය අවම වශයෙන් එය ලිවීමේ වේගයට වඩා විශාලත්වයේ අනුපිළිවෙලකි. සියලුම කේතයන් ඒකාකාර හැඩතල ගැන්වීමක් ඇති බව ඔබ සලකන්නේ නම් (බිල්ට්-ඉන් gofmt විධානය භාවිතා කර ඇත), එවිට අමතර රේඛා කිහිපයක් කියවීම කිසිසේත්ම ගැටළුවක් නොවේ.

ඉතා ප්රකාශිත නොවේ

නිදහස සීමා වූ විට කලාව ඉවසන්නේ නැත. නිරවද්යතාව ඔහුගේ වගකීම නොවේ.

සරලත්වය සඳහා ඇති ආශාව නිසා, වෙනත් භාෂාවලින් ඔවුන්ට හුරුපුරුදු අය විසින් ස්වභාවික දෙයක් ලෙස සලකන ආකාරයේ ඉදිකිරීම් Go හි නොමැත. මුලදී එය තරමක් අපහසු විය හැකි නමුත්, වැඩසටහන කියවීමට වඩා පහසු සහ නොපැහැදිලි බව ඔබට පෙනේ.

උදාහරණයක් ලෙස, 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)
}

D හි ඇති එකම ගැටලුවට විසඳුම, එය තරමක් කෙටි ලෙස පෙනුනද, කියවීමට පහසු නැත

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);
    }
}

කොපි කරන මගුලක්

මිනිසා තමා තුළම අපාය රැගෙන යයි. මාටින් ලූතර්.

Generics නොමැතිකම සම්බන්ධයෙන් ආරම්භකයින් නිරන්තරයෙන් Go ගැන පැමිණිලි කරයි. මෙම ගැටළුව විසඳීම සඳහා, ඔවුන්ගෙන් බොහෝ දෙනෙක් සෘජු කේත පිටපත් කිරීම භාවිතා කරයි. උදාහරණයක් ලෙස, පූර්ණ සංඛ්‍යා ලැයිස්තුවක් සාරාංශ කිරීම සඳහා වූ ශ්‍රිතයක්, එක් එක් දත්ත වර්ගය සඳහා සරල පිටපත් ඇලවීමකින් මිස වෙනත් ආකාරයකින් ක්‍රියාකාරීත්වය ක්‍රියාත්මක කළ නොහැකි බව එවැනි වෘත්තිකයන් විශ්වාස කරයි.

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;
}

කෙසේ වෙතත්, එය කෙටි වේ, නමුත් වඩා නිවැරදි නොවේ, D ක්‍රියාත්මක කිරීම දෝෂ හැසිරවීමේ ගැටලුව සම්පූර්ණයෙන්ම නොසලකා හරින බැවිනි.

සැබෑ ජීවිතයේ දී, තර්කනයේ සංකීර්ණත්වය වැඩි වන විට, පරතරය වේගයෙන් අඩු වේ. සම්මත භාෂා ක්‍රියාකරුවන් භාවිතයෙන් සිදු කළ නොහැකි ක්‍රියාවක් කිරීමට අවශ්‍ය වූ විට පරතරය වඩාත් වේගයෙන් වැසී යයි.

නඩත්තු කිරීමේ හැකියාව, විස්තීරණ බව සහ කියවීමේ හැකියාව අනුව, මගේ මතය අනුව, Go භාෂාව ජය ගනී, එය වාචිකත්වයෙන් පැරදුනත්.

සාමාන්‍යකරණය වූ වැඩසටහන් සමහර අවස්ථාවල දී අපට ප්‍රතික්ෂේප කළ නොහැකි ප්‍රතිලාභ ලබා දෙයි. වර්ග කිරීමේ පැකේජය මගින් මෙය පැහැදිලිව පෙන්නුම් කරයි. එබැවින්, ඕනෑම ලැයිස්තුවක් වර්ග කිරීම සඳහා, අපට අවශ්ය වන්නේ 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 “අතුරුමුහුණත{}” -R විධානය ක්‍රියාත්මක කරන්නේ නම්, ව්‍යාකූල අතුරුමුහුණත් කොපමණ වාර ගණනක් භාවිතා වේද යන්න ඔබට පෙනෙනු ඇත. මේ සියල්ල ජෙනරික් නොමැතිකම නිසා යැයි සමීප මනසක් ඇති සහෘදයින් වහාම කියනු ඇත. කෙසේ වෙතත්, මෙය සැමවිටම නොවේ. අපි උදාහරණයක් ලෙස DELPHI ගනිමු. මෙම ජෙනරික්ස් තිබියදීත්, අත්තනෝමතික දත්ත වර්ග සමඟ මෙහෙයුම් සඳහා විශේෂ VARIANT වර්ගයක් එහි අඩංගු වේ. Go භාෂාව ද එයම කරයි.

කාලතුවක්කුවක සිට ගේ කුරුල්ලන් දක්වා

ඒවගේම ස්ට්‍රයිට් ජැකට් එක පිස්සුවේ ප්‍රමාණයට ගැලපෙන්න ඕනේ. ස්ටැනිස්ලාව් ලෙක්.

බොහෝ ආන්තික රසිකයින් ගෝට ජෙනරික්ස් - පරාවර්තනය නිර්මාණය කිරීම සඳහා තවත් යාන්ත්‍රණයක් ඇති බව ප්‍රකාශ කළ හැකිය. ඔවුන් නිවැරදි වනු ඇත ... නමුත් දුර්ලභ අවස්ථාවන්හිදී පමණි.

රොබ් පයික් අපට අනතුරු අඟවයි:

මෙය ප්‍රවේශමෙන් භාවිතා කළ යුතු ප්‍රබල මෙවලමකි. දැඩි ලෙස අවශ්ය නම් මිස එය වළක්වා ගත යුතුය.

විකිපීඩියාව අපට පහත දේ කියයි:

පරාවර්තනය යනු වැඩසටහනක් ක්‍රියාත්මක කිරීමේදී එහි ව්‍යුහය සහ හැසිරීම නිරීක්ෂණය කිරීමට සහ වෙනස් කිරීමට හැකි ක්‍රියාවලියයි. පරාවර්තනයට යටින් පවතින ක්‍රමලේඛන ආදර්ශය පරාවර්තක ක්‍රමලේඛනය ලෙස හැඳින්වේ. මෙය metaprogramming වර්ගයකි.

කෙසේ වෙතත්, ඔබ දන්නා පරිදි, ඔබ සියල්ල සඳහා ගෙවිය යුතුය. මෙම අවස්ථාවේ දී එය:

• වැඩසටහන් ලිවීමේ අපහසුතාව
• වැඩසටහන ක්රියාත්මක කිරීමේ වේගය

එමනිසා, පරාවර්තනය විශාල ප්‍රමාණයේ ආයුධයක් මෙන් ප්‍රවේශමෙන් භාවිතා කළ යුතුය. පරාවර්තනය නොසැලකිලිමත් ලෙස භාවිතා කිරීම කියවිය නොහැකි වැඩසටහන්, නිරන්තර දෝෂ සහ අඩු වේගයට හේතු වේ. වෙනත්, වඩා ප්‍රායෝගික සහ නිහතමානී සගයන් ඉදිරියේ ඔහුගේ කේතය පෙන්වීමට හැකිවීම ස්නොබ් ක්‍රමලේඛකයෙකුට ඇති දෙයකි.

Xi වෙතින් සංස්කෘතික ගමන් මලු? නැත, භාෂා ගණනාවකින්!

වාසනාව සමඟ ණය ද උරුමකරුවන්ට ඉතිරි වේ.

භාෂාව සම්පූර්ණයෙන්ම C උරුමය මත පදනම් වී ඇති බව බොහෝ දෙනා විශ්වාස කළද, මෙය එසේ නොවේ. භාෂාව හොඳම ක්‍රමලේඛන භාෂා වල බොහෝ අංග ඇතුළත් කරයි.

කාරක රීති

පළමුවෙන්ම, ව්‍යාකරණ ව්‍යුහවල වාක්‍ය ඛණ්ඩය පදනම් වන්නේ C භාෂාවේ වාක්‍ය ඛණ්ඩය මතය. කෙසේ වෙතත්, DELPHI භාෂාව ද සැලකිය යුතු බලපෑමක් ඇති කළේය. මේ අනුව, වැඩසටහනේ කියවීමේ හැකියාව බෙහෙවින් අඩු කරන අතිරික්ත වරහන් සම්පූර්ණයෙන්ම ඉවත් කර ඇති බව අපට පෙනේ. භාෂාවේ DELPHI භාෂාවට ආවේණික “:=” ක්‍රියාකරු ද අඩංගු වේ. පැකේජ සංකල්පය ADA වැනි භාෂා වලින් ලබාගෙන ඇත. භාවිතයට නොගත් ආයතනවල ප්‍රකාශය PROLOG භාෂාවෙන් ණයට ගෙන ඇත.

අර්ථ නිරූපණය

පැකේජ DELPHI භාෂාවේ අර්ථ ශාස්ත්‍රය මත පදනම් විය. සෑම පැකේජයක්ම දත්ත සහ කේත සංග්‍රහ කරන අතර පුද්ගලික සහ පොදු ආයතන අඩංගු වේ. පැකේජ අතුරුමුහුණත අවම වශයෙන් අඩු කිරීමට මෙය ඔබට ඉඩ සලසයි.

නියෝජිත ක්‍රමය මගින් ක්‍රියාත්මක කිරීමේ මෙහෙයුම DELPHI භාෂාවෙන් ණයට ගන්නා ලදී.

සම්පාදනය

විහිළුවක් ඇත්තේ හේතුවක් නොමැතිව නොවේ: C වැඩසටහනක් සම්පාදනය කරන අතරතුර Go සංවර්ධනය කරන ලදී. භාෂාවේ එක් ශක්තියක් වන්නේ එහි අති වේගවත් සම්පාදනයයි. අදහස DELPHI භාෂාවෙන් ලබාගෙන ඇත. සෑම Go පැකේජයක්ම DELPHI මොඩියුලයකට අනුරූප වේ. මෙම පැකේජ නැවත සකස් කරනු ලබන්නේ සැබවින්ම අවශ්‍ය වූ විට පමණි. එමනිසා, ඊළඟ සංස්කරණයෙන් පසුව, ඔබට සම්පූර්ණ වැඩසටහන සම්පාදනය කිරීමට අවශ්‍ය නැත, නමුත් මෙම වෙනස් කළ පැකේජ මත රඳා පවතින වෙනස් වූ පැකේජ සහ පැකේජ පමණක් නැවත සම්පාදනය කරන්න (එවිට පවා, පැකේජ අතුරුමුහුණත් වෙනස් වී ඇත්නම් පමණි).

ඉහළ මට්ටමේ ඉදිකිරීම්

C වැනි පහත් මට්ටමේ භාෂාවලට කිසිදු ආකාරයකින් සම්බන්ධ නොවන විවිධ ඉහළ මට්ටමේ ඉදිකිරීම් භාෂාවේ අඩංගු වේ.

• රේඛා
• හැෂ් වගු
• පෙති
• ඩක් ටයිප් කිරීම RUBY වැනි භාෂාවලින් ණයට ගෙන ඇත (අවාසනාවකට මෙන්, බොහෝ දෙනෙකුට එහි සම්පූර්ණ විභවය තේරුම් ගැනීමට හෝ භාවිතා කිරීමට නොහැකි වේ).

මතක කළමනාකරණය

මතක කළමනාකරණය සාමාන්‍යයෙන් වෙනම ලිපියක් ලැබිය යුතුය. C++ වැනි භාෂා වල, පාලනය සම්පූර්ණයෙන්ම සංවර්ධකයාට පැවරේ නම්, පසුව DELPHI වැනි භාෂා වල, යොමු ගණන් කිරීමේ ආකෘතියක් භාවිතා කරන ලදී. මෙම ප්‍රවේශය සමඟින්, අනාථ පොකුරු සෑදී ඇති බැවින්, චක්‍රීය යොමු කිරීම්වලට ඉඩ නොලැබුණි, එවිට Go හට එවැනි පොකුරු (C# වැනි) ගොඩනගා ඇත. මීට අමතරව, කසළ එකතු කරන්නා දැනට දන්නා බොහෝ ක්‍රියාත්මක කිරීම් වලට වඩා කාර්යක්ෂම වන අතර බොහෝ තත්‍ය කාලීන කාර්යයන් සඳහා දැනටමත් භාවිතා කළ හැක. විචල්‍යයක් ගබඩා කිරීම සඳහා අගයක් තොගය මත වෙන් කළ හැකි අවස්ථා භාෂාව විසින්ම හඳුනා ගනී. මෙය මතක කළමනාකරු මත පැටවීම අඩු කරන අතර වැඩසටහනේ වේගය වැඩි කරයි.

සමකාලීන සහ සමගාමී

භාෂාවේ සමාන්තරභාවය සහ තරඟකාරිත්වය ප්‍රශංසාව ඉක්මවා යයි. කිසිදු පහත් මට්ටමේ භාෂාවකට Go සමඟ දුරස්ථව තරඟ කළ නොහැක. සාධාරණ වීමට නම්, ආකෘතිය භාෂාවේ කතුවරුන් විසින් සොයා නොගත් නමුත් හොඳ පැරණි ADA භාෂාවෙන් සරලව ණයට ගත් බව සඳහන් කිරීම වටී. බහු-නූල් කේත සඳහා සාමාන්‍ය වන ඩෙඩ්ලොක් සහ ධාවන තත්ත්වයන් සමඟ විශාලත්වයෙන් අඩු සංකීර්ණ ගැටළු ඇති අතරම, සියලුම CPU භාවිතා කරමින් මිලියන ගණනක් සමාන්තර සම්බන්ධතා සැකසීමට භාෂාවට හැකියාව ඇත.

අමතර ප්රතිලාභ

එය ලාභදායක නම්, සෑම කෙනෙකුම පරාර්ථකාමී වනු ඇත.

භාෂාව අපට නිසැකවම ප්‍රතිලාභ ගණනාවක් ලබා දෙයි:

• ව්‍යාපෘතිය ගොඩ නැගීමෙන් පසු තනි ක්‍රියාත්මක කළ හැකි ගොනුවක් යෙදුම් යෙදවීම බෙහෙවින් සරල කරයි.
• ස්ථිතික ටයිප් කිරීම සහ ටයිප් අනුමානය මඟින් පරීක්ෂණ ලිවීමෙන් තොරව පවා ඔබේ කේතයේ ඇති දෝෂ ගණන සැලකිය යුතු ලෙස අඩු කළ හැක. මම දන්නවා සමහර ක්‍රමලේඛකයින් පරීක්ෂණ ලිවීමෙන් තොරව කරන අතර ඔවුන්ගේ කේතයේ ගුණාත්මක භාවය සැලකිය යුතු ලෙස දුක් විඳින්නේ නැත.
• හරස් වේදිකා යෙදුම් සංවර්ධනය බෙහෙවින් සරල කරන සම්මත පුස්තකාලයේ ඉතා සරල හරස් සම්පාදනය සහ විශිෂ්ට අතේ ගෙන යා හැකි හැකියාව.
• RE2 නිත්‍ය ප්‍රකාශන නූල් ආරක්ෂිත වන අතර පුරෝකථනය කළ හැකි ක්‍රියාත්මක කිරීමේ වේලාවන් ඇත.
• තුන්වන පාර්ශ්ව රාමු නොමැතිව බොහෝ ව්‍යාපෘති කිරීමට ඉඩ සලසන බලවත් සම්මත පුස්තකාලයකි.
• ගැටලුව විසඳන්නේ කෙසේද යන්නට වඩා ගැටලුව කෙරෙහි අවධානය යොමු කිරීමට තරම් භාෂාව බලවත් නමුත් ගැටලුව කාර්යක්ෂමව විසඳිය හැකි තරම් පහත් මට්ටමක පවතී.
• Go eco පද්ධතියේ දැනටමත් සියලුම අවස්ථාවන් සඳහා සංවර්ධිත මෙවලම් අඩංගු වේ: පරීක්ෂණ, ලියකියවිලි, පැකේජ කළමනාකරණය, බලවත් ලින්ටර්, කේත උත්පාදනය, ධාවන තත්ව අනාවරකය යනාදිය.
• Go අනුවාදය 1.11 ජනප්‍රිය VCS සත්කාරකත්වය මත ගොඩනගා ඇති බිල්ට්-ඉන් අර්ථකථන යැපුම් කළමනාකරණය හඳුන්වා දෙන ලදී. Go පරිසර පද්ධතිය සෑදෙන සියලුම මෙවලම් එක පහරකින් ඔවුන්ගෙන් කේතය බාගත කිරීමට, ගොඩනැගීමට සහ ස්ථාපනය කිරීමට මෙම සේවාවන් භාවිතා කරයි. ඒ වගේම නියමයි. 1.11 අනුවාදය පැමිණීමත් සමඟ, පැකේජ අනුවාදයේ ගැටළුව ද සම්පූර්ණයෙන්ම විසඳා ඇත.
• භාෂාවේ මූලික අදහස මැජික් අඩු කිරීම නිසා, භාෂාව පැහැදිලිවම දෝෂ හැසිරවීමට සංවර්ධකයින් දිරිමත් කරයි. මෙය නිවැරදියි, මන්ද එසේ නොවුවහොත්, දෝෂ හැසිරවීම සම්පූර්ණයෙන්ම අමතක වනු ඇත. තවත් දෙයක් නම්, බොහෝ සංවර්ධකයින් හිතාමතාම දෝෂ හැසිරවීම නොසලකා හරින අතර, ඒවා සැකසීම වෙනුවට දෝෂය ඉහළට යොමු කිරීමට කැමැත්තක් දක්වයි.
• භාෂාව සම්භාව්‍ය OOP ක්‍රමය ක්‍රියාත්මක නොකරයි, මන්ද එහි පිරිසිදු ස්වරූපයෙන් Go හි අතථ්‍යතාවයක් නොමැති බැවිනි. කෙසේ වෙතත්, අතුරු මුහුණත් භාවිතා කිරීමේදී මෙය ගැටළුවක් නොවේ. OOP නොමැති වීම ආරම්භකයින් සඳහා ඇතුල් වීමට ඇති බාධාව සැලකිය යුතු ලෙස අඩු කරයි.

ප්‍රජා ප්‍රයෝජනය සඳහා සරල බව

එය සංකීර්ණ කිරීමට පහසුය, සරල කිරීමට අපහසුය.

Go නිර්මාණය කර ඇත්තේ සරල ලෙස වන අතර එය එම ඉලක්කයට සාර්ථක වේ. එය ලියා ඇත්තේ කණ්ඩායම් ක්‍රියාකාරිත්වයේ ප්‍රතිලාභ අවබෝධ කර ගන්නා සහ ව්‍යවසාය මට්ටමේ භාෂාවල නිමක් නැති විචල්‍යතාවයෙන් වෙහෙසට පත් වූ දක්ෂ ක්‍රමලේඛකයින් සඳහා ය. එහි අවි ගබඩාවේ සාපේක්ෂව කුඩා වාක්‍ය ව්‍යුහයක් තිබීම, එය ප්‍රායෝගිකව කාලයත් සමඟ වෙනස්කම් වලට යටත් නොවේ, එබැවින් සංවර්ධකයින්ට සංවර්ධනය සඳහා බොහෝ කාලයක් නිදහස් කර ඇති අතර, නිමක් නැතිව භාෂා නවෝත්පාදන අධ්‍යයනය කිරීම සඳහා නොවේ.

සමාගම්වලට ද වාසි ගණනාවක් ලැබේ: අඩු ප්‍රවේශ බාධකයක් ඉක්මනින් විශේෂඥයෙකු සොයා ගැනීමට ඉඩ සලසයි, සහ භාෂාවේ වෙනස් නොවන බව වසර 10 කට පසුව පවා එකම කේතය භාවිතා කිරීමට ඉඩ සලසයි.

නිගමනය

මොළයේ විශාලත්වය කිසිදාක කිසිදු අලියෙකු නොබෙල් ත්‍යාගලාභියෙකු බවට පත් කර නැත.

කණ්ඩායම් හැඟීමට වඩා පුද්ගලික මමත්වය ප්‍රමුඛත්වය ගන්නා ක්‍රමලේඛකයින්ට මෙන්ම ශාස්ත්‍රීය අභියෝගවලට සහ නිමක් නැති "ස්වයං-අභිවෘද්ධියට" ආදරය කරන න්‍යායවාදීන්ට, භාෂාව ඇත්තෙන්ම නරක ය, මන්ද එය ඔබට ලබා ගැනීමට ඉඩ නොදෙන පොදු කාර්ය ශිල්පීය භාෂාවක් වන බැවිනි. ඔබගේ කාර්යයේ ප්‍රතිඵලයෙන් සෞන්දර්යාත්මක සතුටක් සහ සගයන් ඉදිරියේ ඔබ වෘත්තීය බව පෙන්වන්න (අපි බුද්ධිය මනින්නේ මෙම නිර්ණායක මගින් මිස IQ මගින් නොවේ). ජීවිතයේ සෑම දෙයක්ම මෙන්, එය පෞද්ගලික ප්රමුඛතා පිළිබඳ කාරණයකි. සියලු වටිනා නවෝත්පාදනයන් මෙන්, භාෂාව දැනටමත් විශ්වීය ප්‍රතික්ෂේප කිරීමේ සිට මහජන පිළිගැනීම දක්වා බොහෝ දුර පැමිණ ඇත. භාෂාව එහි සරල බවෙහි දක්ෂ වන අතර, ඔබ දන්නා පරිදි, සෑම දෙයක්ම සරල ය!

මූලාශ්රය: www.habr.com