2020年5月13日水曜日

Vプログラミング言語がベンチマーク結果で最速です。 V programming language is the fastest in the benchmark results.

二つのベンチマークのブログでは、V言語が全てのプログラミング言語の中で最速となっております。あとはRustの様にメモリーリーク対策などのセキュリティ対策がしっかり施されている事を期待しております。

In the two benchmark blogs, the V language is the fastest of all programming languages. Also, I'm hoping that security measures such as memory leak prevention will be provided as well as Rust's.


https://techracho.bpsinc.jp/hachi8833/2020_03_13/89457
Shared.
Comment: Among the programming languages, V is the fastest.
コメント:プログラム言語の中でV言語が一番早いですね。

https://vlang.io/compilation_speed
Shared.



Comment: The benchmark results show that the V language is the fastest.

The feature is a simple structure, similar to Go language, and

It's being developed for strong concurrent processing such as multi-threading.

Since there is no garbage collection, it is suitable for mission-critical database systems such as online banking systems, online credit card systems, and online game servers that process more than 100,000 transactions per second.

I hope, like Rust, that you make security checks such as memory leaks strictly by compile-time checks.


The following is an example of how to unify the source code and maintain the quality of the source code during development in Rust.

It's about whether they can be secured.
Consistency of source code on a team basis in the programming language Rust (to reduce the variation of code styles on a team, to ensure the quality of the code, and to prevent the code from becoming a technical liability in case it becomes unreadable later on)
On Slack
Thank you very much.
https://rust-jp.slack.com/archives/C8FLSR5F1/p1581424953112100
Reprinted (shared) for study purposes.

Masahiro Ishizuka 9:42 PM
I used to think that Golang was the best for team development and unity, but how about Rust? Is it easy to get out?

Pen name 9:49 PM
The default directory placement (src for source, target for output, src/lib.rs and src/main.rs for source entry points)
The fact that rustfmt is officially distributed and the default settings are widely used
The official distribution of clippy
There is also documentation such as API guidelines.
I think it's relatively easy to keep the variation in chord style down from the point of view of the following

Masahiro Ishizuka 11:00 PM
pen name
Thank you for your reply.
To add, is it easy for source code to be similar in a good way no matter who writes it, and easy for source code to be non-personal and non-individualistic in a good way no matter who writes it?

Pen name 11:08 PM
That's pretty hard to answer, but at least it's unlikely to introduce a large number of notations that are "mostly just different in syntax" like Perl or Ruby.
11:11
For example, in Ruby, you can write ["foo", "bar"] or %w[foo bar] or %W|foo bar|, or puts("foo") or puts('foo') or puts "foo", but it doesn't get this diverse. (But it's not entirely absent, for example, there are two notations for string literals in Rust, regular and raw string literals, and "foo" and r#"foo "# can mean the same thing)
11:13
However, for example, when dealing with data structures, there are two ways to describe them roughly: procedurally and functionally, and there are some differences in the way modules are cut and encapsulated.
11:14
I can give individual examples like this, but I don't think it's easy to argue for "unity" objectively when viewed as a whole.

Pen name 11:20 PM
Rust also has a policy of keeping the standard libraries small (in the sense that they are bundled with the compiler) and assuming the use of a large number of "de facto standard" libraries (some of which are maintained in a close to official form, some of which are not). While there are many that already have de facto standards (rand, regex, log, serde, chrono, crossbeam, etc.), there are still some genres where libraries are in disarray. For example, in the asynchronous ecosystem, TOKIO and ASYNC_STD are the two major forces, and it is not easy to straddle between them, so it is interesting to see what happens. Error contexts are also not yet out of the messy state of error-chain, failure, fehler, snafu, anyhow, etc. (I think the error context is similar to pkg/errors, go-errors/errors, etc. in golang)

Masahiro Ishizuka 11:25 PM
Thank you for the additional response.
In that sense, it seems that there are few variations or types of source code writing.
If you also know Python and Go, do you find that when you compare Rust with Python and Golang, it's easier to create a sense of unity and less variability across the team, even though there are fewer meetings and meetings when developing with a team?
For example, there are some people who write source code with a lot of personality, or the style is so unique that the chances of rewriting the source code as a result of the overall review seems low, but what kind of image do you have? I think it's somewhat unavoidable that there are different ways to write.

Pen name 11:31 PM
It's difficult because it depends too much on the degree of "individuality"... For example, there are standards for casing function names and variable names, and the compiler will warn you if you set the function name to camelCase or the constant to lower_snake_case (e.g., https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4d1d54de1e07b62a06f66a89de822994 ). If you are a person who sees these compiler default warnings properly, I think you can guarantee a certain level of sanity.
11:33
Also, there is a linting tool called clippy that is officially distributed, and it has many lints that are not included in the compiler itself, including "lint with false positives" and "lint that is not necessarily recommended by the Rust community, but can be activated if necessary for each project". (A list of lint can be found here: https://rust-lang.github.io/rust-clippy/ )
11:36
You can adjust the settings to some extent, whether it's a compiler warning or a clippy lint. Configuration can be done in the top level file (lib.rs / main.rs) or clippy.toml on the Rust side, so if you write the configuration, it will be reflected in all programmers' development environment. So, I think there is room to adjust the degree of "richness of personality" by these settings if necessary.

Pen name 11:43 PM
By the way, we're talking about a sense of unity now, but I think we're actually looking for a sense of unity as a tool to ensure the quality of the code and to prevent the code from becoming unreadable later and becoming a technical liability.

Masahiro Ishizuka 11:45 PM
Thank you for the additional answer.
Well, that's great!
This is the first time I've ever heard of lint. I'm going to do a Google search tomorrow and see what I can find.
So there's room to adjust the degree of individuality.
That's how I would define unity.

  11:47 PM.
In that sense, Rust is a language that places a high priority on protecting programmers from writing bad code as much as possible (often likened to "stopping the footgun"), and on keeping the traceability of source code behavior intact regardless of quality, so that's worth considering.

Masahiro Ishizuka 11:51 PM
Thank you for the additional answer.
Well, I thought Rust was a well-considered language about unity.
I would like to use it as soon as possible to develop a website and recommend it to others with confidence.
Thank you very much for answering my question until midnight.

Information-only supporter WEB programmer Masahiro Ishizuka (Akiruno City, Tokyo)


コメント:ベンチマーク結果は、V言語が最速なのが分かります。
特徴は、Go言語に似てシンプルな構造で、
マルチスレッドなどの並行処理が強い事を目指して開発中だそうです。
ガベージコレクションが無いので、固まったりノンストップである前提なオンラインバンクシステムやオンラインクレジットカードシステムやオンラインゲームサーバーなど一秒間に10万件以上の処理などがある様なミッションクリティカルなデータベースシステムに向いております。
願わくは、Rustの様にコンパイル時のチェックで、メモリーリークなどのセキュリティ上のチェックを厳密にして頂きたいと願います。

以下はRustでのチームでの開発時のソースコードの統一感を出し一定の品質を
担保出来るかについてです。

プログラミング言語Rustでのチームでのソースコードの統一感について(チームでのコードスタイルのばらつきを抑え、コードの品質を担保し、あとでコードが読めなくなってしまった場合の、技術的負債と化すことを防ぐ)
Slackにて
ありがとう御座います。
https://rust-jp.slack.com/archives/C8FLSR5F1/p1581424953112100
勉強の為に転載(シェア)しました。

石塚 正浩  9:42 PM
以前は、Golangが一番チームでの開発性と統一感を出すのに優れていると思いましたが、Rustはチームでの開発時の統一感など、はいかがでしょうか?出しやすいでしょうか?

ペンネーム  9:49 PM
ディレクトリ配置のデフォルトが決まっている (ソースは src , 出力先は target, ソースのエントリポイントは src/lib.rs と src/main.rs ) 点
rustfmtが公式で配布されていて、デフォルト設定が広く採用されている点
clippyが公式で配布されている点
API guidelinesなどのドキュメントも存在する点
などの点でみれば、比較的コードスタイルのばらつきは抑えやすいのではないかと思います。

石塚 正浩  11:00 PM
ペンネーム
御回答ありがとうございます。
更に付け加えますと、ソースコードは、誰が書いても良い意味で同じ様なソースコードになりやすく、良い意味で非個性で、個性豊かではないソースコードの書き方になりやすいですか?

ペンネーム  11:08 PM
それはかなり答えづらいですが、少なくともPerlやRubyのように「ほとんど構文が違うだけ」の多数の表記を導入することはほぼないですね。
11:11
たとえばRubyだと ["foo", "bar"] とも %w[foo bar] とも %W|foo bar| とも書けますし、 puts("foo") とも puts('foo') とも puts "foo" とも書けますが、ここまで多様になることはないです。 (とはいえやはり全くないわけではなく、たとえばRustでの文字列リテラルには通常の文字列リテラルとraw文字列リテラルの2つの記法があり、 "foo" と r#"foo"# は同じ意味になります)
11:13
しかしたとえば、データ構造を扱うときは大まかには手続き的に記述する方法と関数型プログラミング的に記述する方法がありますし、モジュールの切り方やカプセル化の方法にも多少の流儀の差はあったりします。
11:14
こういう個別的な例は出せますが、総合的に見たときに客観的に「統一感」を論じるのは簡単ではないなと思います。

ペンネーム  11:20 PM
またRustでは(コンパイラに同梱されるという意味での)標準ライブラリを小さく保ち、「事実上の標準」にあたる多数のライブラリ(公式に近い形でメンテされているものもあれば、そうでないものもある)を使うことを前提にするという方針があります。すでに事実上の標準が確立されているもの(rand, regex, log, serde, chrono, crossbeamなど)も多数ある一方、まだライブラリが乱立しているジャンルもあります。たとえば非同期エコシステムではtokioとasync_stdが2大勢力となっていて、これらの間を跨ぐのは容易ではないためどうなるかが注目されています。エラーコンテキストもerror-chain, failure, fehler, snafu, anyhowなど乱立状態からまだ抜け出せていません。(エラーコンテキストについてはgolangでもpkg/errors, go-errors/errorsなど似たような状態かと思います)

石塚 正浩  11:25 PM
追加回答ありがとうございます。
そう言う意味では、ソースコードの書き方のバリエーションと言うか種類は、概ね少ない様ですね。
もしPythonやGoもご存知でしたら、PythonやGolangとRustを比較すると、チームで開発した時に会議や打ち合わせの回数が少なくても、統一感を比較的出しやすいと言うか、チーム全体のバラツキが少なくなりそうな感じがRustには、ありますでしょうか?
例えば、中には個性豊かにソースコードを書いてしまう人がいたり、流派が独特な感じがひどくて、全体レビューの結果、ソースコードを書き直しで出戻りが発生したりする可能性は、低そうですが、どんなイメージでしょうか?書き方に種類が、あるのは、多少仕方ないかとは、思います。

ペンネーム  11:31 PM
「個性豊か」の度合い次第すぎるので難しいですが…… たとえば関数名や変数名のケーシングには標準があり、関数名をcamelCaseにしたり定数をlower_snake_caseにしたりするとコンパイラが警告を出します (例→ https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4d1d54de1e07b62a06f66a89de822994 )。こういったコンパイラのデフォルトの警告をちゃんと見る人であれば、ある程度の正気度は保証できる気はします。
11:33
また、clippyというリントツールが公式で配布されており、こちらには「偽陽性のあるリント」や「Rustコミュニティーとして必ずしも推奨するわけではないが、プロジェクトごとに必要であれば有効化できるリント」も含めてコンパイラ本体にはないリントが多数用意されています。 (リントの一覧がここで見られます: https://rust-lang.github.io/rust-clippy/ )
11:36
コンパイラの警告にしても、clippyのリントにしても、設定をある程度調整できます。設定はRust側のトップレベルのファイル (lib.rs / main.rs) や clippy.toml 内でできるので、設定を書いておけばそのまま全てのプログラマの開発環境に反映されます。なので、必要であればこれらの設定によって「個性豊か」度合いを調整できる余地もあると思います。

ペンネーム  11:43 PM
ところで、「統一感」の話をいまはしていますが、実際のところは「コードの品質を担保する」ことや、「あとでコードが読めなくなってしまい、技術的負債と化すことを防ぐ」といったことを達成するための道具として「統一感」を求めていると思いますが、どうでしょうか?

石塚 正浩  11:45 PM
追加回答ありがとう御座います。
なるほど素晴らしい!
リントなる物は、初めて知りました。明日 Google検索して見ようと思います。
個性豊かの度合いを調整出来る余地があるのですね。
統一感についての定義は、その様な感じになります。

  11:47 PM
その意味でいうと、Rustはプログラマがよくないコードを書いてしまわないようにできるだけ保護すること (よく「footgunを阻止する」と喩えられています) や、品質にかかわらずソースコードの動作の追跡性を損なわないようにすることを重要視している言語なので、その点は考慮に値すると思います。

石塚 正浩  11:51 PM
追加回答ありがとう御座います。
なるほど、Rustは、統一感について、良く考慮された言語だと思いました。
自分でも、これから、早く使いこなしてWEBサイトなどを開発していきたいですし、人にも自信を持って勧めていきたいと思います。
夜分まで回答して頂きましてありがとう御座いました。


19インチラックマウント上のメインフレーム(汎用機)の上で動くLINUXの上で各プログラムのシステムが高速で安定して動作します。The system of each program runs at high speed and stable on LINUX running on the main frame (general-purpose machine) on a 19-inch rack mount.

Link is here English version

Link is here Japanese version

0 コメント:

コメントを投稿