281–290 of 302 posts
I would have expected Go even for CLI due to fast compilation and easy cross compilation out of the box
Their manager is either incompetent, or he is very opinionated, wich doesn't sound good for their stack
What's always been interesting about the languages Meta uses is the story of the rise and fall of the D programming language at Meta. I wasn't around at the time when Andrei was working there and advocating for its adoption, but it seemed like he hit a wall at some point. By the time I joined all D services were being deprecated or rewritten. Rust seems to be doing far better. Though it's also worth noting that Go ne…
Rust is far more widely used than D in the industry, so it's no surprised that it's more supported at Meta. Re: Go, it's use cases overlap with the officially supported languages, so there's no broad need for it.
The industry adopted Go as the cloud native language, not rust, i suspect the people doing the recomandation are ex-mozilla, or they literally HATE Go
Earlier quoted context omitted.
Andrei is now at NVidia, and I bet most likely for his C++ skills. It is a pity that D never found its enterprise sponsor to push it no matter what. Even the recently announced Carbon could probably have somehow built on top of it.
Depressing that even a PL savant amongst us has to go and ply his trade around town instead of being financially independent.
Earlier quoted context omitted.
Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html This needs to exist in Rust for it to get adopted, because forcing good developers to get explicit with code for memory safety when they are doing simple operations is going to result in them ignoring the language. So ev…
> C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively You can't use smart pointers exclusively, because there is no "smart observational pointer", and there cannot be one, because that would be a reference type checked by a borrow checker, which is exactly what rust uses. You can emulate it with shared pointers, but then you're left…
Sure, there are some things that Rust makes nice, like compile time checking for errors, however with C++ codebases, they will just result in runtime errors rather than usable exploits.
Earlier quoted context omitted.
I can't say Go had the adoption I was hoping for. It did well in the infra community (probably starting with docker) but, among my clients in services, I can think only of one failed startup who bet on Go (and actually failed because they decided to rewrite from node to go).
> and actually failed because they decided to rewrite from node to go Interesting. What did golang do so badly that they failed?
They had a working node server and decided to reimplement it from scratch. They started missing demos and weren't able to raise more from existing or new investors before they run out of money. I suspect the CTO did it on purpose and was just CV building.
Often times the tech choice is not that important, you just need to get something out the door.
Earlier quoted context omitted.
Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser. Ther…
For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable. But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which…
Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice.
My point is: there are tons of GUI applications written in C++. And to this day there are still new projects that pick C++ because it needs a GUI. I consider that a bad thing for Rust. Thinking Rust should be at the CLI-apps competition is just a way to avoid C++. It is the wrong contest, and I am not sure if Rust is even able to win that contest because what Rust has to offer (no GC) isn´t of interest for most CLI apps. I think cli apps like kubectl would not be hurt by being GC'ed.
I think that the Rust leadership should identify that GUI is the first city they need to liberate from C++ if they ever dream to replace C++. I just learned some original work has started by various projects, so I keep my fingers crossed.
Earlier quoted context omitted.
Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html This needs to exist in Rust for it to get adopted, because forcing good developers to get explicit with code for memory safety when they are doing simple operations is going to result in them ignoring the language. So ev…
Being "explicit with code for memory safety [even for] simple operations" is the whole point of Rust. Otherwise, sooner or later, as a codebase grows, you make mistakes that your compiler cannot catch (e.g., you give an immutable reference to a component and later on unexpectedly mutate that same referenced memory from under that component). > [Rust] [will be] driven into a shit state. Specifically because of [unsafe…
>Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler
Yes and no. There are some things you want to specify for compiler to check, but a lot of behavior can be inferred from the code. Think about some backend server functionality for a website that has to do processing on some json data. You could take that code in python and write absolutely safe C code, and the process to translate it wouldn't be that hard.
Earlier quoted context omitted.
Chasing popularity seems to be a necessary evil these days. I am disappointed when zig calls itself a general purpose language, and 10 years ago Go called itself a system language.
Back in my days, systems programming evolved writing compilers, linkers, os drivers and kernels. Given that the whole Go toolchain is bootstraped, it fulfills that role quite alright. Maybe we need drivers and such to strenght the argument, well given the role of gVisor and Android GPU debugger, that seems a case for systems programming. Maybe still not good enough, then I refer to the F-Secure TamaGo unkernel being…
But it's relatively more abstract and gives less control than C++/zig/rust. I was just comparing and contrasting the marketing.
Go was once marketed as systems language even if the authors intended it more for systems adjacent stuff. Now everyone advertises their language can write web services it seems. I mean why is it out of fashion to just admit a language is mainly intended for low level stuff?
Earlier quoted context omitted.
Depressing that even a PL savant amongst us has to go and ply his trade around town instead of being financially independent.
Yeah, it sad to think we have 100 f*cking think tanks endowed by billionaires that serve mainly to drive wedges into our democracies, yet nothing like that for PL geniuses that I'm aware of.
If one PL doesn’t do the job, another will.
If we don’t get fusion, we die. That’s what the Princeton IAS is for.
I’m surprised they said Rust is their new language of choice for CLI tools. I’m no expert but always saw Go as the better choice for CLI tooling where performance is important, Rust more of a low level language for highly performant libraries and tools, and Python a good choice for scripting or plumbing that needs to work and be easily maintainable, without special performance concerns (Python is my primary language,…
> I’m no expert but always saw Go as the better choice for CLI tooling where performance is important I'm no expert in golang, so golang may in fact be better(?) by some metric of better, but as the author of a Rust CLI tool[0], I will say that Rust is extremely performant, and pretty fantastic at this very use case. It seems like a sweet spot to me. [0]: https://github.com/kimono-koans/httm
I'd really love to get into Rust (and Go, tbh) but haven't needed the performance when I'm working on personal stuff and it's generally 1000x faster for me to jump in Python and write a quick script, using threading or asyncio when I need more perf and my program is IO-limited.