I don't think that a `diverse` environment represents a healthy environment. For now, `diversity` is just a buzzword like `machine learning`, `artificial intelligence` or `internet of things`. I believe that people should be hired based on their skills (including social skills).
In order to find out that the company is friendly, you should ask people that worked/are working there.
I don't really understand these acquisitions made by Microsoft, first Mojang, then Bethesda and now Activision. Is Microsoft trying to revive these companies or it's just trying to leech of the market? At this moment, Activision is living out of in-game purchases, not making good games. Bethesda was almost dead when they bought it.
>Legendary games, immersive interactive entertainment and publishing expertise accelerate growth in Microsoft’s Gaming business across mobile, PC, console and cloud.
I wonder what this "cloud" means. Is Microsoft planing an alternative to Google Stadia?
I wasn't even referring to CRuby, I was referring to YJIT especially. For now, it only works on x86_64 Unix like systems (Linux and mac). I doubt that someone will ever port YJIT codegen to these "esoteric" architectures, so rust platform support is enough.
The platform `problem` shouldn't be a problem, because you wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD, OpenBSD and Rust has support for more than that[1]. Backwards compatibility isn't a concert either, Rust promised and kept it for some years (after 1.6).
The real problem is whether or not the expense of porting it is justified. Taking a look at the git repository of it (before it was merged into upstream), I understand why they want to rewrite it in Rust, the repository looks like a complete mess. I don't know if they want to use an existing JIT codegen like LLVM or Cranelift, or their own.
My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much. Zig still can't proper handle UTF-8 strings [1] in 2022, which is kind of unfortunate, because it's a `requirement`. In a `recent` interview[2], he claims that Zig is faster than C and Rust, but he refers to extremely short benchmarking that has almost no value in the real world.
At least Rust, as blamed and loved as it is, delivered a stable compiler and people started working on the ecosystem (in the first years, most packages were working only on nightly, but at least there were crates available). The ecosystem for zig is insignificant now and a stable release would help the language.
Nowadays, I keep my TODOs in the codebase, it's pretty easy to browse through code to find what isn't implemented yet, also it became really popular lately and a lot of plugins for better management appeared.
For real life TODOs, I use a simple cli to keep them in a database that I share via Google Drive with my phone.
The idea of completly replacing human beings with chatbots isn't going to succeed. They have their own uses, not very advanced, for example replacing some web interface with chatting in WhatsApp/Telegram, some companies already adopted that and filtering people in case of a call center. But for something more complex that requires actual experience and real life understanding, they should connect you to a real person that can comprehend your messages.
After Grammarly spent millions of dollars on Google ads, I expect them not to accept valid criticism on Google platforms.
But it's unfair to block a guy that talked about a real flaw in Grammarly's plagiarism checker, at least pretend that you allow free speech and take down that video for a random reason specified in your ToS.
It's a nice Quality of Life addition, that I would like to see with C++ as well.
I wish they don't implement f-strings and s-strings, at least for now. Even if they are more ergonomic than the `format!` and `String::from`, they hide a memory allocation which is not really indicated in a language like Rust and would be really weird in a context without an allocator. The only solution to this would be `const` evaluation of this, but that would restrict their use to `const` environments, so mostly unusable.
What's really important for a newcomer (and even more for a 9 year old) is to be motivating and rewarding. For most kids, modding their favorite game or drawing a few lines on a canvas would be fine.
The programming language doesn't matter, but lua for roblox or java for minecraft would be a good fit.
Background concepts like how does the CPU work, what's an OS, what's an architecture aren't important for a kid. If he wants to continue programming as a career, he can learn them, but they are not important to get started and will probably lose the motivation.
From what I know, system76 didn't shill cosmos as a rust DE, the only reference to Rust being done in some reddit comment. Most PopOS users don't know what Rust is, so it wouldn't make sense to talk about Cosmos as a Rust project.
Now, 90-95% of users use GNOME or KDE, having some competition from a `new` GTK4 DE can't be bad, so I would like to see Cosmos gain attention, and maybe be ported to other distros.
So these "factcheckers" are literally the media aka the propaganda machine. I wonder if that's the future we want, a future only politically correct opinions are accepted, otherwise you're called a liar and you lose social points. It doesn't sound like democracy, but who knows.
I would like to see that avr-unknown-gnu-atmega328 works with the latest compiler. Some bug in LLVM broke it[1], because it didn't work starting with versions after nightly-2021-01-07[2]. I know that rust team has nothing to do with this, but they should improve the gcc codegen[3] to be able to run rust on more embedded devices than LLVM has support for. Someone wanted to port his libc written in rust to ia64 and the gcc codegen broke and couldn't compile that.
>Dockerfiles are much simpler than nix configuration
I highly doubt this, Dockerfiles are simpler for a hello world microservice, but they get worse and unmaintainable when you add them lots of them with docker-compose.
>ostree is the future, not nix
>flatpak takes care of the desktop aspect
I really hate the approach this approach, it just moves the state from the root system to the user. The root directory is immutable, but you move the whole responsability to Flatpak, which is not even comparable to nix.
Meanwhile, in case of Nix, the whole system is reproducible and settings are more and less immutable.
>it's too complex
My whole nix config (with specific configs for vscode, neovim, chromium, wireguard, rust, python, nodejs, c++, go) is less than 600 lines of code, and it's readable. Also I configure most of my open source projects via nix as well as it's pretty easy to share the environment with the other developers.
Nix works everywhere, on every linux distro, macOS and even Windows via cygwin or wsl.
>under documented
That's a really good point, nix maintainers didn't care much about documentation, but usability. But it looks like that's changing, they moved docs to mdbook and a team is working specifically on improving the docs
Durov had multiple posts related to healthy lifestyle where he talked about how bad fast food is and how people should prepare their own dishes.
Restaurants. Restaurants offer the slowest and least efficient way to eat. Cooking at home allows for healthier diets and more control over ingredients.[1]
I think that they choose gtk-rs because they have experience with it, if you take a look most stuff is written in Rust with gtk-rs. Also I think that they say they won't drop gtk.
That's not really a solution to the problem because the attacker might change the contents of the package instead of adding `postinstall` or `preinstall` hooks.
The more realistic solution would be teams of volunteers that are auditing the packages and check the differences between specific versions of those. This doesn't block all possible infected packages, but most of them, which is better than what we have now. Everything is based on trust so you can't stop this, but maybe prevent it.
In order to find out that the company is friendly, you should ask people that worked/are working there.