321–330 of 521 posts
Earlier quoted context omitted.
dlang would have been a very serious contender to C++ had it been fully nogc, stable & lean. Also dlang unnecessarily suffered low adoption in start due to competing stdlibs, trying to be both Java & C++ at once.
If you use the @nogc attribute, D is fully nogc.
Earlier quoted context omitted.
> Seamless interop where existing, unmodified C++ APIs are made callable from safe Rust requires the C++ code to follow borrow checking rules at the API boundary. > Seamless interop where safe Rust APIs are made callable from C++ requires C++ users to follow Rust borrow checking rules. Their complaints about borrow checking rules at the interop layer ring hollow to me. Whether the new code is being written in Rust, C…
> Their complaints about borrow checking rules at the interop layer ring hollow to me. It's actually a big problem. There's a whole lot of Rust library API's that are only provided with an idiomatic "safe" interface, but this actually imposes stronger , more demanding preconditions on those API calls than are warranted by the actual code, which could easily work with e.g. raw (possibly aliased) pointers, or owned-but…
If they needed to fork the Rust compiler to pessimize a few optimizations that the Rust compiler would normally do (that would invalidate such unsafe C++ code with additional UB), even that would be far less effort than inventing their own entire new language and ecosystem from scratch. That is without considering how Google could work with the Rust Core Team to contribute solutions for ergonomic issues they're encountering in the interop process.
When the alternative is "building an entire, general purpose programming language", there are a lot of other things you can do that would be much easier.
And, as previously mentioned, Carbon is only addressing the low hanging fruit... it isn't stated anywhere I've seen that they even intend to achieve parity with Rust. All of this effort, just for a lesser outcome.
I'm sorry that I'm frustrated at big companies choosing to take half measures that seem even more expensive than the full measure. I have used Rust professionally for years; I'm clearly biased, but it's not that hard. The level of safety that Rust provides should be table stakes in discussions of unmanaged languages... not the ceiling for what we can possibly imagine, but Carbon is a statement that Rust's bar is too high for Google to reach, and that's pretty depressing.
Earlier quoted context omitted.
Which is what D can do. D can (and does) interact successfully with C++ classes and member functions. Even templates!
dlang would have been a very serious contender to C++ had it been fully nogc, stable & lean. Also dlang unnecessarily suffered low adoption in start due to competing stdlibs, trying to be both Java & C++ at once.
Earlier quoted context omitted.
I still haven't seen a cross-platform production level GUI app written in Rust. All the time, it is C++ these companies use for these apps, especially having millions of users and generating multi-millions or hundreds of millions of dollars.
Here is one example: https://serokell.io/blog/rust-in-production-1password
Earlier quoted context omitted.
> Their complaints about borrow checking rules at the interop layer ring hollow to me. It's actually a big problem. There's a whole lot of Rust library API's that are only provided with an idiomatic "safe" interface, but this actually imposes stronger , more demanding preconditions on those API calls than are warranted by the actual code, which could easily work with e.g. raw (possibly aliased) pointers, or owned-but…
I think a number of companies have proven that it isn't a "big problem" by successfully interoping Rust and C++. What you describe might be an inconvenience, but this goes back to what I was saying about how Google could achieve their outcome with less effort by customizing their own version of bindgen. Google could give up some safety in exchange for the desired, incremental outcomes. If they needed to fork the Rust…
"Pessimizing" the compiler is not a solution, UB is still UB. You'd have to actually look at what the code does in detail and provide a generalized interface to it, possibly needing to introduce new "unsafe" blocks in the process and prove their safety.
Earlier quoted context omitted.
I think a number of companies have proven that it isn't a "big problem" by successfully interoping Rust and C++. What you describe might be an inconvenience, but this goes back to what I was saying about how Google could achieve their outcome with less effort by customizing their own version of bindgen. Google could give up some safety in exchange for the desired, incremental outcomes. If they needed to fork the Rust…
I'm not talking about giving up safety, I'm talking about library API's that are simply not usable by code that involves, e.g. possibly aliased pointers, or pinned data, other than by invoking possible UB, merely because those things are "unidiomatic" in Rust (even though, if the unsafety is properly contained, it's quite possible to e.g. write proofs of correctness for such code, or verify it via a model checker). I…
I addressed this when I talked about a compiler fork. Google could maintain a patchset against the Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten. Or they could work with the Rust Core Team to address this issue in a way that is favorable to them over the next year or two. Either of these options are much less work than developing an entirely new language and ecosystem.
As far as I can tell, Google tried neither option.
Still, Mozilla and others have gotten along just fine as it is.
Earlier quoted context omitted.
It's moderately annoying to implement because it messes with the calling convention in architecture dependent ways. So it isn't an IR transform, it's N lowerings for N architectures. Clang and llvm understand them, and you can require them from the front end, but the cost is some backends will hard error on them as unimplemented.
Just to clarify, are you saying that a language’s calling convention is implemented differently per architecture? Or is it that the tail call implementation needs to be implemented in different ways per architecture and that would mess with the required calling convention?
Tail calls mean reusing memory (notably the stack) and arranging for there to be no work to do between the call and the return. E.g. if arguments are passed by allocating on the stack, you can't deallocate after the call, so you have to make the stack look just right before jumping.
If you've got multiple calling conventions on your architecture, they each need their own magic to make tail calls work, so you might have 'fastcall' work and 'stdcall' error. Iirc I implemented it for a normal calling convention on one arch and didn't bother for variadic calls.
I suppose one could have a dedicated convention for tail calls as well, I just haven't seen it done that way. Usually the callee doesn't know and can't tell whether it was called or tail-called.
Earlier quoted context omitted.
(-1, -2, -3), is it not?
That's not a vector of natural numbers.
Earlier quoted context omitted.
(one of the Carbon leads) Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us. Projects like this have to start somewhere, but can grow and become community endeavors. We are also alr…
The README doesn't expand on what is probably the most challenging problem: how do you achieve effortless C++ interop without burdening Carbon with all the odd behaviour and memory safety / UB issues prevalent in C++? In Rust for example, `unsafe {}` blocks are not just "local unsafety". They can freely operate on all memory, so they are infectious and are essentially a marker for "dangerous code below, be extra care…
You can definitely massively improve upon C++ without touching its actual computation model.
Earlier quoted context omitted.
I'm not talking about giving up safety, I'm talking about library API's that are simply not usable by code that involves, e.g. possibly aliased pointers, or pinned data, other than by invoking possible UB, merely because those things are "unidiomatic" in Rust (even though, if the unsafety is properly contained, it's quite possible to e.g. write proofs of correctness for such code, or verify it via a model checker). I…
> other than by invoking possible UB I addressed this when I talked about a compiler fork. Google could maintain a patchset against the Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten. Or they could work with the Rust Core Team to address this issue in a way that is favorable to them over the next year or two. Either of these options a…
To be clear, this is "forever". I don't think anyone involved has an expectation to truly get rid of Google's existing C++ codebase ever. So the question is, do you really want Google to fork rustc to implement some google specific UB handling? Is that good or fair to the rust community?
Even if it was, the HN comments would be along the line of "Google is using an embrace/extend/extinguish approach to force rust to do certain things bypassing the normal rust language processes", and they'd in some ways be correct! Could rust really choose different semantics from the already existing one, or would google-rust implicitly be a standard that rust would need to support?
Would that be a good idea for anyone?
> Still, Mozilla and others have gotten along just fine as it is.
IIUC, one of the driving factors behind this is that vanilla C++ is too slow, and ABI compatibility prevents up-streaming certain performance improvements. So what works for Mozilla probably doesn't work here, because what works for Mozilla has a performance penalty. Sure it's small, but that's going in the wrong direction.