It’s less the job post, more the implication, that they consider Rust to be better than (their internally developed) C# for one of their major products. And that I think is worth news (as it could further drive towards adoption of Rust in general).
Well the project never left its roots, it’s a still a simple system-f implementation, and a lot of ideas. I’ve put it on ice, after seeing how much involved there is with questionable outcome (and I need to dedicate a good amount of time to get the theory right, it’s not that I have year long research experience background in type-theory etc.). There’s more concrete problems than designing yet another language… Maybe I’ll come back to that project at some time.
Anyway the idea was to have something like Nix but more general (including derivations, possibly controlled side-effects). Closest to that currently would be typescripts object type, Haskell (overall static typing), crystal-langs union type and nickel (which is less ambitious (probably for good reason)).
“Faster/easier/less mental overhead” is indeed exactly what I mean by “convenient”.
How different the conception of convenient is :P
I think it’s super convenient to just do cargo new <project>, start hacking, have superb tooling/expressiveness/performance etc.
And it works remarkably well and fast if the problem space is not self-referential etc. or a lot of mutability is in play (I’m probably faster in Rust now than in python, but that probably has to do with the amount of time I’m spending with it…). But I get your point, and I think there’s certainly better languages for certain problems (and I even started one myself some time ago, because I wanted something like Nix but with strong typing (anonymous sum/union types/sets etc. similar as typescript))
Box<dyn Trait>
Now try to do that with a trait that isn’t object-safe…
I get your point, these things make fighting with the borrow-checker a little bit less annoying, but Rust is complex. I’ll happily accept that because I value high code-quality (to that point that I rather invest more time to get things right) but when that is not the goal and you want something higher-level and strongly-typed there are alternatives that work better (I’m just talking about the language itself, ecosystem alone for me is yet another pro-Rust thing)
What is a convenient language exactly?
Although I think the arguments are not exactly pro-Rust (they already show complexity with something like Box<dyn Trait>).
Sure hacking something quickly together with python is quite a bit faster/easier/less mental overhead.
But long-term and IDE experience IMO Rust is the most convenient language (mind you I programmed in ~10-20 languages, and the whole DX is best with Rust IMO (cargo, rust-analyzer etc.)), as it forces you to write a clean architecture and the strong type system keeps it maintainable. While refactoring can feel cumbersome, I almost always had a clean and working/correct (often without tests) code afterwards (when all the compiler errors are fixed).
That said Rust is of course not perfect, all the strong-typing, zero-cost (async is certainly not something I would recommend beginners) systems-programming features make it complex at times (and the type-system can get in the way at times, e.g. trait-object-safety, or not “simple” higher-kinded types). So when that is annoying and control over the exact memory is not that important, something like OCAML or Haskell may be better.
have an even cleaner architecture
Although I’m fully in camp functional, I doubt that. There are problems that are inherently stateful and rely on mutability. Modelling that in Haskell often results in unnecessary abstractions. I think Rust hits a sweet spot here (when you’re that experienced to write idiomatic Rust, whatever that exactly is). Also being lazy by default has its own (performance) implications, strict + lazy iterators (like Rust) is a good default IMO.
Almost… To be precise it’s a Merkle DAG
One day you will inherit a code base so bad that you’ll end up commenting old code
Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…
Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)
Your so called comment standards and principals are fine if you are building something from the ground up
Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…
Nah, it’s not, code is modular (IME should be kinda tree-structured), a book is linear.
So the API should be in your analogy the synopsis. And I haven’t said, that there shouldn’t be any comments. E.g. doc-comments above functions, explaining the use-cases and showing examples are good practice.
Don’t get me wrong comments != documentation (e.g. doc-comments above function/method).
I probably was a bit unprecise, as others here summed up well, it’s the why that should be commented.
Yeah that’s a good summary
Yeah, but unironic…
If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.
Good video I really recommend: https://www.youtube.com/watch?v=Bf7vDBBOBUA
Indeed, and the maintainer opened this RFC (I think because of it)
SUUUUUUUUURE!!!11 I"M oN ITTTTTTTT
We’re at 22.8̅2̅8̅7̅8̅4̅1̅1̅9̅1̅0̅6̅6̅9̅9̅7̅5̅1̅8̅6̅1̅0̅4̅2̅1̅8̅3̅6̅2̅2̅% slowly gaining rainbow ground
I just calculated exact subpixel accuracy, for me it’s exactly 20.5̅9̅5̅5̅3̅3̅4̅9̅8̅7̅5̅9̅3̅0̅5̅2̅1̅0̅9̅1̅8̅1̅1̅4̅1̅4̅3̅9̅2̅0̅ % that is still missing to fill the whole comment body with rainbows, way to go!
Let’s start the sixth rainbow!
Plenty of space for me still (browser version on desktop)
Rookie numbers, it’s probably 15% on my screen, There’s space for a lot more rainbows
Easy, it’s just… continue programming in python. (large codebases are a mess in python…)
More seriously: Don’t do that, it’ll only create headaches for your fellow colleagues and will not really hit those (hard) that likely deserve this.