In order to find out that the company is friendly, you should ask people that worked/are working there.
136 karma · joined November 5, 2021
In order to find out that the company is friendly, you should ask people that worked/are working there.
>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?
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.
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.
[1] https://github.com/ziglang/zig/issues/234 [2] https://about.sourcegraph.com/podcast/andrew-kelley/
For real life TODOs, I use a simple cli to keep them in a database that I share via Google Drive with my phone.
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.
f-strings on other hand would be pretty weird. Would `f"5"` return a &'static str or a String?
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.
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.
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.
For example, https://www.washingtonpost.com/politics/2022/01/06/january-6... or https://www.washingtonpost.com/politics/2021/11/04/bidens-cl...
[1] https://reviews.llvm.org/D114611
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
Restaurants. Restaurants offer the slowest and least efficient way to eat. Cooking at home allows for healthier diets and more control over ingredients.[1]
[1] Durov's message on his 37th birthday
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.
Also, other languages are Rust, Kotlin, Swift (to name a few `modern` ones). Yes, Kotlin and Swift have `first class` CLI parsing libraries, but they are not part of standard library.