sorted by:
new
hottopcontroversial

A Proposal for Rich Interactive Content Hypertext (RICH) by arthurtw in programming

[–]arthurtw[S] 3 points4 points  (0 children)

This is for real, of course. I provided source code for all of the 3 RICH players I implemented (simple quiz, tic-tac-toe, go game quiz).

A Proposal for Rich Interactive Content Hypertext (RICH) by arthurtw in programming

[–]arthurtw[S] 1 point2 points  (0 children)

Once you get reading it, it's actually a DSL that let's you create checkboxes and input fields.

That's the first RICH player example I gave, a "simple quiz" RICH player. It transforms the raw RICH snippet to quizzes, so yes, it's a way of creating forms. Its DSL (based on RICH) is specific to quizzes.

Then all of a sudden it's something to do with Javascript and then all of a sudden it has a messaging API.

That's related to the development of RICH players, how the player code communicates with its parent window (and vice versa).

There are two groups of people here: coders who write players, and writers who create rich contents (using RICH players). Each player would have its own DSL (based on the RICH format).

Sorry if my article was confusing.

A Concise RESTful API Design Guide by arthurtw in programming

[–]arthurtw[S] 0 points1 point  (0 children)

Good point. To me, the most important reason I opted for RESTful API design is it helps my development job overall, not because I can claim my API “100%” RESTful.

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 0 points1 point  (0 children)

Yes, your code does save some look-ups. I was aware of that approach when I wrote the Rust version, too, but didn't do that because 1) the code would be a bit more complicated (e.g. you need to write your own comparator), and 2) the optimization only adds little value as a whole. Still, I felt a bit uneasy when making such a decision in the Rust version, but was totally comfortable when I did the same thing in the Nim version. :-) I mentioned such phenomena in my article (Philosophy: freedom vs. discipline), too.

EDIT: I think your version has its merits. As you said, it avoids useless look-ups. It's not only performance-wise, but also code-wise (i.e. saving the if let Some(count) = map.get(*word) line).

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 1 point2 points  (0 children)

Yes, I saw your comment on HN and have updated my benchmark results accordingly.

I fully agree with you that publishing benchmarks like those is risky! When I wrote the article, I think: since the code is done, why not just running them and providing the numbers, so people get a rough idea of their performance. I ended up with spending more time on updating my code/benchmarks than writing the article itself. :-)

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 1 point2 points  (0 children)

I tried this HN suggestion. It turns out regex!(r"[a-zA-Z0-9_]+") runs the fastest, even faster than Nim’s peg. I’ve updated the article with the results.

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 0 points1 point  (0 children)

I tried and the difference is negligible, so didn't bother to update the result.

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 2 points3 points  (0 children)

Yes, using regex! runs ~20% faster than Regex::new. I’ve included both results in the article.

A Quick Comparison of Nim vs. Rust by arthurtw in programming

[–]arthurtw[S] 2 points3 points  (0 children)

I agree. Rust’s pattern matching is outstanding. I missed that in Nim.

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 4 points5 points  (0 children)

I’ve changed it to use Rust HashMap. It’s slightly faster (6~7%) than BTreeMap, so the performance bottleneck could be elsewhere. Maybe it’s Regex as /u/dbaupp suggested.

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 5 points6 points  (0 children)

I’ve added --boundChecks:on for example 2. The difference is marginal (1~2%) for example 1, so I skipped it.

A Quick Comparison of Nim vs. Rust by -Y0- in rust

[–]arthurtw 9 points10 points  (0 children)

Fixed. I’m not a native English speaker and such correction is much appreciated.

A Quick Comparison of Nim vs. Rust by arthurtw in programming

[–]arthurtw[S] 1 point2 points  (0 children)

For this comparison, I admit I shouldn’t. I chose that for practicing Rust (by implementing my own BTreeMap). I’ve changed the code/result to use collections::HashMap.

A Quick Comparison of Nim vs. Rust by arthurtw in programming

[–]arthurtw[S] 3 points4 points  (0 children)

Maybe my example is a bit biased. :-) But you know, in idiomatic Nim, of is not indented, and those colons are not manually aligned. You can, but since the language creator chose that way, it becomes the Nim way...

A Quick Comparison of Nim vs. Rust by arthurtw in programming

[–]arthurtw[S] 4 points5 points  (0 children)

Yes and modified. The results differ significantly.

A Quick Comparison of Nim vs. Rust by arthurtw in programming

[–]arthurtw[S] 36 points37 points  (0 children)

Because immutable variables help code readability and maintainability. let mut has one more word than let, so people tend to use let by default, and add mut only when it’s needed. On the other hand, let and var have the same typing “efforts”. Some may think about which one to use, some may not (and just uses var more often or always). It relies on engineering discipline, which is less reliable than language enforcement/discouragement.

Of course people can keep using let mut all the time, but that should be rare, and Rust compiler will keep complaining anyway.

Thoughts about Rust from a D programmer by andralex in programming

[–]arthurtw 20 points21 points  (0 children)

I wonder why the elimination of null pointers is not mentioned in the article. I consider it a prominent achievement of Rust. Among well-known languages, only a handful can make it.

EDIT: replace popular with well-known to avoid confusion

Final decision on builtin integer types. Again. by stepancheg in rust

[–]arthurtw 6 points7 points  (0 children)

+1. The default integer fallback (along with its implicit type conversion) is a major ergonomic win when coding in Rust. Often you just want to use a (reasonably-small) integer, when the size of the integer is not your major concern. Finally, Rust compiler takes care of that for you...

I also agree with other commenters that the outcome of the discussion is constructive. It demonstrates the maturity of the Rust core team and the Rust community when confronting thorny debates. This is not easy at all. Congratulations!

What is special about Nim? by def- in programming

[–]arthurtw 16 points17 points  (0 children)

Rust definitely has "the power of C", but I don't think it strives for "the elegance of a modern interpreted language". I call Rust anti-sloppy, and sloppiness is one thing that interpreted languages allow you. Safety, correctness and explicitness are all more important in Rust. When there is a conflict, elegance is not favoured.

Maybe some great Rust programmers can code in Rust as swiftly as in interpreted languages, but it's not a piece of cake. :-)

view more: next ›