josh11b

This newsletter does not contain ads, ...

It most definitely contains ads since it is about ads.

I think it has to be parallel by symmetry.

Array iteration got checked into the prelude so this is now shorter: https://godbolt.org/z/YYheo19ea

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.

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

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.

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.

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.

That is what I was thinking of too! From 2014: https://www.destroyallsoftware.com/talks/the-birth-and-death....

(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.

https://caseyhandmer.wordpress.com/2019/08/20/space-based-so...

[Carbon team member here.]

Carbon is still a small team, so it is going to take time to achieve all of our goals. Carbon will need to demonstrate both C++ interop and memory safety to be considered a successful experiment, worth pushing to a 1.0 version. Once those are achieved, we do expect it will be easier to get C++ code to memory safety through Carbon, since that is the purpose it is being created for. The impedance mismatch between C++ and Carbon will be much lower than with Rust.

Parsing code quickly is merely one of those goals we can demonstrate today.

(2019)

[1] on structured concurrency gives good context for Dijkstra's GOTO paper and how it is applicable today.

[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

https://caseyhandmer.wordpress.com/2019/08/20/space-based-so...

There is no place on the moon that isn't in shadow 14 days at a time. https://caseyhandmer.wordpress.com/2022/07/03/powering-the-l...

I don't think Rust polymorphism is decidable: https://sdleffler.github.io/RustTypeSystemTuringComplete/

I suspect this is a follow-up to this recent article: https://news.ycombinator.com/item?id=28017204

Robinhood's app has a 1.2 star rating at the moment.

https://play.google.com/store/apps/details?id=com.robinhood....

I know the author, if you have any questions.

I'm on the team that worked on this -- happy to answer questions!

In fact, the typical way to visualize word2vec embeddings is t-SNE.