sargas

How so?

This new logo looks sterile and boring, creativity-wise. It isn't clever neither. I'm excited for the official website redesign, however. It needs it.

That's really good information. I've stopped trusting Rotten Tomatoes not a long time ago. To be honest, I have stopped taking any "average" ratings for anything. At one point, I trusted those ratings for everything related to entertainment: movies, games, touristic places. But the truth is that the ones affected by reviews, that have power to influence it, will skew the perception, interpretation, and numbers of those reviews.

Neither it has been mine. I have written C and C++ only in college, so my impression might be very wrong, but I think that programmers who are proficient in low level languages are the ones that learn Rust the fastest due to the low level concepts Rust's compiler puts upfront such as sane memory management.

This is a bold statement, specially because not many other languages have such high quality guarantees at compile time.

> I already know it works

This is the part I don't agree all of the time, but depending on the scope and size of the project, I've seeing this be true. And the compiler is really good at catching regressions, submitting PRs for Rust projects is not easy in the beginning, but it is very hard to insert a regression.

That's your taste.

The semantics of Go are fine for the most part. My only problem with Go is manipulating slices. The rest is just awesome and it requires a lot of taste to simplify semantics without taking away the languages power.

And that's entirely possible.

And solve one problem by implanting another?

The fast/happiness graph of languages is pretty interesting.

Unrelated: Rust would probably be around the right-most area in the horizontal axis, close to C and C++, and a little below Go in the vertical axis.

That's great from beginner to master levels. Although master programmers call shots that are correct almost always :)

"Beginner programmers have a favorite language. Seasoned programmers have a language they hate the least." - Unknown Author

---

It is about the right tool for the job guys. All languages have something to hate on. Of course it is important to work with technology you like. Nothing wrong with this article, the guy is voicing his opinion. But this isn't a verdict on Go. People like Go for precisely the way it handles errors.

The learning pain is comparable to C pointers when you first see them haha. Funny thing is that after getting used to the borrow checker and other nice things of the language, its sad to go back to the languages I use at work.

Your article is great. The examples of functional and non-functional uses of Rust were neat. I've been practicing by doing the Rust track on exercism.io and, by comparing my solutions to others', I always get impressed by how equally performant those two versions are (at small programs at least).

The article itself points to a HN discussion: https://news.ycombinator.com/item?id=11774850

I didn't see it until it was mentioned here.

I can't seem to delete this discussion. So I added the original link here. Please head there.

That's a good way to get into the language, as long as you have someone to guide you through the borrow checker during the jam.

I just saw the link on to the first HN discussion. I don't what to divide the conversation into two HN posts. How do I proceed?

> Anyway, I'm very curious whether it ultimately turns out that, as advertised, Rust's performance characteristics really are as good or better than C++'s[1].

From my limited experience, Rust's performance is comparable to C++ throughout, with the added safety guarantees that Rust is known for.

I had fun reading this. How dare game programmers complain about their privileged positions in the entertainment and tech industries?

I almost thought he was serious. But even if he was being serious, the reading was fun and informative.

That's very insightful. So my understanding now it that Rust provides low level "blocks" that, as a whole, is an extensible language. Thus language vs standard library doesn't really matter, since Rust = Language spec + standard library. Am I getting close to its definition?

BTW, I remember in the alpha days when the decision was made to make Rust support concurrency in the standard library rather in the language itself. So in that sense (Rust = language spec + stdlib) Rust does have concurrency built-in.

Do you have an example of the behavior you're describing? The article offers a demonstration that seems to work as the author described:

https://play.rust-lang.org/?gist=5d3174958c76718508f6ab45660...

But now I'm curious. Aren't the characters in the example above comprised of multiple Unicode code points?

Thanks for the explanation.

Would you please clarify something to me?

1. So to say that a language has concurrency built-in is, in general, misleading, correct?

2. Than a language may have concurrency primitives, but the capability comes from C through the OS?

So you're looking for something like: https://wiki.theory.org/YourLanguageSucks#Ruby_sucks_because

This wiki is controversial to me, but sometimes useful.

Funny but mean.

I'm very excited for 1.0.x, type aliases and a library for concurrent programming are great news. Not to mention support for Java 7-9 bytecode generation.

Here's my perception of Rust: It is a system's low level language (more like C or C++) that is very expressive. It's performance is compared to C++, so faster than Go/Python/Java.

----------------------------------------

In term of expressiveness, it offers:

- Expression-based languages (instead of statement-based)

- Has anonymous functions (lambdas)

- It has a match mechanism which is powerful

- Enums are enumerated data-types rather then integer types

- Has traits and explicit implementation blocks for them (vs Go's implicit interface contracts)

----------------------------------------

Other than that, it also offers:

- Built-in concurrency

- It has a thing called the borrow checker that makes sure you're handling memory safely (this will get a little but of getting used to, but it is powerful)

- Everything is private by default. You put `pub` in front of an identifier if you want it to be public

- It isn't very verbose in the Java sense, but you still have to write a crap lot of code in comparison to Go and Python. The trade off is that the code is very explicit, and you get to type more in order to have zero cost abstractions at runtime

- Zero cost abstraction at runtime

Please correct me if any of those points are wrong/misleading, I'd love to learn more about Rust too.

I really like those improvements and features. Specially the Async/IO stuff, jobs, timers, and a stab at plugin packages.

This will be quite a long journey I think - an exciting one.

The other thing is that I think Vim and NeoVim will diverge at a faster rate now. They'll soon be way too different to be related. So NeoVim won't be a "nicer"/asynchronous/opinionated Vim anymore. But it's own alternative.

> but I'm sure Wordpress just broke a lot of links on their user's sites.

Growing pains. I think that will at least make people on the web more aware of the HTTPS "revolution".

> we need to always default to secure.

This.

When will they actually consult with various IT-literate parties before making decisions that affect the way IT-related professionals will have to operate?

I don't think they are stupid enough to not have thought of that. So I wonder what motivates them to write that kind of bill.

Bingo.