タグ付けされた質問 「go」

私は本当にGoogle golangが好きですが、実装者が標準ライブラリのセットなどの基本的なデータ構造を省略した理由は何ですか？

69 programming-languages  data-structures  go 

私はGoに比較的精通しており、小さなプログラムをいくつか書いています。錆は、もちろん、あまり馴染みがありませんが、注視しています。 最近http://yager.io/programming/go.htmlを読んで、Genericsが処理される2つの方法を個人的に調べたいと思いました。エレガントに達成できませんでした。私は、Rustの特徴がいかに強力であるかについての誇大宣伝を聞き続けました。Goでいくつかの経験を積んで、それがどのように真実であり、最終的にどのような違いがあったのかと思いました。私が見つけたのは、特性とインターフェースがかなり似ているということです！最終的に、私は何かが欠けているかどうかわからないので、ここでそれらの類似点の簡単な教育的要約があります。 それでは、ドキュメントからGoインターフェイスを見てみましょう。 Goのインターフェイスは、オブジェクトの動作を指定する方法を提供します。これができる場合は、ここで使用できます。 最も一般的なインターフェイスはStringer、オブジェクトを表す文字列を返すことです。 type Stringer interface { String() string } そのため、そのString()上で定義されているStringerオブジェクトはすべてオブジェクトです。これfunc (s Stringer) print()は、ほとんどすべてのオブジェクトを取得して印刷するようなタイプシグネチャで使用できます。 またinterface{}、いずれのオブジェクトも受け取ります。その後、実行時にリフレクションを介してタイプを決定する必要があります。 それでは、ドキュメントからRust Traitsを見てみましょう： 最も単純な場合、特性はゼロ個以上のメソッドシグネチャのセットです。たとえば、単一のメソッドシグネチャを使用して、コンソールに出力できるものに対して特性Printableを宣言できます。 trait Printable { fn print(&self); } これは、すぐにGoインターフェースに非常によく似ています。私が見る唯一の違いは、単にメソッドを定義するのではなく、特性の「実装」を定義することです。だから、私たちはやる impl Printable for int { fn print(&self) { println!("{}", *self) } } の代わりに fn print(a: int) { ... } ボーナス質問：特性を実装するが使用しない関数を定義すると、Rustで何が起こりますimplか？うまくいきませんか？ Goのインターフェイスとは異なり、Rustの型システムには型パラメーターがありinterface{}、コンパイラーとランタイムが実際に型を認識している間、適切なジェネリックなどを実行できます。例えば、 trait Seq<T> …

64 go  rust 

ここで誰がGoを学習していますか？他の企業はそれを使用することを検討していますか？広く使用される可能性はありますか？

58 go 

なぜnewGoに参加したのか、まだ戸惑っています。 構造体をインスタンス化したいときは、 t := Thing{} すると、新しいインスタンスへのポインタを取得できます t := &Thing{} しかし、この可能性もあります： t := new(Thing) この最後のものは、他の言語とは少し違うようです。&Thing{}と同じくらい明確で簡潔でnew(Thing)あり、他の場所でよく使用する構成体のみを使用します。また、&Thing{3}またはに 変更する可能性があるため、より拡張可能です&Thing{Feets:7}。 私の意見では、補助キーワード1を使用するとコストがかかり、言語がより複雑になり、知っておくべきことが追加されます。そして、構造体のインスタンス化の背後にあるものを、新規参入者に隠すかもしれません。 また、もう1つ予約語を作成します。 それでは、背後にある理由はnew何ですか？それは時々便利ですか？それを使うべきですか？ 1：はい、文法レベルではキーワードではないことを知っています。シャドウできますが、合理的な開発者にとって予約語であるという事実は変わりません。

49 go 

ここでの解説は、グリーンスレッドの以下の批判を提供しています： 私は当初、コールバック地獄のないイベント駆動型プログラミングの手段としてN：Mモデルで販売されていました。古い手続き型コードのように見えるコードを書くことができますが、その下には、何かがブロックされるたびにユーザースペースのタスク切り替えを使用する魔法があります。いいね。問題は、複雑さをより複雑に解決することになるということです。swapcontext（）およびファミリはかなり単純であり、複雑さは他の意図しない場所に由来します。 突然、ユーザー空間のスケジューラーを書くことを余儀なくされ、何年もかけて努力を重ねてきたLinuxのスケジュールよりも良い仕事をするスケジューラーを書くのは本当に難しいと思います。ここで、N個の緑色のスレッドからM個の物理的なスレッドをスケジュールして、同期を心配する必要があります。同期はパフォーマンスの問題を引き起こすため、新しいロックレスウサギの穴を掘って今すぐ始めます。正確で高度な並行スケジューラーを構築するのは簡単なことではありません。 別の批評はここにあります： 複数のスレッドを偽装する単一のプロセスには、多くの問題があります。その1つは、偽のスレッドがすべてページフォールトで停止することです。 私の質問は- されて行く-LANGのゴルーチン（デフォルトプール用）ちょうどグリーンスレッド？もしそうなら-彼らは上記の批判に対処しますか？

47 concurrency  go  multithreading 

Goは、「金属に近い」状態で実行されるはずの数少ない言語の1つです。つまり、コンパイルされ、静的に型指定され、VMなしでネイティブにコードを実行します。これにより、Java、C＃などよりも速度が向上します。ただし、Javaの背後にあるようです（プログラミング言語のShootoutを参照） 成熟度の低いコンパイラがこれに大きな責任を負っていると仮定していますが、他の理由はありますか？Goの設計に固有のものはありますか。たとえば、Javaよりも速く動作することを妨げるものはありますか。私はランタイムモデルについて非常に洗練された見方をしていますが、少なくとも原則として、ネイティブコードの実行のおかげで、Javaよりも速く実行できるはずです。

39 language-design  optimization  go 

Go言語についてはかなり読みましたが、有望なようです。言語にもっと労力をかけることに決める前に不足している最後の重要な情報は、次のとおりです。この情報を提供できない場合、プロジェクトへのGoogleのコミットメントを示す他の情報はありますか。新しい投資などの主要言語として使用されていますか（これには早すぎますが、わかりません）。

35 programming-languages  google  go 

私はGoを使用して新しいプロジェクトに取り組んでおり、私たちは全員Goに新しいです。標準のgoディレクトリ構造に従い、すべてのコードを $ GOPATH / src / github.com / companyname / projectname gitリポジトリのルートでもあります 標準の推奨パスレイアウトは、特にGoベースのrest / httpバックエンドやhtml / javascriptフロントエンドなどの多言語プロジェクトで作業している場合、少し奇妙に見えます。その場合、プロジェクト構造を次のようにしたいと思うでしょう。 / doc/ src/ server/ main.go module1/ module.go client/ index.html Makefile しかし、実際にはGOPATH内にコードを配置する必要がありますか？ 試みとして、ソースコードがGOPATHの外にある小さなプログラムを作成しました。プロジェクトをパッケージに簡単に分割できるので、mainパッケージはを使用fooしてfoo/フォルダー内のパッケージを参照できますimport "./foo"。 私が見る限り、これが私を許さない2つのことがあります： 他のコードはこのコードをインポートできません。これは、企業向けのサービスを構築しているため、問題ではありません。 go installインストールに使用できません。これも問題ではありません。ビルドパイプラインはツールをインストールします。 ただし、ビルドサーバーはワークスペースをGOPATH内に配置できません。 そのようなアプローチは推奨されませんか？もしそうなら、なぜそうですか？ リストした2つ以外のマイナスの副作用はありますか？ これは企業のプライベートプロジェクトであり、公開のオープンソースコードではないことに注意してください。 GOPATHから実際のプロジェクトを切り離すのは魅力的ですが、Shuステージにいるときはルールを破る際には注意が必要です。

32 go 

Erlang、Go、およびRustはすべて、安価な「スレッド」/コルーチンを使用した同時プログラミングをサポートしていると何らかの形で主張しています。ゴーよくある質問の状態： 同じアドレス空間に数十万のゴルーチンを作成するのが実用的です。 錆チュートリアルは言います： タスクは従来のスレッドよりも作成コストが大幅に低いため、Rustは標準的な32ビットシステムで数十万の同時タスクを作成できます。 Erlangのドキュメントによると： 233ワードのデフォルトの初期ヒープサイズは、数十万または数百万のプロセスを持つErlangシステムをサポートするためにかなり控えめです。 私の質問：どんな種類のアプリケーションが非常に多くの同時実行スレッドを必要としますか？最も忙しいWebサーバーだけが、数千もの同時訪問者を受け取ります。私が書いたボスワーカー/ジョブディスパッチタイプのアプリケーションは、スレッド/プロセスの数が物理コアの数よりもはるかに多い場合に、リターンを減少させます。数値アプリケーションにとっては理にかなっていると思いますが、実際には、ほとんどの人はこれらの新しい世代の言語ではなく、Fortran / C / C ++で書かれたサードパーティのライブラリに並列処理を委任します。

31 multithreading  go  erlang 

私は、Hindley-Milnerがサブクラスを持つ型システムでは機能しないことを読みましたが、他の型システム機能でも機能しないことがあります。現在、Goでは:=演算子の型推論が非常に限られています。しかし、Goには伝統的な意味でのサブクラスはなく、Hindley-Milner推論で問題なく動作するHaskellの型クラスに非常によく似たインターフェースのみがあります。 それでは、Hindley-Milnerの推論は、Haskellの場合と同じように、Goでも原則的に機能しますか？それとも、Goには他の機能がありますか？（一方で、HaskellにはHindly-Milnerで動作しない機能もあります。これらを使用すると、プログラムのこれらの部分を手動で入力する必要があります。）

22 haskell  type-systems  go 

Go言語のチュートリアルでは、インターフェイスの仕組みについて説明しています。 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宣言]。 暗黙的なインターフェースは、実装パッケージをインターフェースを定義するパッケージから分離します。どちらも他に依存しません。 また、すべての実装を見つけて新しいインターフェイス名でタグ付けする必要がないため、正確なインターフェイスの定義も推奨されます。 これはすべて、Goのメソッドが容赦なく多態的であることを除いて、C＃の拡張メソッドに似ています。それらは、それらを実装する任意のタイプで動作します。 Googleは、これが急速な開発を促進すると主張していますが、なぜですか？C＃の明示的なインターフェイスから離れることで何かをあきらめますか？C＃の拡張メソッドにより、GoインターフェイスがC＃に持つ利点のいくつかを引き出すことができますか？

21 c#  language-design  go 

私はErlangとGoプログラミング言語での並行プログラミングを検討していました。私の発見によると、それらはそれぞれアクターモデルとCSPを使用しています。 しかし、それでも私はCSPとアクターの客観的な違いは何かと混乱していますか？それは単に理論的に異なるだけで同じ概念ですか？

19 programming-languages  concurrency  concepts  go  erlang 

私はChannel9 でハーブサッターとのインタビューを見ていましたが、彼はビデオの最後で、左から右への言語構文が将来の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 (*ff)(int x, int y), int b) //Go analogous syntax which is left to write …

18 c++  c  programming-languages  go 

私はいつも「共通ライブラリ」が良いアイデアだと思っていました。つまり、いくつかの異なるアプリケーションでしばしば必要とされる共通の機能を含むライブラリを意味します。コードの重複/冗長性が少なくなります。 私は最近、これは実際には悪い考えであり、「アンチパターン」であると言ったほどの記事を見つけました（今は見つかりません）。 このアプローチには利点がありますが。バージョン管理と変更管理は、このライブラリを使用するアプリスイートの回帰テストを意味します。 私は、新しい（Golang）プロジェクトにちょっと不満を感じています。コードの重複排除は長年にわたって私に打ち込まれてきましたが、今回はそれを試してみるべきだと思います。 これを書いている間、私はこの「共通ライブラリ」アプローチがアーキテクチャのスキミングの結果であると考え始めていますか？おそらく私の設計にはもっと考えが必要ですか？ 考えを聞いて興味を持っています。

16 design  go 

Golang「netchan」パッケージは廃止されたようです。 結局、「ネットワーク化されたチャネル」の概念は良い習慣ではなかったと思います。（それ以外の場合、なぜ「そのまま」にしないのですか？） これは事実ですか？もしそうなら、なぜですか？

16 networking  go