-
carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
There is plenty of experimentation in high-performance memory-safe languages going on now - see e.g. https://vale.dev/ and https://github.com/Kindelia/HVM
There is plenty of experimentation in high-performance memory-safe languages going on now - see e.g. https://vale.dev/ and https://github.com/Kindelia/HVM
This language was started by folks at Google. (Although it's interesting that they're publishing it under a separate github org, which suggests ambitions beyond Google's needs.) Google has a huge, performance-sensitive C++ codebase. At Google, major product teams' backends are typically written in C++, as well as common infrastructure like D (disk server), Colossus (distributed filesystem), Spanner (distributed SQL database), and Borg (cluster management). More than a few people would love for it all to be be written in Rust instead, but migration would be challenging, to say the least. I'm told people are looking into it—see Crubit for example. But AFAIK, no one's decided yet whether Google will stay with C++ for all these things, migrate some to Rust, migrate some to Carbon, and/or do something else entirely.
Notably Google is also investing in autocxx to make C++/Rust bidirectional interoperation easier
I've been writing Go and Rust nearly daily for about a decade now (Go is more than a decade, Rust is about 8 years). You are not going to teach me anything about the pros and cons of either language in a reddit comment. I do not need to be taught about the "iota mess" when I've written tooling for exhaustiveness checking in Go.
There are now several features in the standard library (e.g. sync.Map) which use interface {}-based APIs. They now need to add a new version of sync.Map which uses generics. So at best, it winds up creating duplication and cruft in the standard library.
I am looking at the design of this language as an alternative design (in research mode, not because I think it is going to gain popularity) and I think it has the nicest semantics I found so far on the paper. Of course, if you start to use it at the scale of Rust probably some problems will pop up: https://github.com/val-lang/val
What language would you use to build a server? I've been using go for a while and have enjoyed using the different emerging frameworks and even just the standard packages.
What language would you use to build a server? I've been using go for a while and have enjoyed using the different emerging frameworks and even just the standard packages.