That is correct. Strings and I/O both have a bunch of work to be done. Printing currently requires workarounds like https://godbolt.org/z/MP4164f7s
Array iteration got checked into the prelude so this is now shorter: https://godbolt.org/z/YYheo19ea
Readit Newsjosh11b commented on Carbon Language: An experimental successor to C++ docs.carbon-lang.dev/... · Posted by u/samuell
josh11b commented on Carbon Language: An experimental successor to C++ docs.carbon-lang.dev/... · Posted by u/samuell
Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages?
A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust.
There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common.
(Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.)
Carbon is performance-first, so ABI instability is the default. We plan to have opt-in ABI stability, but that story is not well developed yet. Replacing C as the lingua franca is not a goal, at least not yet.
josh11b commented on Carbon Language: An experimental successor to C++ docs.carbon-lang.dev/... · Posted by u/samuell
I am trying to run Carbon in Godbolt.
Printing as in the example from Carbon's Github repository, does not work. 'Print("Test");' gives a complaint about not finding 'Print'.
That is correct. Strings and I/O both have a bunch of work to be done. Printing currently requires workarounds like https://godbolt.org/z/MP4164f7s
josh11b commented on Carbon Language: An experimental successor to C++ docs.carbon-lang.dev/... · Posted by u/samuell
Is there a compiler, maybe an online one, for Carbon, or some way to compile and run Carbon code? And if not, what are the plans for that?
The nightly release of the Carbon compiler can be used via https://carbon.compiler-explorer.com/ . Note that it is definitely a work in progress, it hasn't even reached our v0.1 goals yet, but a good chunk of important functionality is working.
josh11b commented on C3 solved memory lifetimes with scopes c3-lang.org/blog/forget-b... · Posted by u/lerno
"No more [...] slow compile times with complex ownership tracking."
Presumably this is referring to Rust, which has a borrow checker and slow compile times. The author is, I assume, under the common misconception that these facts are closely related. They're not; I think the borrow checker runs in linear time though I can't find confirmation of this, and in any event profiling reveals that it only accounts for a small fraction of compile times. Rust compile times are slow because the language has a bunch of other non-borrow-checking-related features that trade off compilation speed for other desiderata (monomorphization, LLVM optimization, procedural macros, crates as a translation unit). Also because the rustc codebase is huge and fairly arcane and not that many people understand it well, and while there's a lot of room for improvement in principle it's mostly not low-hanging fruit, requiring major architectural changes, so it'd require a large investment of resources which no one has put up.
https://learning-rust.github.io/docs/lifetimes/
> Lifetime annotations are checked at compile-time. ... This is the major reason for slower compilation times in Rust.
This misconception is being perpetuated by Rust tutorials.
Deleted Comment
If your original data is not a byte sequence then it would indeed work. Otherwise you have to convert it back to bytes yourself, but no small x exists such that 10^x is just barely smaller than 256^y and bignum would be necessary for efficient encoding. Base45 doesn't need bignum and only incurs ~3.2% overhead [1] compared to the pure octet mode (which might be unsuitable for decoder compatibility and other purposes though).
[1] 32 original bits = 4 original bytes = 6 base45-encoded letters = 33 bits in the alphanumeric mode, so the overhead is 1 - 33/32 = 0.03125 for 4n bytes of data.
10^12 < 256^5 ≈ 1.1e+12, which isn't too bad. You could also use 10^118 < 256^49, which wastes less but is in bignum land.
But don't you want 10^x to be slightly bigger than 256^y, so you could represent all length-y byte sequences in x-digit number? In this direction, there's 10^53 > 256^22, but that is still in bignum land.
josh11b commented on WASM will replace containers creston.blog/wasm-will-re... · Posted by u/hpincket
I'm always reminded of Gary Bernhardt's "the birth and death of javascript" when wasm gets discussed. While it's a bit tongue-in-cheek, I think it really drives home that it's really just another layer of abstraction that may or may not be useful for a given problem, and might not be the silver bullet that anyone is looking for. I recon that whether or not wasm will take over everything will mostly be about trade offs between it and the other solutions.
That is what I was thinking of too! From 2014: https://www.destroyallsoftware.com/talks/the-birth-and-death....
josh11b commented on The two factions of C++ herecomesthemoon.net/2024... · Posted by u/cyclopeanutopia
> Honestly, I am extremely glad that Google is finally leaving the ecosystem, as I generally do not enjoy it when Google engineers try to force their ridiculous use cases down peoples' throats, as they seem to believe they simply know better than everyone else how to develop software.
Well, you may be celebrating a bit prematurely then. Google still has a ton of C++ and they haven't stopped writing it. It's going to take ~forever until Google has left the C++ ecosystem. What did happen was that Google majorly scaled down their efforts in the committee.
When it comes to the current schism on how to improve the safety of C++ there are largely two factions:
* The Bjarne/Herb [1] side that focuses on minimal changes to the code. The idea here is to add different profiles to the language and then [draw the rest of the fucking owl]. The big issue here is that it's entirely unclear on how they will achieve temporal and spatial memory safety.
* The other side is represented by Sean Baxter and his work on Safe C++. This is basically a whole-sale adoption of Rust's semantics. The big issue here is that it's effectively introducing a new language that isn't C++.
Google decided to pursue Carbon and isn't a major playing in either of the above efforts. Last time I checked, that language is not not meant to be memory safe.
[1] https://github.com/BjarneStroustrup/profiles [2] https://safecpp.org/draft.html
(Carbon lang dev here.)
Carbon is intended to be memory safe! (Not sure whether you intended to write a double negative there.) There are a few reasons that might not be clear:
* Carbon has relatively few people working on it. We currently are prioritizing work on the compiler at the moment, and don't yet have the bandwidth to also work on the safety design.
* As part of our migration-from-C++ story, where we expect code to transition C++ -> unsafe Carbon -> safe Carbon, we plan on supporting unsafe Carbon code with reasonable ergonomics.
* Carbon's original focus was on evolvability, and didn't focus on safety specifically. Since then it has become clear that memory safety is a requirement for Carbon's success, and will be our first test of those evolvability goals. Talks like https://www.youtube.com/watch?v=1ZTJ9omXOQ0 better reflect more recent plans around this topic.