アカウント名:
パスワード:
Google的にはGoじゃダメな理由があるんだろうか。Goに移行するのに比べれば、iOSでも使えるSwiftに移行する方が反発が少ないと考えたのかな。
Go言語は、C言語と同等の移植性をあるバイナリを出力出来る代わりに、実現できる言語機能に制限が有る。
関数の多重定義とか、ソースコード内では、同じ名前の関数があっても問題ないが、コンパイル後のバイナリに複数の関数を同じシンボル名を埋め込むことは出来ない。そういう理由があって Go言語は関数の多重定義が出来ないし、ジェネリックな関数も定義できない、
その手の機能を追加するとC++の様な名前修飾をやる必要が出てきて、シンボル名が訳のわからない名前になり、他のバイナリや言語から呼び出すことが困難になってC++と同じような永遠にC言語を置き換えられない言語になってしまうわけだ。
Swiftが候補に上がる理由は、最近の言語は構文解析が高速にできるという基準で文法が定義されているので。似たような文法になってしまい、わざわざ新言語る理由がないからだろう。まぁSwiftよりかは android studioで使える JetBrains製のkotlinが手っ取り早いとは思うけれど
Kotlinは開発観点でみれば申し分ないと思うけど、今直面している問題の解決にはならないでしょ。
> その手の機能を追加するとC++の様な名前修飾をやる必要が出てきて、> シンボル名が訳のわからない名前になり、他のバイナリや言語から呼び出すことが困難になって> C++と同じような永遠にC言語を置き換えられない言語になってしまうわけだ。
外部に公開するシンボルはextern "C"すればいいだけでは? 今どきWindowsのDLLとか外部にエクスポートされている関数はCリンケージに見えてもほぼC++に置き換えられているけど?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
Goじゃないんだ (スコア:1)
Google的にはGoじゃダメな理由があるんだろうか。
Goに移行するのに比べれば、iOSでも使えるSwiftに移行する方が反発が少ないと考えたのかな。
Re:Goじゃないんだ (スコア:4, 興味深い)
Go言語は、C言語と同等の移植性をあるバイナリを出力出来る代わりに、実現できる言語機能に制限が有る。
関数の多重定義とか、ソースコード内では、同じ名前の関数があっても問題ないが、
コンパイル後のバイナリに複数の関数を同じシンボル名を埋め込むことは出来ない。
そういう理由があって Go言語は関数の多重定義が出来ないし、ジェネリックな関数も定義できない、
その手の機能を追加するとC++の様な名前修飾をやる必要が出てきて、
シンボル名が訳のわからない名前になり、他のバイナリや言語から呼び出すことが困難になって
C++と同じような永遠にC言語を置き換えられない言語になってしまうわけだ。
Swiftが候補に上がる理由は、
最近の言語は構文解析が高速にできるという基準で文法が定義されているので。
似たような文法になってしまい、わざわざ新言語る理由がないからだろう。
まぁSwiftよりかは android studioで使える JetBrains製のkotlinが手っ取り早いとは思うけれど
Re: (スコア:0)
Kotlinは開発観点でみれば申し分ないと思うけど、今直面している問題の解決にはならないでしょ。
Re: (スコア:0)
> その手の機能を追加するとC++の様な名前修飾をやる必要が出てきて、
> シンボル名が訳のわからない名前になり、他のバイナリや言語から呼び出すことが困難になって
> C++と同じような永遠にC言語を置き換えられない言語になってしまうわけだ。
外部に公開するシンボルはextern "C"すればいいだけでは? 今どきWindowsのDLLとか外部にエクスポートされている関数はCリンケージに見えてもほぼC++に置き換えられているけど?