คำถามติดแท็ก go

Go หรือที่เรียกว่า golang เป็นภาษาโปรแกรมโอเพ่นซอร์สที่พัฒนาโดย Google เป็นภาษาที่พิมพ์แบบคงที่โดยมีไวยากรณ์ที่มาจากภาษา C อย่างหลวม ๆ เพิ่มการจัดการหน่วยความจำอัตโนมัติความปลอดภัยของประเภทความสามารถในการพิมพ์แบบไดนามิกบางประเภทในตัวเพิ่มเติมเช่นอาร์เรย์ที่มีความยาวตัวแปรและแผนที่คีย์ - ค่าและขนาดใหญ่ ห้องสมุดมาตรฐาน


1
ลักษณะของ Rust แตกต่างจาก Go Interfaces อย่างไร
ฉันค่อนข้างคุ้นเคยกับ Go โดยเขียนโปรแกรมขนาดเล็กจำนวนมากในนั้น แน่นอนว่าสนิมฉันไม่คุ้นเคย แต่จับตาดู เมื่อเร็ว ๆ นี้อ่านhttp://yager.io/programming/go.htmlฉันคิดว่าฉันควรตรวจสอบสองวิธีที่ Generics ได้รับการจัดการเพราะบทความดูเหมือนจะวิพากษ์วิจารณ์อย่างไม่เป็นธรรมไปเมื่อในทางปฏิบัติมีอะไรมากที่อินเตอร์เฟส ไม่สามารถทำได้อย่างสวยงาม ฉันยังคงได้ยินโฆษณาต่อไปเกี่ยวกับลักษณะของ Rust ที่ทรงพลังและไม่มีอะไรนอกจากการวิจารณ์จากคนเกี่ยวกับ Go มีประสบการณ์ใน Go ฉันสงสัยว่าความจริงมันเป็นอย่างไรและอะไรคือความแตกต่างในท้ายที่สุด สิ่งที่ฉันพบคือลักษณะและการเชื่อมต่อมีความคล้ายคลึงกัน! ท้ายที่สุดฉันไม่แน่ใจว่าฉันขาดอะไรบางอย่างดังนั้นนี่คือบทสรุปการศึกษาที่รวดเร็วเกี่ยวกับความคล้ายคลึงกันของพวกเขาเพื่อให้คุณสามารถบอกฉันว่าฉันพลาดอะไรไป! ตอนนี้ขอใช้เวลาดูไปเชื่อมต่อจากพวกเขาเอกสาร : อินเทอร์เฟซในตัวไปมีวิธีในการระบุพฤติกรรมของวัตถุ: หากมีสิ่งใดสามารถทำได้ก็สามารถใช้ที่นี่ได้ ส่วนใหญ่แล้วอินเตอร์เฟสจะStringerส่งคืนสตริงที่แสดงถึงวัตถุ type Stringer interface { String() string } ดังนั้นวัตถุใด ๆ ที่มีการString()กำหนดไว้เป็นStringerวัตถุ นี้สามารถใช้ในลายเซ็นประเภทเช่นที่func (s Stringer) print()ใช้วัตถุเกือบทั้งหมดและพิมพ์ นอกจากนี้เรายังมีinterface{}สิ่งที่ใช้วัตถุใด ๆ จากนั้นเราจะต้องกำหนดประเภทของรันไทม์ผ่านการสะท้อนกลับ ตอนนี้เรามาดูลักษณะของสนิมจากเอกสารประกอบ : ที่ง่ายที่สุดลักษณะคือชุดของลายเซ็นวิธีการศูนย์หรือมากกว่า ตัวอย่างเช่นเราสามารถประกาศลักษณะที่พิมพ์ได้สำหรับสิ่งที่สามารถพิมพ์ไปยังคอนโซลด้วยลายเซ็นวิธีการเดียว: trait Printable { fn …
64 go  rust 


1
ทำไมจึงมี "ใหม่" ใน Go
ฉันยังงงเหมือนว่าทำไมเราถึงnewไปกัน เมื่อคุณต้องการสร้างอินสแตนซ์ของโครงสร้างให้ทำ t := Thing{} และคุณสามารถรับตัวชี้ไปยังอินสแตนซ์ใหม่โดยการทำ t := &Thing{} แต่ยังมีความเป็นไปได้นี้: t := new(Thing) อันสุดท้ายดูเหมือนว่าคนต่างด้าวตัวเล็ก ๆ กับภาษาที่เหลือ &Thing{}มีความชัดเจนและรัดกุมเหมือนกันnew(Thing)และใช้โครงสร้างที่คุณมักใช้ที่อื่นเท่านั้น นอกจากนี้ยังขยายมากขึ้นในขณะที่คุณอาจจะเปลี่ยนไปหรือ&Thing{3} &Thing{Feets:7} ในความคิดของฉันการมีคำหลักเสริม1นั้นมีค่าใช้จ่ายสูงมันทำให้ภาษามีความซับซ้อนมากขึ้นและเพิ่มในสิ่งที่คุณต้องรู้ และมันอาจปิดบังผู้มาใหม่ว่ามีอะไรอยู่เบื้องหลังอินสแตนซ์ของโครงสร้าง นอกจากนี้ยังทำให้คำที่สงวนไว้อีกหนึ่งคำ ดังนั้นเหตุผลที่อยู่เบื้องหลังnewคืออะไร? บางครั้งมันมีประโยชน์หรือไม่ เราควรใช้มันหรือไม่? 1 : ใช่ฉันรู้ว่าไม่ใช่คำหลักในระดับไวยากรณ์คุณสามารถเงาได้แต่นั่นไม่ได้เปลี่ยนความจริงสำหรับนักพัฒนาที่เหมาะสมคำที่สงวนไว้
49 go 

1
goroutine พูลเป็นแบบเธรดสีเขียวหรือไม่
ผู้วิจารณ์ที่นี่เสนอคำวิจารณ์ต่อไปนี้ของหัวข้อสีเขียว: ตอนแรกฉันขายในโมเดล N: M เพื่อให้มีการเขียนโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์โดยไม่ต้องโทรกลับนรก คุณสามารถเขียนโค้ดที่ดูเหมือนรหัสขั้นตอนเก่าที่เจ็บปวดได้ แต่ภายใต้มีเวทย์มนตร์ที่ใช้งานการสลับผู้ใช้เมื่อใดก็ตามที่บางสิ่งจะปิดกั้น ฟังดูดี. ปัญหาคือเราท้ายการแก้ไขความซับซ้อนด้วยความซับซ้อนมากขึ้น swapcontext () และตระกูลค่อนข้างแคบไปข้างหน้าความซับซ้อนมาจากที่อื่น ๆ ทันใดนั้นคุณถูกบังคับให้เขียนตารางเวลา userspace และเดาว่ามันยากจริงๆที่จะเขียนตัวจัดตารางเวลาที่จะทำงานได้ดีขึ้นซึ่งตารางเวลาของ Linux ที่มีความพยายามมาหลายปี ตอนนี้คุณต้องการกำหนดเวลาให้กับเธรด N สีเขียวของฟิสิคัลเธรด M ดังนั้นคุณต้องกังวลเกี่ยวกับการซิงโครไนซ์ การซิงโครไนซ์นำปัญหาด้านประสิทธิภาพมาใช้เพื่อให้คุณเริ่มได้ในตอนนี้คุณกำลังลงสู่หลุมกระต่ายที่ไม่มีล็อค การสร้างตัวกำหนดตารางเวลาพร้อมกันที่ถูกต้องสูงไม่ใช่เรื่องง่าย บทวิจารณ์อื่นอยู่ที่นี่ : กระบวนการเดียวที่แกล้งทำหลายเธรดมีปัญหามากมาย หนึ่งในนั้นคือเธรดที่แกล้งทำอยู่บนหน้าเพจที่ผิด คำถามของฉัน - จะไป lang ของ goroutines (สำหรับสระว่ายน้ำเริ่มต้น) เพียงหัวข้อสีเขียว? ถ้าเป็นเช่นนั้นพวกเขาจะจัดการกับคำวิจารณ์ข้างต้นหรือไม่

4
ไปได้เร็วแค่ไหน?
Go เป็นหนึ่งในไม่กี่ภาษาที่ควรจะเรียกใช้ 'ใกล้กับโลหะ' นั่นคือมันถูกรวบรวมพิมพ์แบบคงที่และเรียกใช้งานโค้ดโดยไม่ต้องใช้ VM สิ่งนี้ควรให้ความได้เปรียบด้านความเร็วเหนือ Java, C # และอื่น ๆ อย่างไรก็ตามดูเหมือนว่าอยู่หลัง Java (ดูProgramming Language Shootout ) ฉันสมมติว่าคอมไพเลอร์ที่มีวุฒิภาวะน้อยกว่ามีความรับผิดชอบอย่างมากในเรื่องนี้ แต่มีเหตุผลอื่นอีกไหม? มีอะไรในการออกแบบของ Go ที่จะป้องกันไม่ให้รันเร็วกว่าพูด Java หรือไม่? ฉันมีมุมมองที่ไม่ซับซ้อนมากของแบบจำลองรันไทม์ แต่ดูเหมือนว่าอย่างน้อยในหลักการแล้วมันควรจะสามารถทำงานได้เร็วกว่าจาวาเพราะต้องมีการประมวลผลโค้ดเนทีฟ

4
Google ลงทุนในภาษา Go เป็นจำนวนเท่าใด
ฉันได้อ่านเกี่ยวกับภาษาโกและดูเหมือนว่าจะมีแนวโน้ม ข้อมูลสำคัญที่ฉันหายไปก่อนที่ฉันจะตัดสินใจใช้ภาษาให้มากขึ้นคือ: Google หรือ บริษัท อื่น ๆ ใช้เงิน / กำลังคนเท่าไรในการพัฒนาความพยายาม หากไม่สามารถให้ข้อมูลนี้ได้คุณมีข้อมูลอื่นใดที่แสดงถึงความมุ่งมั่นของ Google ต่อโครงการ มันถูกใช้เป็นภาษาหลักสำหรับการลงทุนใหม่หรือคล้ายกัน (ฉันเดาว่ามันเร็วเกินไปสำหรับสิ่งนี้ แต่ฉันไม่รู้)

3
การมีซอร์สโค้ดสำหรับโครงการ Go นอก GOPATH เป็นความคิดที่ไม่ดี
ฉันกำลังทำงานในโครงการใหม่โดยใช้ Go และเราทุกคนยังใหม่กับ Go เรากำลังติดตามโครงสร้างไดเรคทอรี go มาตรฐานและมีโค้ดทั้งหมดอยู่ด้านล่าง $ GOPATH / src / github.com / CompanyName / projectname ซึ่งก็เป็นรากของพื้นที่เก็บข้อมูลคอมไพล์ รูปแบบเส้นทางที่แนะนำมาตรฐานดูเหมือนแปลกโดยเฉพาะอย่างยิ่งถ้าเรากำลังทำงานในโครงการหลายภาษาเช่นส่วนที่เหลือตาม Go / http backend และ html / javascript front-end ในกรณีนี้ฉันอาจต้องการให้โครงสร้างโครงการของฉันเป็นดังนี้: / doc/ src/ server/ main.go module1/ module.go client/ index.html Makefile แต่จริง ๆ แล้วจำเป็นต้องวางรหัสไว้ใน GOPATH หรือไม่ ในความพยายามฉันได้สร้างโปรแกรมขนาดเล็กที่ซอร์สโค้ดอยู่นอก GOPATH ฉันได้อย่างง่ายดายสามารถแยกโครงการออกเป็นแพคเกจเพื่อให้mainแพคเกจสามารถอ้างอิงfooแพคเกจในโฟลเดอร์โดยใช้foo/import "./foo" เท่าที่ฉันเห็นมีสองสิ่งที่ไม่เชื่อฟังฉัน: รหัสอื่นไม่สามารถนำเข้ารหัสนี้ได้ …
32 go 

8
เมื่อใดที่คุณจะต้องใช้ "กระทู้นับแสน"
Erlang, Go และ Rust อ้างสิทธิ์ทั้งหมดไม่ทางใดก็ทางหนึ่งซึ่งสนับสนุนการเขียนโปรแกรมพร้อมกันด้วย "threads" / coroutines ราคาถูก ไปคำถามที่พบบ่อยฯ : เป็นจริงในการสร้าง goroutines หลายแสนในพื้นที่ที่อยู่เดียวกัน The Rust Tutorialพูดว่า: เนื่องจากงานมีราคาถูกกว่าอย่างมากในการสร้างกว่าเธรดดั้งเดิม Rust สามารถสร้างงานพร้อมกันนับแสนในระบบ 32 บิตโดยทั่วไป เอกสารของ Erlangกล่าวว่า: ขนาดฮีพเริ่มต้นเริ่มต้นที่ 233 คำนั้นค่อนข้างอนุรักษ์นิยมเพื่อสนับสนุนระบบ Erlang ที่มีกระบวนการหลายแสนหรือหลายล้านกระบวนการ คำถามของฉัน: แอปพลิเคชั่นประเภทใดที่ต้องการเธรดการทำงานพร้อมกันจำนวนมาก? มีเพียงเว็บเซิร์ฟเวอร์ที่ยุ่งที่สุดเท่านั้นที่จะได้รับผู้เยี่ยมชมหลายพันคนพร้อมกัน แอปพลิเคชั่นประเภทบอส - คนงาน / การส่งงานที่ฉันเขียน Hit ลดลงส่งคืนเมื่อจำนวนเธรด / กระบวนการมากกว่าจำนวนแกนประมวลผลทางกายภาพมาก ฉันคิดว่ามันสมเหตุสมผลสำหรับแอปพลิเคชั่นตัวเลข แต่ในความเป็นจริงคนส่วนใหญ่มอบหมายให้ขนานกับไลบรารีของบุคคลที่สามที่เขียนใน Fortran / C / C ++ ไม่ใช่ภาษารุ่นใหม่กว่านี้

1
การอนุมาน Hindley-Milner สามารถทำงานกับภาษา Go ได้หรือไม่
ฉันอ่านแล้วว่าHindley-Milnerไม่ทำงานกับระบบพิมพ์ที่มีคลาสย่อยและมีคุณสมบัติของระบบประเภทอื่น ๆ ที่ใช้งานไม่ได้กับมัน ไปในขณะนี้มีข้อสรุปประเภท จำกัด มากใน:=ผู้ประกอบการ แต่ Go ไม่ได้มี subclasses ในความหมายดั้งเดิมมีเพียงอินเตอร์เฟสที่มีลักษณะคล้ายกับคลาสของ Haskell ซึ่งทำงานได้ดีกับการอนุมาน Hindley-Milner ดังนั้นการอนุมานของ Hindley-Milner สามารถทำงานได้ในหลักการของ Go แบบเดียวกับ Haskell หรือไม่? หรือไปมีคุณสมบัติอื่น ๆ ที่ทำลายมันได้หรือไม่ (ในทางกลับกัน Haskell ยังมีคุณสมบัติบางอย่างที่ไม่สามารถใช้กับ Hindly-Milner ได้หากคุณใช้สิ่งที่คุณต้องพิมพ์ด้วยตนเองในส่วนของโปรแกรม)

1
Go ปรับปรุงประสิทธิภาพการทำงานด้วยอินเทอร์เฟซ“ นัย” อย่างไรและเปรียบเทียบกับแนวคิดของ C # ของวิธีการขยายอย่างไร
ในการสอนภาษาไปพวกเขาอธิบายว่าอินเตอร์เฟสทำงานอย่างไร: Go ไม่มีคลาส อย่างไรก็ตามคุณสามารถกำหนดวิธีการกับประเภทโครงสร้าง รับวิธีการที่ปรากฏในรายการอาร์กิวเมนต์ของตัวเองระหว่างคำหลัก func และชื่อวิธีการ type Vertex struct { X, Y float64 } func (v *Vertex) Abs() float64 { return math.Sqrt(v.X*v.X + v.Y*v.Y) } ประเภทอินเตอร์เฟสถูกกำหนดโดยชุดวิธีการ ค่าประเภทอินเตอร์เฟสสามารถเก็บค่าใดก็ได้ที่ใช้วิธีการเหล่านั้น นี่เป็นวิธีเดียวในการสร้างส่วนต่อประสานใน Go Google อธิบายเพิ่มเติมว่า: ชนิดที่ใช้อินเทอร์เฟซโดยใช้วิธีการ ไม่มีการประกาศเจตนาอย่างชัดเจน [ interfaceการประกาศเช่น] อินเทอร์เฟซโดยนัย decouple ใช้งานแพคเกจจากแพคเกจที่กำหนดอินเทอร์เฟซ: ไม่ขึ้นอยู่กับอีก นอกจากนี้ยังสนับสนุนการกำหนดอินเทอร์เฟซที่แม่นยำเนื่องจากคุณไม่จำเป็นต้องค้นหาทุกการติดตั้งและติดแท็กด้วยชื่ออินเตอร์เฟสใหม่ ทั้งหมดนี้ฟังดูน่าสงสัยเช่นวิธีการขยายใน C #ยกเว้นวิธีการใน Go ที่เป็น polymorphic โหดเหี้ยม พวกเขาจะทำงานในประเภทใด ๆที่ใช้พวกเขา …
21 c#  language-design  go 

1
การเขียนโปรแกรม Erlang และ Go พร้อมกันความแตกต่างระหว่าง CSP และนักแสดง?
ฉันกำลังดูการเขียนโปรแกรมพร้อมกันในภาษาโปรแกรม Erlang และ Go ตามการค้นพบของฉันพวกเขาใช้โมเดลนักแสดงและ CSP ตามลำดับ แต่ฉันก็ยังสับสนกับ CSP และนักแสดงต่างกันอย่างไร มันแตกต่างทางทฤษฎีเพียงอย่างเดียว แต่เป็นแนวคิดเดียวกันหรือไม่

3
ข้อดีของไวยากรณ์ภาษาจากซ้ายไปขวา
ฉันได้ดูบทสัมภาษณ์ของ Herb Sutter ที่ช่อง 9 และเขาพูดถึงตอนท้ายของวิดีโอว่าไวยากรณ์ของภาษาซ้าย - ขวาจะอยู่ในอันดับต้น ๆ ของนักแปลเพื่อมาตรฐาน C ++ ในอนาคต (แม้ว่าเขาจะยอมรับว่าการดัดแปลง C ++ ด้วยวิธีนั้น จะทำให้สัตว์ร้ายต่างไปจากเดิมอย่างสิ้นเชิง) นอกเหนือจาก: มนุษย์สามารถเข้าใจได้ชัดเจนขึ้นด้วยตาเปล่าเช่น //C syntax /*pointer to function taking a pointer to function(which takes 2 integers as arguments and returns an int), and an int as arguments and returning an int*/ int (*fp)(int …

5
ห้องสมุดทั่วไปเป็นความคิดที่ดีหรือไม่?
ฉันมักจะคิดว่า "ห้องสมุดทั่วไป" เป็นความคิดที่ดี โดยที่ฉันหมายถึงห้องสมุดที่มีฟังก์ชั่นทั่วไปที่มักจะต้องใช้งานโดยไม่กี่แอปพลิเคชันที่แตกต่างกัน มันส่งผลให้รหัสซ้ำซ้อนน้อย / ซ้ำซ้อน ฉันเพิ่งอ่านบทความ (ไม่สามารถหาได้ตอนนี้) ที่บอกว่านี่เป็นความคิดที่เลวและจริง ๆ แล้วมันบอกว่ามันเป็น "รูปแบบต่อต้าน" ในขณะที่มีวิธีการนี้กลับหัว การกำหนดเวอร์ชันและการจัดการการเปลี่ยนแปลงหมายถึงการทดสอบการถดถอยสำหรับชุดแอพที่ใช้ไลบรารีนี้ ฉันติดอยู่ในร่องสำหรับโครงการใหม่ของฉัน (Golang) การขจัดความซ้ำซ้อนของรหัสได้รับการตอกย้ำเข้ามาในตัวฉันตลอดหลายปีที่ผ่านมา แต่ฉันรู้สึกว่าฉันควรลองในครั้งนี้ ในขณะที่เขียนสิ่งนี้ฉันเริ่มคิดว่าวิธีการ "lib ทั่วไป" นี้เป็นผลมาจากการข้ามสถาปัตยกรรม? บางทีการออกแบบของฉันต้องการความคิดมากกว่านี้ใช่ไหม สนใจฟังความคิด
16 design  go 

1
ทำไมโกลังเลิกแพ็คเกจ“ netchan”?
แพ็คเกจ "netchan" ของ Golang ดูเหมือนจะถูกยกเลิก นั่นทำให้ฉันคิดว่าแนวคิดของ "ช่องทางเครือข่าย" ไม่ใช่วิธีปฏิบัติที่ดี (ทำไมพวกเขาถึงไม่ "ปล่อยให้เป็นอย่างอื่น") เป็นกรณีนี้หรือไม่? และถ้าเป็นเช่นนั้นทำไม
16 networking  go 

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.