Caste followers have a lot of undue social advantage over the oppressed groups (like in any other form of discrimination). Admitting that it exists would be the first step to giving up those undue privileges. It's perhaps that subconscious bias that leads them to 'caste denial'. People from most upper castes will swear that it doesn't exist outside of rural and uneducated areas of India. But ask someone from the lower (oppressed castes) and they will tell you the very many innocuous-looking ways in which caste based discrimination is meted out to them. Caste is never mentioned - but the treatment follows a predictable caste pattern. People in US are unlikely to hear these stories because a large population of Indians there are the wealthy privileged ones. So, these denials backed by anecdotal evidences should be taken with a lot of skepticism.
Rust has an undeniably steep learning curve which can cause a productivity penalty for beginners. However, there are some statements in this article I simply can't agree with based on personal experience. I'm using Rust to develop a few projects. At this stage, I would go for Rust for general development, irrespective of how useful manual garbage collection is. To put it in context, my other favourite language is Python.
> Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages, and there is a pretty steep learning curve, even for experienced programmers.
Rust's borrow checker system doesn't exist in isolation. It's designed to avoid problems that can occur with computing and memory model of programming - things like call stack frames (esp constant size), heap memory and other resource management, concurrency paradigms, etc. These are just the tip of low level computing models. There are things like cache coherence that Rust doesn't address directly. These are concepts that programmers must know if they want to do: a) Low level programming b) High performance programming. The problem raised by author may partially belong to the second category. Even if it is not, programmers should probably learn these, because they are likely to face such problems at some point and may gain from that knowledge.
There are two ways to learn the borrow checker rules. The first is to start with the rules itself. It's going to appear rather convoluted. The other approach is to understand the machine/memory model that I mentioned above first. Once you do, the rules are going to make much more sense - especially in the context of specific error messages during coding. These days, I'm able to connect every single error message that I see to some potential memory or concurrency problem, even though they are the result of some seemingly convoluted but simple borrow checker rule.
> Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below).
There were dozens of errors that I made today that were easily understood just by a glance at Rust's error messages. The help messages that accompany these error messages are often the solution that I needed. Even otherwise, the error messages point out potential low-level bugs as I mentioned above - allowing me to make proper corrections. This may just be anecdotal. What is not anecdotal is that the Rust team reworked the error messaging early in the project's life to make it that way. It's generally accepted that Rust's error messaging is top-notch. I find it disrespectful to all those early endeavors to call it arcane. Perhaps it's a good idea to try to learn those error messages. There is an entire index of errors with detailed explanations [1].
> We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development.
Perhaps this is the wrong way to approach the problem. The thing that may need learning is type theory. Type theory is often too esoteric with a theoretical mathematical approach. Perhaps we need an introduction to it that encourages people to see a bunch of bits as a storage for data with a particular meaning (the type). Next step would be to how to track types using software (type system) and then extend the idea all the way to include constant-size stack frames, generics, polymorphism and lifetime tracking.
> Libraries and documentation are immature
Library ecosystem is still growing - especially async programming. But documentation support is a first-class feature of Rust's language ecosystem. I find myself writing documentation much more often in Rust than with other languages. It's also equally easy to browse the documentation of the language, stdlib and other libraries. Sections are marked out clearly and navigation is well thought-out. Every search of a feature or API takes me through half a dozen links to the final target in a matter of minutes, if not less. It's a good investment to learn browsing technique for documentation in any language.
> Rust makes roughing out new features very hard
Somehow, my experience doesn't match here either. I use the same technique for trying out new features in both Python and Rust. Create a scratch project for each experiment. A single project may take up to a dozen such scratch projects. It's marginally easier in Rust than in Python, mainly because project management is another first-class feature of Rust tooling.
But what's really remarkable about Rust compared to most other languages I've encountered is that Rust's discipline gently nudges the scratch project to a proper design. By the end of the scratch project, the experimental code is often in a good enough state to be directly integrated into the main project. It's amazingly friction-less to integrate integrate external code into the main project.
I wouldn't blame the author for having a very different experience as mine. But I sure would like to know what makes Rust 'click' for some, but remain a tough nut to crack for others.
I have a different experience with Rust these days. The errors that Rust throws are either the ones I had a vague hunch about or the ones I missed. It never feels like friction, but rather like helping guides. The error messages are informative and often very helpful in resolving problems.
The key, I believe is understanding the machine and memory model of low level computing. Rust errors immediately make sense in that context and it becomes easier to find a proper solution without having to work around it.
These days I feel much more comfortable with Rust than I'm with even Python. It feels like Rust does a lot of heavy lifting and thorough checking of a lot of semantics that's not possible in other languages. The worries about unforseen bugs are lesser (not zero, though) with Rust.
> It never feels like friction, but rather like helping guides.
That is exactly what I mean by "healthy friction." Friction can be used to guide users towards better habits. The fact that you encounter friction less often is evidence of having learned from friction in the past.
These sorts of incidents would be far more common if bosses shit talked their employees in the public and tanked their brand image in the process in front of their users and future employees. Fortunately, almost everyone else is smart enough to know that it's bad.
Sir, he was shit talking the app (which everybody agrees blows ass) and the dev took to Twitter to whining instead of using the internal platform. Next time your boss admits your product is trash, try shit talking a rebuttal to him on Twitter, I dare you. Elon is his father.
I'm sure the job market yearns to hire yet another Android "engineer" and one who shit talks their boss on Twitter to boot. The bratty stepchild will be fine.
Indeed! The headline gave false hopes that the article may advocate for returning to plain text emails. It instead talks as if the biggest problem with email is the lack of even more complicated features. The introduction of html has already turned email it into a push version of attention seeking and pervasive user tracking on the web. It has made email ux bad for normal purposes like business communications. I for one really don't want any more of that.
Other commenters have mentioned interactive and patch staging. That is the standard way to ensure that only the lines you specify go into a commit. I want to add an alternative method that offers some extra advantages.
Patch stack management tools like stacked-git and topgit allow you to setup a number of patches (using git). You can then specify which patch each change goes into. This is sort of like having multiple staging area/indexes at your disposal. They also allow you to add commit messages to each patch at any stage of the development. You could also add, delete, split, squash or edit each patch at any time. And these patches are converted to regular commits at the end of development of the feature. You can also convert any commits into patches if you ever need it.
The attraction that I see in this workflow is that it allows you to combine the chaotic development workflow and final rebasing step into a single stage.
The ad is about a git tool (hiflux) that happens to be written in Rust. That is perfectly relevant in this context. Rust is also a good language to write such tools (as is Go). I understand why Rust evangelism can be a bit tiring. But the opposition to it shouldn't try to imitate the same quality.
