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でのチームでのソースコードの統一感について（チームでのコードスタイルのばらつきを抑え、コードの品質を担保し、あとでコードが読めなくなってしまった場合の、技術的負債と化すことを防ぐ）
Shared.
コメント：プログラム言語の中で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でのチームでの開発時のソースコードの統一感を出し一定の品質を
担保出来るかについてです。
0 件のコメント:
コメントを投稿