[HN Gopher] Carbon Language: An experimental successor to C++
___________________________________________________________________
Carbon Language: An experimental successor to C++
Author : slimsag
Score : 362 points
Date : 2022-07-19 14:05 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pjmlp wrote:
| The experimental successor to C++ is Circle.
|
| I guess now it is clear where Google's clang contributions end up
| going instead.
| sam0x17 wrote:
| why camel-case functions tho :(
| zeotroph wrote:
| Indeed, from Python to Rust and newer C++ codebases you usually
| see CamelCaseClasses (or structs) and then snake_case for
| functions methods etc, which improves readability.
|
| CamelCaseForEverything is such a waste, maybe they use it for
| implicit public/private as in Go? And maybe to please existing
| Go or Java users?
| Narishma wrote:
| That's PascalCase. camelCase is like this.
| ArrayBoundCheck wrote:
| This is the 3rd language I know about that google created. I have
| no idea why they don't use rust with their C++ code base and I
| don't know why they made this instead of use zig which actually
| brings something new to the table.
|
| Overall I don't see myself using this. 0/3 google
| compiler-guy wrote:
| There is an entire document which explains why they can't use
| rust or zig.
|
| The short version is that for their particular usecase they
| need really close ties to C++.
|
| "Existing modern languages already provide an excellent
| developer experience: Go, Swift, Kotlin, Rust, and many more.
| Developers that can use one of these existing languages should.
| Unfortunately, the designs of these languages present
| significant barriers to adoption and migration from C++. These
| barriers range from changes in the idiomatic design of software
| to performance overhead."
| ArrayBoundCheck wrote:
| I guess I'll rewrite my original comment here to clarify
|
| I don't know why google created this language. It offers
| nothing new and I can't see why they'd use this over rust
| when rust can be used. I don't see why they use this over zig
| since zig can certainly be used where this language is meant
| to be used. Zig actually brings something new
|
| Overall google is 0/3 on creating languages that people want
| to use. Maybe go is useful but I haven't seen enough proof
| sam_bristow wrote:
| It's a minor thing, but I do find it odd that they use PascalCase
| for function names when the C++ standard library uses snake_case.
| ansible wrote:
| From the end of the safety document:
|
| > _Overall, Carbon is making a compromise around safety in order
| to give a path for C++ to evolve. C++ developers must be
| comfortable migrating their codebases, and able to do so in a
| largely automated manner. In order to achieve automated
| migration, Carbon cannot require fundamental redesigns of
| migrated C++ code. While a migration tool could in theory mark
| all migrated code as unsafe, Carbon should use a safety strategy
| that degrades gracefully and offers improvements for C++ code,
| whether migrated or not._
|
| > _That does not mean Carbon will never adopt guaranteed safety
| by default, only that performance and migration of C++ code takes
| priority, and any design will need to be considered in the
| context of other goals. It should still be possible to adopt
| guaranteed safety later, although it will require identifying a
| migration path._
|
| That's very interesting and pragmatic. It would be interesting if
| they can eventually come up with the same level of safety
| guarantees via a different path than Rust's borrow checker.
|
| -------------
|
| Since one of their goals is to automatically translate _modern_
| C++ to Carbon, I do wonder how well that is going to work in
| general.
|
| I definitely welcome an alternative to C++ that would be easier
| to read and understand. That would be a benefit to the world.
| klodolph wrote:
| This is also how Meta got Hack.
|
| It's not like PHP is unsafe to begin with like C++, but the
| language does have a ton of problems, and Meta's massive
| codebase could only be migrated to another language gradually.
| Hence, Hack. Better language, better tooling, more productive
| programmers.
|
| Note that unlike Carbon/C++, Hack is backwards-compatible with
| PHP. So the migration is somewhat more gradual.
| jeffreygoesto wrote:
| The borrow checker is a pretty smart solution pushing checks to
| compile time and have efficient runtime, so yes, it would be
| interesting to see if there is an even better alternative. But
| you can't beat that kind of safety into an old C++ code base,
| so I am pessimistic for retrofitting.
| MR4D wrote:
| I wonder what would happen if Security became a compiler flag?
|
| For instance, just like the -O1 or -O3 flags work for
| optimization, something like a -S1 or -S3 would be really
| useful.
|
| To me, there are lots of times when I just need to get an idea
| into code. Then there are times when I need to make sure that
| code just works(tm).
|
| Having different compiler flags would really make that nice,
| and for devops, allow anything pushed to production have to
| complete a -S3 successfully first.
| pjmlp wrote:
| You already have them, true it is more than one and isn't
| bullet proof, still it is way better than not using them.
| gigatexal wrote:
| From the syntax alone it looks a bit more approachable than
| vanilla C++.
| pipeline_peak wrote:
| All these C++ "successors" that do nothing but change the syntax
| sugar and find ways to operate with C++ are really tiring to read
| about.
|
| I seem to be the only one on the planet that doesn't think the
| language needs to be replaced.
| jokoon wrote:
| I agree.
|
| Although I still think it should be possible to make some
| things obsolete in C++. The technical debt is real, and the
| language can hardly improve if old codebases are slowing down
| the evolution of the language.
|
| I already wrote several times that I would like a new C++-like
| language, but without the complexity of C++. D, zig and rust
| are fine but they're not simple languages to use. I want the
| nice things of C++ (string, a few containers, a bit of syntax
| sugar, the most useful std stuff), with enough simplicity from
| python or C.
|
| I just use the simple parts of C++, and I only want those
| parts. I just want the KISS simplicity. Carbon is not that,
| neither is rust zig or D.
| m4nu3l wrote:
| AFAIK this is the only one what is compatible with C++ at the
| source level. As much as I like C++ I think it has a lot of
| accidental complexity built in and the syntax is too verbose at
| times. I also think that a lot of people (me included) do not
| want to switch to something like Rust immediately because of
| the existing C++ code and the friction of having to make it
| interoperable. So I believe this is actually a great
| experiment. Will see whether it works or not, but I hope it
| will.
| bestouff wrote:
| I'm as tired as you by these cosmetic successors. But for my
| part I think C++ has already been replaced, and to great
| benefits. I couldn't thank the people building Rust enough.
| rvz wrote:
| 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.
| mustache_kimono wrote:
| "I still haven't seen a production level numerical weather
| prediction app written in Rust.
|
| All the time, it is Fortran the government uses for these
| apps,..."
|
| I vacillate as to whether the best response is: "Who
| cares?" or "give it time"? First, if C++ actually is better
| for GUI apps, then more power to C++ (do you have some
| evidence this is the case?). That doesn't mean their aren't
| other niches to fill for other languages, like Rust. Next,
| Rust is a relatively new language. It may end up that it's
| really great for GUI apps, but again _it doesn 't have to
| be_. It can be great at other things.
| bialpio wrote:
| GP mentioned C++ being replaced by Rust - I'd say that a
| replacement should be as capable as the thing it
| replaces, so if that's the claim, then Rust should be at
| the very least OK for GUI apps. If it's not, then that's
| also okay, but let's not call it a replacement then. :-)
|
| I'm personally excited to see how all those languages
| will influence each other!
| wiseowise wrote:
| You're comparing framework for one language to another
| language.
| pca006132 wrote:
| Perhaps also with a large portion of legacy code that they
| don't want to throw away and switch to something new?
| bialpio wrote:
| We may need more time. IIRC, Firefox is incorporating some
| code written in Rust, and there's also Servo.
| pipeline_peak wrote:
| Mozilla laid off Servo's developers and a lot of the core
| Firefox Team 2 years ago. Servo is dead
| jeltz wrote:
| Many cross platform GUI apps have been written in C, JS and
| Java too. The ability to write GUI apps does not really
| seem that unique to C++.
| adastra22 wrote:
| That's not the claim being made.
| otabdeveloper4 wrote:
| Remove "cross-platform" and "GUI" and your post would still
| be correct.
| stusmall wrote:
| Here is one example: https://serokell.io/blog/rust-in-
| production-1password
| yakubin wrote:
| The GUI is made with Electron.
| pjmlp wrote:
| Written in a mix of JavaScript and C++.
| spacechild1 wrote:
| > I think C++ has already been replaced
|
| In which world has Rust replaced C++?
| foxtacles wrote:
| I feel the same way. Add to that the plethora of "C++ bad"
| memes that every software engineer is throwing around as soon
| as they get a whiff of anything remotely resembling C++ - I've
| made my peace with the fact that I'm in a tiny minority of
| people who think it's generally a great language that is worthy
| of further development and improvement instead of abandonment.
| beeforpork wrote:
| Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that
| is not so well-designed in Rust (in my opinion). Also, with the
| stated goals, it seems a bit unnecessary to overhaul C++ syntax,
| but then I found no explanation why syntax was changed. So what's
| wrong with C++ syntax if your goal is a successor of C++?
|
| This now looks to me like a Rust-- instead of a C++++, which is a
| picture they might not want to give rise to. Because then I'd
| rather use Rust instead, which then feels like the real
| thing(tm).
|
| [EDIT: If you think about downvoting, maybe answer instead as I
| am genuinely interested in this syntax question. I am not trying
| to be negative, it was just an observation and a question.]
| dixego wrote:
| From the "Why build Carbon?" section:
|
| > The best way to address these problems is to avoid inheriting
| the legacy of C or C++ directly, and instead start with solid
| language foundations like a modern generics system, modular
| code organization, and consistent, simple syntax.
|
| That last part seems to imply that the authors don't consider
| C++ syntax to be a good foundation for a modern successor
| language, so they chose to change it. As to why change it in a
| Rust-like direction I'd imagine that it's both because it's
| what fashionable at the time and possibly to attract people who
| are already familiar with that style.
| jimbob45 wrote:
| I can't handle [] syntax for generics. It makes code unreadable
| as far as I'm concerned because it makes it twice as difficult
| to know if I'm dealing with an array indexer or a generic.
|
| The rest I can excuse but [], I cannot. Same reason I won't
| touch Nim.
| xigoi wrote:
| I can't handle <> syntax for generics. It's impossible to
| auto-pair and looks ugly.
|
| The real solution is [] for generics and something else for
| indexing.
| Koshkin wrote:
| Indeed, syntax only a mother could love. (Swift, I am looking
| at you, too.)
| yakubin wrote:
| Go authors put out a good post explaining the problem with C
| syntax and contrasting it with Pascal/Go/Rust syntax:
| <https://go.dev/blog/declaration-syntax>
| notriddle wrote:
| It's not just Rust syntax. `name: Type` is the syntax used in
| TypeScript and Python type annotations (also Ocaml, which is
| probably where Rust got it from). Golang drops the colon, but
| still keeps the name first.
|
| As for what's wrong with `Type name(constructor, args)`? A lot
| of tooling wants to be able to parse "mostly-valid C++", like
| IDEs and compiler diagnostics. Sure, once clang's type
| inference is finished, the lexer hack and most vexing parse
| aren't problems, but when the program isn't complete, parsing
| isolated fragments is impossible, and that limits the amount of
| useful tooling the language can have.
| kzrdude wrote:
| There is a lot of Rust in the Carbon syntax.
|
| `fn`, `name: Type`, `i32`, `->` for return type. `impl` as a
| keyword. `Self` as a keyword.
|
| Nothing unique to Rust, but it's _interesting_ to see.
| c-cube wrote:
| The syntax `name: Type` is also friendlier to type inference
| as you generally have a token indicating a declaration. If
| you have `var x: Type = ...` then you can just omit the type
| and let inference do its job.
|
| Even better, when you start having more complex patterns on
| the left-hand side of `=`, you can type annotate them as you
| want. Hypothetical syntax would be: var (x:
| f32, y, [z1,z2,z3]) = SomeExpression();
|
| That's harder to do when you have a type declaration on the
| left imho.
| nyanpasu64 wrote:
| It would make sense if Carbon started allowing omitting ":
| Type", which they currently don't:
| https://github.com/carbon-language/carbon-
| lang/blob/trunk/do...
| beeforpork wrote:
| OK, I see. Yes, C and C++ syntax is definitely ambiguous
| without semantic analysis. Maybe this could also be explained
| somewhere.
| cyber_kinetist wrote:
| And to add, the `name: Type` syntax is not just a modern fad,
| don't forget the OG language that did this: Pascal!
| (https://en.wikipedia.org/wiki/Pascal_(programming_language))
| dangets wrote:
| A blog post by Roman Elizarov (Kotlin designer) on the
| observation of types following the variable name [1]. It mostly
| states that having consistent length prefixes (fn, val/var)
| makes the code more readable than arbitrarily long type
| identifiers (in the eye of the beholder). Not scientific, but
| interesting.
|
| [1] https://elizarov.medium.com/types-are-moving-to-the-
| right-22...
| kupiakos wrote:
| Fixed prefixes also make a codebase significantly more grep-
| able. Want to find the definition of the function named
| `foobar`? Search `fn foobar` and that will always match, no
| regex required.
| mountainriver wrote:
| This is a really great idea, I love rust but it's lack of good
| c++ interop has kicked me more than once
| dvirsky wrote:
| Why did they go to such lengths to obscure the fact that it's a
| Google project? I heard about it back when I was a Googler so I
| knew immediately what it was, but otherwise it was very hard to
| find any indication that this is a Google led project.
| ccbccccbbcccbb wrote:
| Must be avoiding the stigma of the broken promise not to be
| evil.
| dvirsky wrote:
| The thing is they have an excellent track record with runnig
| open source programming languages for over a decade. It's
| often claimed that Go succeeded only because it was sexy
| because it was Google. Why hide it here?
| ccbccccbbcccbb wrote:
| Being a benefactor doesn't trump being an abuser at the
| same time.
| kccqzy wrote:
| There was apparently a presentation by Chandler today on Carbon:
| https://twitter.com/code_report/status/1549383435642445824
| [deleted]
| hartjer wrote:
| Have you thought about rewriting it in rust? :3
| dxuh wrote:
| I just do NOT feel like using a language, that has explicitly
| stated, that you should not start a new project with it. Very few
| legacy projects will consider using Carbon, I would assume (If
| you have worked on one, you probably know that "legacy" is
| usually more than just the code) and then there are so few
| projects left that I see no chance of this really taking of. And
| in that case it will probably die soon as well, like many (most)
| other Google projects.
| optimuspaul wrote:
| This is interesting. I've been relearning C++ after not using it
| for 25 years. It is hard, I was a Java dev for years, now Python
| with some Golang. Carbon looks much easier to take up.
| superkuh wrote:
| C++?? versions are the experimental successor to C++. A new
| language that the old C++ compilers cannot compile every 3-4
| years.
| throwaway744678 wrote:
| Backward compatibility works the other way: new compilers can
| still compile old code.
| sebastianconcpt wrote:
| Does it help in any way with memory management or it keeps that
| burden loaded in the developer's back?
| mepian wrote:
| It's a shame a stable ABI is declared as one of the non-goals,
| C++ is painful enough to integrate with other languages.
| masklinn wrote:
| Part of why google is unhappy with the committee is google's
| desire to break C++ ABIs.
| kllrnohj wrote:
| C++'s current unwillingness to specify a stable ABI (or even
| state that ABI stability is a goal) but also have the standard
| libraries avoid breaking the ABI is a worst of both worlds
| currently. And the refusal to break the ABI adds overhead to
| things like std::unique_ptr which isn't really great.
|
| This paper goes into the details https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2020/p18...
| yakubin wrote:
| Also, the unfortunate associative containers and std::regex.
| gpderetta wrote:
| Apparently this is a google or google-adjacent project. Google
| was one of the most vocal committee members in favour of
| breaking ABI stability, so it is not surprising.
| lenkite wrote:
| A stable ABI can effectively kill a language.
| https://cor3ntin.github.io/posts/abi/
| saagarjha wrote:
| (At Google, it's definitely useful to others.)
| beached_whale wrote:
| ABI stability is an unstated goal of c++ and holds it back by
| preventing meaningful change or fixing of issues. This is good.
| mihaic wrote:
| Am I the only one that doesn't like this direction for the
| syntax? This was the main reason why I never got into Rust, it
| was just too different without any obvious reason. It's strange
| that I actually enjoy working with type annotated modern Python
| though.
|
| I'll now go away for a few years until the dust settles.
| wiseowise wrote:
| What exactly you don't like about it?
| xigoi wrote:
| The obvious reason is that C++ syntax is difficult to parse,
| for both machines and humans.
| jcranmer wrote:
| Some quick notes about interesting features of the design:
|
| * Source file encoding is required to be UTF-8. Strings are
| UTF-8. No apparent provision for binary strings, but I haven't
| delved into the string API.
|
| * Retains the C/C++ definition of overflow of signed integers
| cannot overflow, unsigned can. That's o_O-worthy; the two should
| be aligned, and if they can't overflow, provide some form of
| wrapping integers as well.
|
| * Yay, tuples.
|
| * Struct type syntax is ... weird? {.name: String, .count: i32}
|
| * Expressions. Partial order for precedence (i.e., a | b << c is
| ill-formed instead of being parsed as (a | b) << c or a | (b <<
| c). The Rust-style cast syntax I think I prefer, but ^x for
| bitwise not is o_O, and if a then b else c feels odd for a
| generally C-syntax language to use. Similarly using 'and' for
| logical and instead of &&.
|
| * var and let for declaring variables; one is constant, the other
| not--that's somewhat jarring. It seems that the : <type> is
| mandatory, and inferred type is : auto instead of letting it be
| omitted? Feels unnecessarily verbose to me.
|
| * No goto, nor labeled break and continue. Huh. Also, 'for (var
| name: String in strings)' is again feeling unnecessarily
| verbose... (Can break break out of an if statement, or does it
| have to be a loop?)
|
| * You declare "returned var c: Circle" instead of relying on
| named return value optimization. Again with the verbosity,
| although I haven't yet reached copy/move constructor stuff to
| understand how much automagic happens.
|
| * The [me: Self] syntax is weird. I'd like something closer to
| the C++ deducing this syntax or Rust's &self/&mut self, where the
| type of the this parameter is specified via the first argument
| rather than what feels like a somewhat-out-of-bounds information.
|
| * Mixin (aka multiple inheritance) is unspecified at this point.
|
| * The keyword for enums is "choice"? Really?
|
| * Name lookup retains the C/C++ rules of need-to-declare-before-
| use. Again, is this really necessary? It's fiddly...
|
| * The [me: Self] syntax appears to be a specific instance of the
| generalized syntax for generics, but only for method parameters,
| because generic types use () instead. Again, why differentiate
| from the C-family standard practice of <> for generics? Also, the
| : versus :! in generics strikes me as overdrawing the weirdness
| budget one too many times. Props for using something closer to a
| constexpr if than C++ SFINAE; SFINAE is not a design model I
| would carry forward in any future languages.
|
| * Stable ABI appears to purely be defined in C ABI terms. Sigh,
| can we get people on these language committees together to start
| thinking about post-C standardized ABIs?
|
| * Async, coroutine, lambda stories are unclear.
|
| * Error handling also unclear. (That's kinda important!)
|
| * Not clear from the main design document is how the distinction
| --if any--between trivial/nontrivial copy/move types work. There
| appears to be an explicit move operator (with obvious syntax ~x),
| so support for nontrivial move or immovable is better than Rust
| already, but the avoidance of a NRVO setup still makes me wonder
| what the actual story is here.
| Animats wrote:
| Can C++ be machine-translated to Carbon? That would be useful.
|
| Translating C++ to Rust is too hard - the underlying data models
| are too different. What would be really useful would be something
| that intelligently translates pointer-based C++ code into a
| slice-based language. Every place there's an unsized array,
| something has to figure out how big it is and pass that info
| around. In the original program, that information had to be
| present in some form. The trick is finding it. That's probably
| not out of reach for a static analyzer today. Especially if
| machine learning is used to help find the usual idioms of C/C++.
| First find, then check.
| secondcoming wrote:
| Interesting. It will obviously take off _because Google_ but
| since they're heavily influcened by the Rust syntax, why not just
| learn Rust instead.
|
| They'll need to get it into Compiler Explorer so people can
| really look at codegen rather than porting small programs.
| kllrnohj wrote:
| > but since they're heavily influcened by the Rust syntax, why
| not just learn Rust instead.
|
| That's pretty extensively covered in the link, but here's a
| relevant snippet:
|
| "Existing modern languages already provide an excellent
| developer experience: Go, Swift, Kotlin, Rust, and many more.
| Developers that can use one of these existing languages should.
| Unfortunately, the designs of these languages present
| significant barriers to adoption and migration from C++. These
| barriers range from changes in the idiomatic design of software
| to performance overhead."
| unrealhoang wrote:
| As stated in their goals, they want Carbon to be semantically
| compatible with C++ so Carbon code can use (automatically
| rewrite) C++ libraries.
| visheshdembla wrote:
| https://carbon.godbolt.org/
| secondcoming wrote:
| tremendous!
| saghm wrote:
| > since they're heavily influcened by the Rust syntax, why not
| just learn Rust instead
|
| Interestingly, when looking at their code samples, the vibe I
| get is more "Go++". Using `var` for variable declarations,
| letter casing for visibility, explicit returns even at the end
| of functions, using the "package" keyword for namespacing, etc.
| I do see some superficial syntactic similarity to Rust, like
| using `fn` for functions and `->` to annotate return types,
| using `:` for type annotations for variables, and semicolons
| seeming to be required at the end of lines, but overall it
| doesn't really _feel_ that much like Rust to me, I think due to
| how imperative it seems. Given the use of `class` and `let/var`
| seeming to be const versus mutable bindings, I'm wondering if
| the Rust resemblance is actually just transitive through more
| of a resemblance to Swift, although I don't know Swift well
| enough to know if this is an accurate explanation.
| Erlangen wrote:
| > like using `fn` for functions and `->` to annotate return
| types
|
| `->` syntax is included in C++11 standard, named "trailing
| return type", but its adoption seems to be very slow.
|
| `auto f() -> int { return 42; }`
| saghm wrote:
| Interesting, I didn't know that!
| cogman10 wrote:
| If you are like me and wondering "What makes carbon different
| from Rust or Zig? 1. The ability to
| interoperate with a wide variety of code, such as classes/structs
| and templates, not just free functions. 2. A
| willingness to expose the idioms of C++ into Carbon code, and the
| other way around, when necessary to maximize performance of the
| interoperability layer. 3. The use of wrappers and
| generic programming, including templates, to minimize or
| eliminate runtime overhead.
|
| In otherwords, what carbon can do that Rust can't do, is take a
| C++ class with a `foo` method and call that method. Or create a
| class with a `foo` method and call that method from C++. Probably
| one of the biggest hurdles to get over in C++ interopt. Most
| don't do that, instead you'd make a C function binding and struct
| and move data/invoke functions through that.
| Sebb767 wrote:
| The syntax looks _a lot_ like Rust, though. I 'm surprised they
| made such a break when there explicit goal is to make migration
| from C++ as easy as possible. Also, Rust (from my biased point
| of view) is currently on its way to become the standard low-
| level language, so I'm not too confident that Rust-but-with-OO
| is enough of a selling point.
| aaaaaaaaaaab wrote:
| >Also, Rust (from my biased point of view) is currently on
| its way to become the standard low-level language
|
| Lol. Gave me a good chuckle!
| imachine1980_ wrote:
| Rust is like c++ but only the new way to doing c++ is huge
| rust is like subset of c++ and ownership model. I thing is
| the right way c++ is harder than rust only because is so
| bloated. Carbon seams less bloated "fork" of c++ whit only
| the new way of doing things, but allow you full
| interoperability whit all c++, instead of partial and i don't
| see ownership, i thing is taxing mentally (worth or not
| depends). if i work in c++ i totally will use this.
| pron wrote:
| > Rust (from my biased point of view) is currently on its way
| to become the standard low-level language
|
| The evidence seems to suggest the opposite. Other than a lot
| of talk on programming fashion publications that are always
| more aspirational than representative (such as this site)
| Rust seems to have reached 0.3% of the market [1], up from
| 0.1% a couple of years ago [2], and while that is ok growth,
| programming languages with few exception tend to reach,
| approach, or at least point toward their all-time peak market
| penetration around age 10, and Rust is already 7. Any
| language could, of course, be an exception to historical
| trends, but there's nothing to suggest that is the case.
|
| More anecdotal adoption stories are just as bleak. Even at
| this relatively advanced age, many companies dabble in Rust
| -- as they did in, say, Haskell -- but not many established
| companies have yet to really bet big on it.
|
| The only positive is that among the low-level languages
| discussed on aspirational sites, Rust is, indeed, the most
| talked-about language, but history also suggests that that is
| a very bad predictor of long-term market success.
|
| [1]: https://www.devjobsscanner.com/blog/top-8-most-demanded-
| lang...
|
| [2]: https://www.hiringlab.org/2019/11/19/todays-top-tech-
| skills/
| mtlmtlmtlmtl wrote:
| GP said the standard _low-level_ language. Low-level code
| will always be a much smaller percentage of all code than
| the heaps of web apps our industry is shitting out on a
| daily basis.
|
| Thus it would be completely reasonable for the de facto
| sysdev language to have a small market share overall(unless
| like for C/C++ there is a lot of legacy stuff to maintain)
| . Your sources don't shine any light on this at all.
| slingnow wrote:
| You don't think comparing the current defacto standard
| low-level languages (C/C++) to Rust shines any light on
| the issue you raised? [1]
|
| C/C++ : 6.17% Rust : 0.29%
|
| This was addressed in one of the linked sources. What
| would you accept as evidence, then?
|
| 1: https://www.devjobsscanner.com/blog/top-8-most-
| demanded-lang...
| mtlmtlmtlmtl wrote:
| I think looking only at the number of dev jobs leaves too
| many potential confounding factors to be useful. For
| instance, how many C/C++ jobs are actually companies who
| need those devs to move away from C/C++? What's the
| overlap? How much of the C/C++ share is maintaining
| legacy code vs starting new projects? Sure the data says
| _something_ about it, can we draw any conclusions from it
| other than precisely the numbers you listed? Not really,
| not without more detailed data.
|
| One thing I would welcome is specifically looking at new
| sysdev projects over time and what languages they're in.
|
| To be clear I'm not taking a view on whether Rust will
| become the standard. I really don't know, and I've yet to
| see anything convincing me one way or the other.
| mek6800d2 wrote:
| "... around age 10." C++ (not to mention C)? IIRC, I
| remember seeing B.S.'s "C with Classes" appear in _ACM
| SIGPLAN Notices_ in the early 1980s -- 40 years ago. I don
| 't think it hit its peak 10 or even 15 years after its
| early development. Given that it's C++, that's a pretty
| major exception.
| Jensson wrote:
| C++ was huge in the 1990s, C++'s share is probably
| smaller today than back then since so much of programming
| has moved over to managed and scripting languages.
| cogman10 wrote:
| > programming languages with few exception tend to reach,
| approach, or at least point toward their all-time peak
| market penetration around age 10
|
| Notable exceptions from the links you've provided:
|
| C#, Java, Go, PHP. All appear to have an upward trajectory
| today.
|
| Javascript has also seen a similar penetration boost when
| nodejs came on the scene.
|
| With rust looking to get integration both into the Linux
| kernel and GCC, that points to some pretty positive things
| for the language's penetration. Particular in the embedded
| world.
| pron wrote:
| > All appear to have an upward trajectory today.
|
| They might have an upward trajectory, but they're not
| posed to break well beyond their respective records. With
| the possible exception of Python, how popular a language
| is at age ten is a reasonable rough indicator of how
| popular it's ever going to be. At its current growth rate
| Rust would reach 1% market share at age ten. Again, there
| can certainly be surprises, but I think it's weird to say
| that actual current evidence clearly points to success
| for Rust. On the contrary, to become a success it would
| need to buck the trend and be quite a surprise. So it
| could happen, but I don't see much to support the claim
| that this is what's currently happening.
|
| > With rust looking to get integration both into the
| Linux kernel and GCC, that points to some pretty positive
| things for the language's penetration.
|
| I agree that it shows that the language is taken
| seriously and isn't dismissed as a possible option, and
| that that's very good. That indicates that the language
| isn't an immediate irredeemable failure, but I don't
| think it's an indicator of future success.
| cogman10 wrote:
| > That indicates that the language isn't an immediate
| irredeemable failure, but I don't think it's an indicator
| of future success.
|
| I'd simply point to the fact that there are very few
| languages that have tried to get into the same space that
| rust exists in. Even something like D came with an
| optional GC which has pulled it out from consideration
| for things like the kernel or embedded devices.
|
| When you say "most languages are peaked at 10 years" I'd
| simply point to the fact that rust is substantially
| different from most languages. It's not tackling the same
| market spaces. The ones it is hitting have been slow
| moving for a while now.
| pjmlp wrote:
| While others with GC are used without issues on embedded
| for the last decade when users aren't stuck on ways of
| the past.
|
| https://www.ptc.com/en/products/developer-tools/perc
|
| https://www.aicas.com/wp/products-services/jamaicavm/
|
| https://www.microej.com/
|
| https://www.astrobe.com/
|
| https://www.wildernesslabs.co/
|
| Ah but that isn't serious enough.
|
| I guess battleship weapons control might be something
| serious,
|
| https://dl.acm.org/doi/10.1145/2402709.2402699
| Jensson wrote:
| Major problem with GC languages is that it is horribly to
| link against libraries that ships with a GC. Lets say I
| want to use 10 libraries, if each has their own GC then
| my program is now running with 10 GC's each trying to
| optimize itself, which isn't a tenable situation.
|
| So system level libraries has to work without a GC, even
| though system level programs can work fine with a GC.
| jb1991 wrote:
| > then my program is now running with 10 GC's each trying
| to optimize itself
|
| Is this true with Java? I thought it's a single runtime
| that manages memory in all the code/libraries in your
| process.
| Jensson wrote:
| For java the virtual machine provides the GC for
| everything, but then you can only use JVM libraries and
| not libraries in other languages.
|
| The reason C and C++ libraries can easily be included in
| basically any other language is that they don't have a
| GC, so there are no such issues, just call the functions
| and things works fine.
| jb1991 wrote:
| > Major problem with GC languages is that it is horribly
| to link against libraries that ships with a GC.
|
| I'm curious which GC languages do this. The most popular
| ones that come to mind for me are anything on the JVM,
| JS, and Go, and I've never heard anyone point this out
| about them.
| Jensson wrote:
| Every language with a GC has this problem. If you want a
| library to be used in both Java and Python you don't
| write it in either Java nor Python, you write it in C++
| or another language without a GC and import that to Java
| and Python. Trying to import a Java library in Python or
| vice versa is horrible, since GC's are very hard to work
| with from outside the language ecosystem.
| Jensson wrote:
| But every language needs to get a foothold within its
| hype period. In a few years the hype for Rust will die
| down, at that point you wont get new blood unless they
| are forced to learn it so it will be hard to grow.
|
| Programmers are forced to learn C++ since many jobs
| require it. Students were forced to learn Python since
| teachers choose it as a language at universities. You
| need some reason like this for a language to thrive after
| its hype cycle is over, and currently there are no such
| reasons forcing programmers to learn Rust and it doesn't
| look like there will be any within a few years either.
| nemothekid wrote:
| > _programming languages with few exception tend to reach,
| approach, or at least point toward their all-time peak
| market penetration around age 10_
|
| How are you coming to this conclusion? I can think of more
| counter examples than actual examples (Almost every
| language on the top 10 aside from PHP where close to peak
| market penetration at age 10).
| agumonkey wrote:
| I don't think rust is headed to be the norm, but I don't
| think it should be compared to most mainstream languages.
| It's not python/php/ruby.. it's a very difficult niche
| where a lot of efforts failed flat.
| anon25783 wrote:
| looks like Rust mixed with Go
| zozbot234 wrote:
| > The syntax looks a lot like Rust, though. I'm surprised
| they made such a break
|
| Convergent evolution. Rusty syntax is pretty close to what
| you get if you want to make a language look broadly similar
| to C/C++ while avoiding pathological and/or computationally
| difficult parsing.
| flohofwoe wrote:
| I'd say the syntax looks like most other modern languages,
| not just Rust.
| usrusr wrote:
| Considering the seemingly endless list of things that
| deliberately _don 't_ break with the c++ legacy, new syntax
| is almost the only change left. And if you were about to give
| c++ a syntax reboot, why wouldn't you look at what successful
| other modern syntaxes are doing? "c++, but in a syntax for
| people accustomed to rust instead of in a syntax for people
| accustomed to C" sounds like a perfectly reasonable approach.
|
| Your perception (and mine) that rust is about to become the
| new default for "true native" is perfectly consistent with
| this, a language for the rust generation for when they have
| to deal with the c++ legacy. A legacy that won't be going
| away any time soon. I suspect that the author (authors?)
| wouldn't disagree at all with "use Rust when possible, Carbon
| when you can't", my perception (from a quick glance at the
| site) is that they are fully aware of the limitations of the
| niche they have so clearly staked out.
| mempko wrote:
| The problem with C++ is it keeps getting better. There was
| a time when Rust was interesting to me but then C++11 came
| out. Then they kept improving it
| fsloth wrote:
| Regarding C++. IMHO - it's not getting intrinsically
| better. More complex. Easy things become a bit less
| verbose, but the hardest things remain as hard and the
| compiler is as unhelpful as before.
|
| I agree C++11 and it's successors are sugaring the
| language to be a lot nicer but fundamentally nothing has
| changed.
|
| Rust is fundamentally better in it's compiler warnings
| (they are actually helpful), and contains specific
| solutions to the things that are hard and bite you in
| C++.
|
| C++ is not going away and it's my main professional
| language but Rust does have features that are better.
| plonk wrote:
| Fundamentally, it has smart pointers and std::make_unique
| now, which means I never have to touch a raw pointer in
| most of my code. They can even be adapted to wrap Win32
| objects. That's a huge improvement and I don't mind using
| C++ for new projects now.
| sudosysgen wrote:
| In my experience compiler error messages have gotten
| hugely better, except for template issues which are still
| very verbose. Especially with clang.
| spacechild1 wrote:
| > but fundamentally nothing has changed.
|
| IMO, move semantics and lambda functions have
| fundamentally changed the way we write C++.
|
| Also, let's not forget that C++11 introduced a formal
| memory model with cross-platform atomic operations and
| multi-threading primitives.
| raydev wrote:
| It's impossible to deny that C++ is improving.
|
| But it's worth investigating what you can do when you
| aren't tethered to wild inconsistencies and odd behaviors
| and workarounds because the community is terrified of
| breaking backcompat.
| gpderetta wrote:
| Doesn't C++11 precede rust?
| avrionov wrote:
| I had the same question as you so I checked. C++ 11
| standard was released in 2011 of course. Rust development
| started in 2006 and Mozilla announced it officially in
| 2010.
| bzxcvbn wrote:
| It's a bit weird to take the release date for one, and
| the start of the development for the other. By that
| measure, the first pre-alpha (!) release of Rust was in
| 2012; the first stable release in 2015. On the other
| hand, the first RFC for C++0x was in 2008.
| arinlen wrote:
| > _C++ 11 standard was released in 2011 of course. Rust
| development started in 2006 and Mozilla announced it
| officially in 2010._
|
| Given that c++0x was a decade in the making, by that
| measuring stick the answer is yes, C++11 does precede
| Rust.
| tialaramex wrote:
| Rust 1.0 is 2015. Hence this is sometimes referred to as
| "2015 edition" in Rust's edition system.
|
| But the sort of people who are here to tell you about how
| great C++ is will say well, _actually_ Rust existed all
| the way back to 2006 as Graydon 's personal project.
| There were no numbered releases until Rust 0.1 (after C++
| 11) and modern features like Traits don't appear until
| much later, but sure, in this sense Rust existed in 2006.
| grimfang4 wrote:
| Almost. C++0x did, but C++11 doesn't and some
| compilers/IDEs (e.g. VS) didn't implement full support
| for C++11 for years.
| fouronnes3 wrote:
| C++ has virtually zero tooling and the committee is not
| interested in ever working on that. Comparing CMake to
| cargo is like comparing fifth century fireworks to the
| Space Shuttle. I mean we are getting modules that aren't
| literally copy paste maybe next year.
| AnimalMuppet wrote:
| Given that gunpowder was invented in the 9th century,
| fifth century fireworks were probably pretty
| uninteresting...
| pjmlp wrote:
| Use Visual C++ and you will have modules today.
|
| I have cargo today in C++ via NuGET and vcpkg, and what
| is great about it, I don't have to compile my depedencies
| from scratch.
| joshuamorton wrote:
| > I have cargo today in C++ via NuGET and vcpkg, and what
| is great about it, I don't have to compile my depedencies
| from scratch.
|
| To be fair, if you're using a language that has a
| reasonable compilation story, this is only every a
| concern the first time you compile.
| pjmlp wrote:
| Sure I always need an excuse to go out for lunch.
| StillBored wrote:
| "C++ has virtually zero tooling"
|
| I read that and I was like WTF, the entire programming
| ecosystem exists on C/C++ tooling. But from your
| perspective its modules/cargo that is the tooling?
|
| That is IMHO an odd viewpoint. As someone who despises
| the way cargo works, and hates not having long term
| explicit control over my dependencies (going so far as to
| track and check them in along with build artifacts) I'm
| not convinced that the recent toss another random
| dependency that itself pulls dependencies into the build
| is a good thing.
|
| I like the fact that I have three dozen+ different ways
| to do regexp's in C depending on my priorities, and that
| picking one requires cognitive overhead and modifications
| to source control/etc. Its easy to add a line to a
| makefile/etc to pull crap off github in C, so its not
| like this is a hard problem to deal with in C/C++ but its
| one where the scale of the problem allows for
| optimization. AKA like the dynamic typing argument,
| making the programmer think about a problem I believe
| yields a better solution.
|
| Its also one where i'm not tied to the whimsy of the
| library author should I decide to fork or maintain the
| code long after they have gotten bored or rewritten it 3
| different times. I can to this day rebuild code I wrote
| 20 years ago on a modern machine with little effort. Can
| you say the same about even 10 year old node.js or python
| code?
|
| Put another way, I spend a little bit more on upfront
| effort and it pays off long term. And I know i'm in the
| minority, but its also why repeatedly I've run small
| teams of a half dozen or so people who's products are
| ahead of major competitors with teams of 100's+ of
| engineers.
| boardwaalk wrote:
| You can do things the way you do them in C++ in Rust if
| you want. You could `cargo vendor`, you could fork a repo
| & depend on a specific commit, etc. It's up to you have
| the self-control to do that though and not just shovel
| random dependencies into your project, that's all.
|
| Mostly you seem to be complaining that it's just to add
| dependencies? (maybe put a 'sleep' in your bash prompt or
| something?) and maybe that the Rust ecosystem doesn't
| have as many duplicate libraries as C++? (of course it
| doesn't?)
| StillBored wrote:
| The problem is that cargo gets in the way (as does rustc)
| if you try and use it in anything other than the simple
| import this dependency mode. I spent a hell hole of a day
| or two, trying to pick up a dependency outside cargo
| because it didn't behave in a way that meshed with the
| rest of my build environment.
|
| So, yes it handles a couple of the basic cases, but then
| your out of luck, stuck in a version hell/etc because
| rustc and cargo are so tightly integrated and the flags
| needed to emulate some of the behavior with just the
| compiler are poorly documented and/or version dependent.
|
| It dictates, you conform (which is basically the rust
| way).
| germandiago wrote:
| The problem with the typical rants about C++ is that you
| guys are outdated.
|
| With Conan you can consume over 1,000 packages directly
| from build systems and with way more control than what
| Cargo seems to offer. Take a look. I did use it for a
| while and compared to 15 years ago things are way better
| now.
| germandiago wrote:
| Besides having lsp (language server protocol), Visual
| C++, CLion and others, I have been successfully using
| CMake/Meson paired with Conan and I can tell from
| experience that it is amazing what you can achieve.
|
| Someone will say Cargo or whatever, which is nice and
| simple. But with these tools you can choose all details
| and optimizations as well, something that other tools
| just hide. But you can still keep it simple with a
| conanfile.txt for your dependencies and the stock
| add_executable etc. in CMake/Meson and get done with it.
| If you feel CMake is subpar (bc its syntax and DSL are
| terrible, I agree with that) then you can use Meson. It
| works pretty well.
| JoshTriplett wrote:
| C++11 was where C++ lost me, and I went from saying I
| knew C/C++ to saying I know C.
| mihaigalos wrote:
| As far as I'm concerned, C++ is there for legacy purposes
| only.
|
| There are some nice frameworks and tools using it, sure.
| Yes, you are required to learn it if you are studying CS.
|
| Any serious new development today is done using more
| modern languages such as Rust (i.e.: the linkerd service
| mesh proxy [1] for encrypted pod communication in a k8s
| cluster).
|
| As even the Linux kernel is slowly transitioning to using
| Rust [2], it's only a matter of time before an inflection
| point is reached and it goes mainstream (if not already.)
|
| [1] https://github.com/linkerd/linkerd2-proxy
|
| [2] https://hackaday.com/2022/05/17/things-are-getting-
| rusty-in-...
| pjmlp wrote:
| Just learned that LLVM, GCC, CUDA, HPC, HFT and the whole
| games industry aren't serious new development.
| mihaigalos wrote:
| .. is it _new_ development?
| pjmlp wrote:
| I guess, unless you're into retro-gaming.
| maccard wrote:
| To be fair, parts of my work codebase are touching on 25
| years old, and I work for a startup from 2020. The
| codebases we're building on have roots in the mid 90s,
| and the platforms they run on didn't support modern C++
| standards for a very long time after that.
| Jensson wrote:
| So anything including "windows.h" isn't really new
| development then? Sounds like a strange definition.
|
| I'd say that there is a lot of new projects being started
| with C++, still way more than there are new projects in
| Rust, at least if you only count serious ones.
| xoac wrote:
| I mean a lot of these things rely on copying old code.
| AFAIK a lot of new games in bigger studios start by
| essentially copying the old engine into a new tree.
| mihaigalos wrote:
| > I guess, unless you're into retro-gaming.
|
| So new (same-)old development then?
| [deleted]
| femtogram wrote:
| robotics is primarily c++ and python. that may change to
| being rust and python, but it will definitely take some
| time.
| fancyfredbot wrote:
| My impression as a CS grad is that very few computer
| science courses require you to learn C++.
| germandiago wrote:
| My impression is that C++ is used in the real world
| though. :)
| tempest_ wrote:
| It really depends on what bit of computer science you are
| learning.
|
| C++ is definitely past its prime and has been surpassed
| in many areas by other languages but there are still a
| bunch of domains where it is the primary language.
| xigoi wrote:
| I'm studying Mathematical Informatics and we have C++ as
| the first language.
| femtogram wrote:
| what languages you learn at university highly depends on
| the specific school you are at, the professors, and which
| companies are donating the most money. it's certainly not
| a great representation of what is going on in the
| industry as a whole.
| otabdeveloper4 wrote:
| > Any serious new development today is done using more
| modern languages such as Rust
|
| Uhm, no. Sorry, thanks for playing, try again.
| kllrnohj wrote:
| > I suspect that the author (authors?) wouldn't disagree at
| all with "use Rust when possible, Carbon when you can't"
|
| That is in fact explicitly stated on the Carbon
| introduction:
|
| "Existing modern languages already provide an excellent
| developer experience: Go, Swift, Kotlin, Rust, and many
| more. Developers that can use one of these existing
| languages should."
| UncleMeat wrote:
| Syntax migration is easy. It is the semantic migration that
| is hard.
| kinjalkishor wrote:
| For once if they would have focused on compile times that would
| have been a very valid reason to switch.
| mrits wrote:
| Designing a language to interop well with a single language is
| short sighted in my opinion. I want a clean ffi that I know
| will be able to iterop with Swift, Typescript, C#, C++, C,
| python etc... In my current project I'm currently using
| Rust/protobuff to do all of this and it rarely gets in my way
| of how I want to do things.
| saagarjha wrote:
| This language has "zero-cost" with C and C++, "minimal cost"
| with anything else that is compatible with those ABIs, and
| "moderate cost" with everything else via protobufs :P
| Kranar wrote:
| Many long living languages are those that are source
| compatible with a single language. C++, Objective-C,
| TypeScript come to mind.
| compiler-guy wrote:
| The major usecase for Carbon is to advance Google's internal,
| multi-billion line, C++ codebase.
|
| As nice as a greenfield language with a clean ffi would be,
| "extremely close ties to C++" is Carbon's primary benefit.
| skavi wrote:
| sorry for nitpicking what is likely intentional
| exaggeration, but multi billion can't be anywhere near
| accurate, right?
| summerlight wrote:
| It's a bit of an exaggeration, but it's close. If you
| count all Google's C++ code base (google3 + open source)
| it's fairly close to one billion. If you count regardless
| of language, I believe it's ~3B.
| saagarjha wrote:
| No, Google really has that much code. Some of it is
| probably machine generated but it's definitely in the
| billions of lines.
| compiler-guy wrote:
| There are many billions of lines in Google's monorepo[1],
| summing well over 80 terrabytes of data. The paper below
| is from 2016, and the repo has only gotten bigger since
| then.
|
| Exactly how many of them are C++ is not disclosed, as far
| as I know. But it is public knowledge that C++ is the
| biggest of Google's primary languages (C++, Java, Go,
| Python, Javascript, and so on).
|
| https://research.google/pubs/pub45424/
| sebastianconcpt wrote:
| Minus having to deal with memory management?
| nerdponx wrote:
| I would also wonder about D and Odin, neither of which are
| particularly successful but both of which are also supposed to
| be kind of like C++ replacements.
| dleslie wrote:
| Interestingly enough, Chicken Scheme has a library that allows
| for interop with C++ to this degree:
|
| http://wiki.call-cc.org/eggref/5/bind#c-notes
| imaltont wrote:
| I believe Clasp has a pretty good C++ interface as well for
| Common Lisp.
| dleslie wrote:
| It looks superior to Chicken's, albeit requiring more
| initial configuration:
|
| https://clasp-developers.github.io/clbind-doc.html
| imaltont wrote:
| Well, they are different languages made for different
| things. Clasp was specifically made because the author
| had a bunch of C++ code for his research projects, but
| wanted something more high level/simpler to implement
| things in. He landed on Common Lisp but none of the
| implementations had good C++ interop, so he made his own.
| Can recommend Christian Schafmeister's (creator of clasp)
| talks on it, it's interesting stuff. In particular his
| talk on an LLVM Conference.
| goodpoint wrote:
| Nim is even better at that, as it generates C/C++ code natively
| and compiles it using GCC.
| zozbot234 wrote:
| Isn't this one of the most prominent features in D? Sounds like
| they're trying for something very much like D, while starting
| closer to current C++.
| pjmlp wrote:
| D is always rebooting what they want to be, I no longer think
| they still stand a chance to be relevant in the next decade.
| kllrnohj wrote:
| D still requires you to write bindings, see
| https://dlang.org/spec/cpp_interface.html
|
| Also D objects have a different lifetimes & requirements,
| which complicates things ( see
| https://dlang.org/spec/cpp_interface.html#lifetime-
| managemen... )
|
| Carbon appears to be auto-generating bi-directional bindings,
| and since it has the same memory model has no such awkward
| interactions between non-GC'd and GC'd worlds like D does.
| zozbot234 wrote:
| > Also D objects have a different lifetimes & requirements,
| which complicates things
|
| Does Carbon actually solve these issues, though? It would
| be great if it did, but they don't list _complete_ interop
| w / C++ as an actual goal of theirs, only enough to make it
| practically viable for development.
| kllrnohj wrote:
| Carbon's memory model is compatible with C++'s[1], so
| where would you foresee complications? D could have been
| so much better here if it just hadn't chosen to be a GC'd
| language. That single choice pretty much kills any easy
| interop.
|
| 1: "For example, C++ and Carbon will use the same memory
| model." https://github.com/carbon-language/carbon-
| lang/tree/trunk/do...
| zozbot234 wrote:
| AIUI, you don't need to use D with a garbage collector.
| It can be disabled.
| dymk wrote:
| The D standard library is heavily tied to the GC. If you
| want to avoid the GC, you'd have to give up the standard
| library, and if you do that, you have to give up most of
| the D ecosystem.
|
| As far as I can tell, there hasn't been progress in
| untying the stdlib from the GC -
| https://github.com/dlang/projects/issues/56
| [deleted]
| KerrAvon wrote:
| This is true, although there is this:
|
| https://dlang.org/blog/2019/04/08/project-highlight-dpp/
| donkarma wrote:
| D is closer to this than this rust rip-off
| Koshkin wrote:
| Yeah, why not D? It's such a good, mature alternative to
| C++, albeit not widely adopted.
| zamalek wrote:
| Like every braces language following C is a C rip-off?
|
| Rusty syntax is objectively superior to almost everything
| else we've come up with, there's no reason it shouldn't be
| copied.
| nineteen999 wrote:
| > Rusty syntax is objectively superior to almost
| everything else we've come up with, there's no reason it
| shouldn't be copied.
|
| You mispelled "subjectively". Rust is a hideous looking
| language, despite its many other benefits.
| Joker_vD wrote:
| > is objectively superior
|
| Those _objective_ criteria of superiority being?..
| vazgriz wrote:
| It eliminates the Most Vexing Parse.
|
| Consider this C++ code: Foo bar();
|
| A programmer could make simple mistake thinking that is
| declaring a variable of type Foo. Carbon eliminates this
| by having explicit keywords for variable and function
| declaration. (This style is much more Rust based than
| C++) fn bar() -> Foo; var bar :
| Foo;
|
| It makes parsing easier for both the users and
| maintainers of the language.
| Joker_vD wrote:
| If that's the only criterion then Pascal's syntax, which
| doesn't have "the most vexing parse" problem either, and
| for the same reason, is also almost better than anything
| else.
| compiler-guy wrote:
| There are literally thousands of shipping languages that
| don't have the most vexing parse problem.
|
| If that is Rust's entire syntax advantage, it isn't a
| very big one.
| arinlen wrote:
| > _It eliminates the Most Vexing Parse._
|
| C++'s most vexing parse issue ceased to be a concern
| around a decade ago with the introduction of uniform
| initialization.
| xigoi wrote:
| So by this logic, pretty much every language other than
| C++ has "objectively best" syntax.
| zamalek wrote:
| long long
|
| Templates
| Someone wrote:
| _If_ Rusty syntax is objectively superior to almost
| everything else we 've come up with, that _almost_ should
| make us think before blindly copying it.
|
| So, for those thinking _"Rusty syntax is objectively
| superior to almost everything else we 've come up with"_
| (I don't, if only because I don't believe the syntax of
| programming languages can be compared on quality without
| considering the audience), what syntax do you believe it
| not objectively superior to?
| formerly_proven wrote:
| > In otherwords, what carbon can do that Rust can't do, is take
| a C++ class with a `foo` method and call that method. Or create
| a class with a `foo` method and call that method from C++.
| Probably one of the biggest hurdles to get over in C++
| interopt. Most don't do that, instead you'd make a C function
| binding and struct and move data/invoke functions through that.
|
| https://cxx.rs
| IshKebab wrote:
| cxx is great but it isn't anything close to what cogman10 is
| describing.
|
| It actually can't ever be, because C++ has move constructors
| and Rust deliberately doesn't, so you can't for example
| return `std::string` from a Rust function by value.
| [deleted]
| hlopko wrote:
| It's currently unclear if Rust can interop with C++ with
| high fidelity. For example
| https://docs.rs/moveit/latest/moveit/ and https://github.co
| m/google/crubit/blob/main/rs_bindings_from_... provide
| functionality to use non-trivially relocatable C++ types
| from Rust.
| ridiculous_fish wrote:
| I tried cxx and walked away somewhat disappointed.
|
| One problem is that it's hard to understand the code. The
| whole thing is one giant proc macro, which is by itself
| tricky to run and debug. Also it uses techniques like
| implementing Deref to simulate inheritance which makes it
| even more confusing.
|
| The main problem is the difficulty in extending it. Support
| for std::string and std::vector are "baked in" in a way that
| does not generalize. I tried to add support for std::wstring
| and it is quite non-trivial.
|
| Because it is a proc macro it's also tricky to integrate into
| a build system.
|
| To me it seems like Cxx is "purpose built" which is fine. But
| after working with it, I longed for a Python script that just
| populates a template string or something.
| WalterBright wrote:
| Which is what D can do. D can (and does) interact successfully
| with C++ classes and member functions. Even templates!
| LorenDB wrote:
| Honestly, the only thing lacking with D (for me) is the lack
| of good support from Qt (which I think is something Qt should
| tackle by making the moc multilingual). But I agree with
| Walter. D already did what Carbon is trying to do, but the
| syntax is easy enough to pick up in a weekend.
| jcelerier wrote:
| > Honestly, the only thing lacking with D (for me) is the
| lack of good support from Qt (which I think is something Qt
| should tackle by making the moc multilingual)
|
| it's possible to do Qt without moc even in C++ with
| https://github.com/woboq/verdigris/, why wouldn't it be
| possible from D ? it should be even easier considering that
| D traits allow reflection of member and function names,
| etc.
| varajelle wrote:
| It is possible, but nobody did it.
| arinlen wrote:
| > _it 's possible to do Qt without moc even in C++ with
| https://github.com/woboq/verdigris/, why wouldn't it be
| possible from D ?_
|
| You're talking about an entirely different thing. While
| OP was referring to the current state of D's ecosystem
| and the impact that missing key frameworks have on
| hindering adoption, you're arguing about the theoretical
| possibility of writing a framework with a language, which
| really does not address OP's point.
| detaro wrote:
| No, you are misunderstanding their point. If the problem
| of using Qt from D is that you need the MOC, then the
| fact that you can work around the need for MOC and use Qt
| without it seems quite relevant?
| chc wrote:
| The initial complaint was that it did not have "good
| support." I think it is fair to say that having to spend
| a significant amount of effort to work around a lack of
| support is not "good support."
| [deleted]
| kinjalkishor wrote:
| 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.
| mhh__ wrote:
| Most C++ codebases would be exactly the same with or
| without a GC
| WalterBright wrote:
| If you use the @nogc attribute, D is fully nogc.
| kinjalkishor wrote:
| Yes it is very useful addition. Hopefully stdlib will
| also be fully nogc soon. Of all available options I am
| most hopeful of dlang. While it doesn't still have taken
| off it still is improving a lot & has high chances of
| increased usage. (Python also took years).
| WalterBright wrote:
| It doesn't need to be fully nogc. Not using the parts
| that use the gc will cripple nothing. You'll know which
| ones use the gc because they won't compile with @nogc.
| kinjalkishor wrote:
| Yes I use @nogc on main itself, to catch all gc usage.
| kinjalkishor wrote:
| I am still a big fan of both dlang & pascal & very hopeful
| of dlang's Bright future ahead.
| WalterBright wrote:
| D has also taken a big step forward in being able to directly
| import C code. You can do things like:
| import stdio;
|
| and it will compile stdio.h with the builtin C compiler,
| making all the declarations in it available to your D code.
| Barrera wrote:
| From the README:
|
| > Interoperate with your existing C++ code, from inheritance to
| templates
|
| Somewhere in the docs (can't remember where) is a link to a
| Rust/C++ interop project sponsored by Google, Crubit:
|
| https://github.com/google/crubit/blob/main/docs/design.md
|
| In case it's not clear, Carbon is also at the moment a Google
| project.
|
| There's not much in the Crubit README (although there is a
| warning not to use it), but the docs directory has some
| interesting stuff:
|
| > The primary goal of C++/Rust interop tooling is to enable Rust
| to be used side-by-side with C++ in large existing codebases.
|
| https://github.com/google/crubit/blob/main/docs/design.md
|
| It's not entirely clear whether this interop is to work as
| envisioned for Carbon (source level?) or some other approach.
| guywithahat wrote:
| Their C++ code example doesn't compile, it has too many "}" marks
| in the circles definition call. Truly the mark of an experimental
| branch
| throwaway03423 wrote:
| Carbon Team, thanks for sharing, I will likely use this if I need
| to bridge with CXX libraries.
|
| Also thanks for adding sum types, and pattern matching, is there
| anyway you could get the dart team on board? They seem to be
| averse to them and it's a big reason why I don't use the
| Dart/Flutter ecosystem.
| munificent wrote:
| _> Also thanks for adding sum types, and pattern matching, is
| there anyway you could get the dart team on board?_
|
| I'm driving the design of pattern matching for Dart. The entire
| language team is on board with them and we have a design that's
| pretty far along. It's _really_ hard to integrate pattern
| matching into a language that wasn 't originally designed for
| it, so it's taken a while to settle on a syntax that makes
| sense, but I think we're getting close.
|
| If you'd like to be involved, there is a category on the issue
| tracker for design discussions related to patterns and records:
|
| https://github.com/dart-lang/language/issues?q=is%3Aissue+is...
| timsneath wrote:
| Au contraire! We're actively investigating them here on the
| Dart team. We're finalizing the spec here:
| https://github.com/dart-lang/language/blob/98335746fb7f2dedf...
| no_wizard wrote:
| A reasonable test of interop would be converting boost to carbon.
| Then you'd hit an enormous amount of edge cases and really be
| able to understand carbon's shortcomings, no?
| bravogamma wrote:
| Based on my quick read, "Why build Carbon?" section calls out
| just 1 problem with C++ which is the developer experience.
| Agreed.
|
| However Carbon seems to do a whole lot more than DevEx. It's
| practically a whole new language that can interop with C++. I
| don't see the point in that. Would be great if someone pointed
| out why I should change my mind.
| mda wrote:
| They have a separate document about difficulties improving C++:
| https://github.com/carbon-language/carbon-lang/blob/trunk/do...
| AndruLuvisi wrote:
| Why do so many new and improved languages still lack tail calls?
| JonChesterfield wrote:
| 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.
| throwaway17_17 wrote:
| 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?
| JonChesterfield wrote:
| Calling convention covers where values are placed in memory
| (or stack or registers) by the caller so that the callee
| can find them. There can be N of these as long as
| caller/callee pairs agree sufficiently. The instruction set
| you're compiling to influences the cost of different
| choices, e.g. how many and which registers to use.
|
| 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.
| gwbas1c wrote:
| I wish they spoke more about their ideas regarding the memory
| model. For me, that's usually the first thing I want to know
| about a new language.
|
| (I initially assumed they had some syntactic sugar for smart
| pointers.)
| Erlangen wrote:
| Its github repo has a very interesting doc on when it's the right
| time for Carbon language to go public. https://github.com/carbon-
| language/carbon-lang/commit/b8750e...
|
| > Broader field experience required
|
| > Sustained interest to use Carbon from multiple organizations
| and individuals
|
| > Prototype implementation
|
| > Demonstration of potential
|
| > Learning material
|
| > Prepare for new contributions and feedback
|
| > Launch event
|
| > Relationship to C++
|
| > Perception of ownership by a single organization
|
| Is this post considered as a step towards going public?
| chandlerc1024 wrote:
| It was made public at CppNorth, a C++ conference, earlier
| today. The page you mention is a bit out of date though, you
| can find the update to our plans here:
| https://github.com/carbon-language/carbon-lang/commit/4aa462...
| togs wrote:
| I'm surprised C++ is still prominent. I thought Rust would have
| taken its place by now.
| outside1234 wrote:
| We already have this with an open foundation: Rust
|
| No thanks
| Rebelgecko wrote:
| How straightforward is interop between C++ and rust?
| cyber_kinetist wrote:
| They have an entire FAQ subsection pointing out some practical
| reasons why one might choose Carbon instead of Rust.
|
| https://github.com/carbon-language/carbon-lang/blob/trunk/do...
| zeotroph wrote:
| On the road map they have _Broaden participation so no
| organization is >50%_, so this has a good chance of not
| becoming Swiftoogle-Lang.
|
| Also, under "Why not Rust?" If you want to use
| Rust, and it is technically and economically viable for
| your project, you should use Rust. In fact, if you can
| use Rust or any other established programming language, you
| should. Carbon is for organizations and projects that
| heavily depend on C++; for example, projects that have a
| lot of C++ code or use many third-party C++ libraries.
| donkarma wrote:
| https://xkcd.com/927/
| rvz wrote:
| > Interoperate with your existing C++ code, from inheritance to
| templates
|
| Very important. A C++ alternative and successor needs to be
| compatible with C++.
|
| The rest of these so called C++ alternatives are either rewriting
| everything in their own language and causing chaos with their own
| incompatibilities with their language features and realising that
| it wasn't a good idea after all to do such rewrites after being
| sold vacuous promises and language feature snake oil, but only to
| show pretty syntax sugar.
|
| Unfortunately, the hype squads will just attempt to drown out
| other alternatives like this one; even if it works with the
| existing C++ ecosystem.
| danjoredd wrote:
| Don't create a programming language to kill another language.
| That never works. Create a language that fulfills a specific
| purpose.
| Koshkin wrote:
| This is rather deep, if you think about it. My gut feeling,
| coming from experience, is that the future lies with DSLs. A
| good programmer would mold the the general-purpose language he
| works with into a DSL fitting the problem at hand anyway (using
| whatever means available, e.g. macros or generics or both).
| Incidentally, the modern Lisps and C++ look the best in this
| regard.
| compiler-guy wrote:
| Carbon is intended to kill C++ in just the same way as C++ is
| designed to kill C, Kotlin is designed to kill Java, and Dart
| is designed to kill Javascript.
|
| Which is to say, "Not at all".
| Koshkin wrote:
| Well, to be fair, "successor" can indeed be understood as
| "replacement."
| m4nu3l wrote:
| I had been thinking about something like this for a long time.
| There is just too much C++ code out there but C++ (despite many
| efforts by the standard committee) is still too verbose and hard
| to make sense of in many cases. So I thought "why not designing a
| new language that is compatible with C++?"
| twen_ty wrote:
| No. No. No.
|
| This reminds me of Dart - another big company thinking they can
| invent a new language to tackle old language problems.
|
| This is not the way to improve C++ - because this path already
| exists, either as D or if compatibility or OO model isn't an
| issue, Rust.
|
| C++ has been improving slowly but surely - just remember that 90%
| (heck even more) of C++ issues stem from the hell that's
| compatibility with C and that's both a blessing and a curse.
| ironman1478 wrote:
| Google is in the business of making software in exchange for
| money and they have internally determined that the way C++ is
| and the direction C++ is headed isn't good for them. They don't
| "care" about C++, they care about running a business. They have
| determined that C++ as it is isn't sufficient and the direction
| its going is not acceptable to meet long term goals, whether
| that be implementing new products or maintaining existing
| software. Google has wholly unique software organization
| problems that very few other companies probably have.
|
| If you've seen their cppcon talks, you'll see that the changes
| they want are not what the committee (or even the general c++
| community) focuses on (for example, I couldn't care less about
| ranges). For example, they want to make changes to unique_ptr
| because the inefficiencies in the ABI cause performance issues
| and probably can be tracked to additional cost per month. They
| couldn't make these changes without changing ABI. At google
| scale, small inefficiencies add up so fast.
|
| I have no doubt they looked at D and saw that it wasn't
| feasible (for whatever reason) and they already stated why Rust
| is not sufficient. They wouldn't make this decision arbitrarily
| and we are not privy to all the meetings that went into the
| decision making process.
| ehzy wrote:
| Do you mind sharing a reference for the changed Google wanted
| to make to unique_ptr? I tried searching but couldn't come up
| with the right set of keywords to find anything relevant. TY!
| ironman1478 wrote:
| Its in this talk
| https://www.youtube.com/watch?v=rHIkrotSwcc
| piperswe wrote:
| Same big company actually - Dart and Carbon are both Google
| projects
| dleslie wrote:
| I was interested and intrigued, but then: // A
| dynamically sized array, like `std::vector`. var
| circles: Array(Circle) = ({.r = 1.0}, {.r = 2.0});
|
| Yegads, they've put effort into ensuring API and ABI
| compatibility with C++, but they've gone and decided to change
| the meaning of nouns for basic types?!
|
| Why, just why would introducing that obvious footgun be
| appealing? It raises the concern that the language is full of
| other arbitrary choices hiding dangerous footguns.
|
| Edit:
|
| Strangely, their test suite makes it look like Array is bounds
| checked and fixed size; there is no test for resizing:
|
| https://github.com/carbon-language/carbon-lang/tree/trunk/ex...
| mda wrote:
| Why is it an obvious footgun?
| [deleted]
| dleslie wrote:
| A developer familiar with C++ may believe it to be a fixed
| length container (perhaps with automatic bounds checking[0])
| and treat it as such in memory/security/performance critical
| sections.
|
| 0: https://en.cppreference.com/w/cpp/container/array/at
| xigoi wrote:
| And if they named it "vector", a developer familiar with
| mathematics might believe it to be a vector.
| bmacho wrote:
| Which is not a footgun.
| Banana699 wrote:
| It actually can be, mathematical vectors gaurantee for
| example that x+y == y+x for all x,y, but no such
| gaurantee can be ever made on the user-defined operator+,
| indeed you can't even gaurantee that it is defined to
| begin with, let alone in the manner prescribed by linear
| algebra.
| yakubin wrote:
| It's std::vector that was weirdly named. In plenty of codebases
| "Vector", particularly gamedev and scientific, will mean the
| mathematical object with that name.
|
| Other languages don't need to replicate this mistake.
| [deleted]
| cnity wrote:
| True, though in OP's defense I don't know if I've ever seen a
| language refer to a growing list of entries as an "array".
| slt2021 wrote:
| Object Pascal's arrays are dynamic.
|
| var kek: array of int;
|
| setlength(kek, 666); // kek is now int[666]
|
| setlength(kek, 1337); // kek is now int[1337]
| linkdd wrote:
| Well, the data structure is called a dynamic array
| cnity wrote:
| I don't see any reference to it in the GH readme, but I
| do wonder what they call actual arrays (as in, fixed size
| allocations of memory that store a contiguously typed
| value).
| linkdd wrote:
| I was talking about std::vector (and Rust's Vec). Those
| are dynamic arrays (as in, growable allocations of memory
| that store a contiguously typed value).
| yakubin wrote:
| Java: ArrayList
|
| Zig: ArrayList
|
| GLib: GArray
|
| Objective-C: NSMutableArray
| domenukk wrote:
| FWIW, ArrayList is a List, backed by Arrays.
|
| So List would have been the more Java/Zig way to name it
| (also Python, etc.)
| yakubin wrote:
| _> FWIW, ArrayList is a List, backed by Arrays._
|
| You probably know that, but just to clarify: it's backed
| by a single array, reallocated repeatedly, just like
| std::vector in C++ (although growth factors are
| different, I think).
|
| Just "List" probably risks that some people will jump to
| the conclusion that it's a linked list. I'd probably
| prefer the full "ArrayList". Although personally I'd use
| something like "DynArray"/"DynamicArray".
| cnity wrote:
| These are examples in favor of my point, not against it.
| jsnell wrote:
| Doesn't seem particularly uncommon. Perl, JavaScript, and
| Ruby come to mind if you're really looking for languages
| that use just a raw term "array" with no extra qualifiers.
| fluoridation wrote:
| An std::vector _is_ a vector in the mathematical sense,
| though. It 's a homogeneous tuple. It's just that using an
| std::vector of std::vectors to store a list of points would
| be inefficient.
| Banana699 wrote:
| >An std::vector is a vector in the mathematical sense
|
| No, because you can't prove that std::vector<T> obeys all
| vector space axioms[1] for all T, which is good because
| it's impossible, I can trivially define a T that will break
| any number of axioms and the cpp compiler will happily let
| me instantiate std::vector on it.
|
| [1] https://www.math.ucla.edu/~tao/resource/general/121.1.0
| 0s/ve...
| xigoi wrote:
| A vector can't change its size or contain things that
| aren't elements of a field. A std::vector can.
| fluoridation wrote:
| Yes, you can have a vector of, say, naturals. I'm pretty
| sure you can even create a vector field out of vectors of
| non-reals.
| xigoi wrote:
| Really? What is the additive inverse of (1, 2, 3) [?] N3
| ?
| fluoridation wrote:
| It depends on how you define addition.
| xigoi wrote:
| I guess you could make it a vector space through a
| bijection with the rational numbers, but something tells
| me C++ programmers don't have that in mind when writing
| std::vector<unsigned>. And it doesn't solve the problem
| that C++ "vectors" are resizable.
| fluoridation wrote:
| See my comment above on the subject.
| Koshkin wrote:
| (-1, -2, -3), is it not?
| xigoi wrote:
| That's not a vector of natural numbers.
| Koshkin wrote:
| Ah, missed the N... But more interestingly, the non-
| negative integers 0... _p_ -1 modulo a prime number _p_
| form a field (where -1, -2 etc. appear in a natural way),
| and so their tuples of some fixed length do form a vector
| space.
| Koshkin wrote:
| A "vector field" and a "field" are two completely
| different notions. (And yes, you can _build_ a field from
| integers.)
|
| https://en.wikipedia.org/wiki/Finite_field
| fluoridation wrote:
| My bad. I meant to say "vector space", not "vector
| field". I understand the difference, but I often make
| this mistake because the set of a vector space is almost
| always the set of an algebraic field (i.e. the reals).
| yakubin wrote:
| It's not. Vectors can be added together and multiplied by
| scalars. That they are often represented as tuples of
| coefficients is just notation, doesn't matter for the
| notion of vectors, and vice versa: a tuple is not
| necessarily a vector.
|
| 1. std::vector doesn't have a fixed dimensionality, as
| would a mathematical vector. A fixed-length array actually
| makes more sense as a vector.
|
| 2. It doesn't provide the operations of addition and
| multiplication by scalars out-of-the-box (though you can
| whip up your own). Moreover, in general those operations
| wouldn't make sense for the elements which can be stored in
| a std::vector. E.g. neither multiplying bank account
| numbers by scalars, nor adding two bank account numbers
| make any sense. It would be good if you modelled them with
| types which don't allow those operations. Yet storing them
| in a std::vector makes perfect sense. But std::vector (or
| tuple) of bank account numbers is not a vector.
| fluoridation wrote:
| 1. That doesn't make it not-a-vector. It just means there
| isn't a one-to-one correspondence between std::vector<T>
| and T^n. However, a particular instance x of
| std::vector<T> is still a T^x.size().
|
| 2. Operations are not intrinsic to a set, but to an
| algebra. Why would there need to be any correspondence
| between the operations of linear algebra and those of
| banking algebra in order to call an std::vector a vector?
| yakubin wrote:
| 2. I'm not sure I understand you here. A vector is
| defined by those operations. A set without those
| operations, even if it has the same elements, is not a
| set of vectors anymore. I don't understand your remark
| about sets here. The correspondence is necessary, because
| those operations on vectors are induced from the
| operations of the relevant field of scalars. The
| operation of adding vectors of bank numbers would be
| induced from the operation of adding bank numbers, if
| there was any such thing. The operation of multiplying
| vectors by scalars (bank numbers in this case) would need
| to be induced from the operation of multiplication of
| bank numbers, if there was any such thing. Anyway, I
| think you got hung up on the example, when the point is
| you can have std::vectors of types for which those
| operations don't make any sense. Now, imagining that
| perhaps there hypothetically might exist some definitions
| of those operations, just to convince oneself that
| std::vector is a vector is really stretching it, and I'm
| not even sure at this point if you're not trolling.
|
| Anyway, as another commenter pointed out, Stepanov
| himself, who gave this container its name, said that it
| has nothing to do with vectors, and he wouldn't name it
| vector, if he could correct this mistake.
| fluoridation wrote:
| A vector is defined as I did above. It's a homogeneous
| tuple, i.e. the Cartesian product of n sets, where all
| sets are the same. Vector addition plus scalar
| multiplication are not part of the set. Usually they're
| part of the definition of a vector space. E.g. (R^2, +,
| [?]). But you can construct a vector space out of a set
| of non-vectors (such as matrices), or out of operations
| other than vector addition and scalar multiplication, and
| you can use vectors for purposes other than constructing
| vector spaces, also without involving either of those
| operations. For example, to store sequential information.
| bmacho wrote:
| A vector is definitely not defined as you did above.
|
| A vector is an element of a vector space, basically
| anything that you can add together and multiply with an
| element of a field. It has nothing to do with what you
| wrote above.
|
| [] : https://en.wikipedia.org/wiki/Vector_(mathematics_an
| d_physic...
| yakubin wrote:
| Then you're using a definition of vector, not used in any
| mathematics course.
|
| _> you can construct a vector space out of a set of non-
| vectors (such as matrices)_
|
| A vector is by definition no more and no less than an
| element of a vector space. Vectors are defined by vector
| spaces, not the other way around.
|
| If you have a vector space whose elements are matrices,
| then those matrices are vectors. And they will be written
| in coefficients in a given base as tuples.
|
| _> out of operations other than vector addition and
| scalar multiplication_
|
| You don't "build vectors out of operations like vector
| addition and scalar multiplication", as in: you don't
| choose them. You choose the field and dimension, and
| those operations (vector addition and scalar
| multiplication) are a consequence.
|
| _> you can use vectors for purposes other than
| constructing vector spaces, also without involving either
| of those operations_
|
| Again, you don't construct vector spaces out of vectors -
| there are no vectors without vector spaces. And there are
| no vector spaces without those operations. But yes, you
| can use vectors from a given vector space in a greater
| capacity than just as vectors.
|
| An example, which shows the futility of looking at
| vectors as just tuples: a real number is a vector in the
| vector space of real numbers over the field of rational
| numbers.
| fluoridation wrote:
| >Then you're using a definition of vector, not used in
| any mathematics course. [...] A vector is by definition
| no more and no less than an element of a vector space.
|
| It's the definition I was given. If you accept that the
| word "vector" may be given a definition different from
| the one you give it, you'll need to concede that an
| std::vector _may_ be a vector.
|
| >you don't choose them. You choose the field and
| dimension, and those operations (vector addition and
| scalar multiplication) are a consequence.
|
| You're using the phrase "vector addition and scalar
| multiplication" in a different sense than I meant. I was
| referring to component-wise addition between two vectors
| and to multiplication between a scalar and the individual
| components of a vector. You could choose different
| operations to construct a vector space, as long as they
| meet the requirements of vector spaces.
|
| You used the phrase to refer to the constructing
| operations of a vector space. So yes, a vector space is
| indeed constructed out of the operations it is
| constructed out of. You could have been more charitable
| in your interpretation of my words, rather than assume I
| was saying something equivalent to "four-cornered
| triangle".
| Koshkin wrote:
| Worse, they have been calling the location of a pointer
| to a subroutine that handles an interrupt a "vector" -
| the word which was originally used to refer to the entire
| set of such locations. (Curiously, this usage is similar
| to how the word "sector" is used to refer to a physical
| record on a disk - simply because it usually comes last
| in the coordinate triple (cylinder, track, sector). This
| would be like calling a point in the 3-dimensional space
| a "Z".)
| Kranar wrote:
| No it's not and even Stepanov, the person who gave it its
| name, has admitted it was a mistake:
|
| Link to lecture by Stepanov:
| https://www.youtube.com/watch?v=etZgaSjzqlU
|
| Furthermore in his book "From Mathematics to Generic
| Programming", Stepanov says that if he could change its
| name, he'd have named it "array".
| Koshkin wrote:
| Indeed, "vector" appears to be relatively recent
| terminology, it has been "array" since the dawn of
| programming. But it's too late now, and we already have
| the std::array anyway...
| kllrnohj wrote:
| Java's Vector looks around awkwardly, hoping everyone forgets
| it existed... ;)
| yakubin wrote:
| Actually, I've never known it existed. You're the one who
| reminded me now. :)
| dleslie wrote:
| And yet it is the name used in C++ code for a variable length
| container of contiguously stored data.
| marssaxman wrote:
| This is intended to be a _different_ language, is it not?
| dleslie wrote:
| Not wholly different; it appears to be intended to
| interop with, and progressively replace C++ in existing
| projects.
| alok-g wrote:
| Awesome! I was looking for an alternative to C++ that cleans it
| up!
| hexo wrote:
| Doesn't look much like C++ successor to me, at all. What's up
| with all those fns, and functions starting with uppercase?
| nikeee wrote:
| Looking at this [0] news from about a month ago, the Chrome team
| showed that they are trying to bring Rust to the table. However,
| their wording was:
|
| > The Chrome security team is working to make a cross-platform
| memory safe language available to Chromium developers. This
| document describes how to use that language in Chromium. The
| language, at least for now, is Rust.
|
| Could this mean that the "at least for now" part might hint to
| the language discussed in this thread? Memory safety seems to be
| a core goal of Carbon [1]:
|
| > Safer fundamentals, and an incremental path towards a memory-
| safe subset
|
| This approach could make sense, looking at their large C++ code
| base in Chrome.
|
| [0]: https://news.ycombinator.com/item?id=31830020 [1]:
| https://github.com/carbon-language/carbon-lang
| tialaramex wrote:
| Sure, the Chrome security team have got a problem, Rust has a
| solution, if somebody comes along with a better solution why
| wouldn't you.
|
| But, right now Carbon doesn't have a better solution, it only
| has an ambition to build an incremental path toward being able
| to be a solution.
|
| Importantly it has an _ambition_ but it has no proposal for how
| to get there. There are other safe languages, but AFAIK none of
| them launched with "Eh, we'll do safety later, I'm sure we
| don't need to start with it". The ones I'm thinking of all
| began with their safety principles and then they added cool
| features which were inspired by those principles.
|
| I reckon that even if that's not directly causal, it means the
| culture associated with these "We'll do safety later" languages
| doesn't prioritise safety highly enough. So ambition or not,
| they aren't going to put the hard work in to make it actually
| happen.
| pkasting wrote:
| I work on the Chrome team. Safety is not the only goal for
| the codebase. There's also things like readability,
| maintainability, performance, and correctness. Finally,
| there's the need to chart a course towards how you get there.
|
| Rust provides many of these, but not much of an incremental
| path there. Carbon aims to provide many of these, but not as
| much safety as Rust (likely, even in the future). The upshot:
| there are tradeoffs, and we'll need to watch our options and
| make continual decisions as to the best courses of action.
| Such courses may differ by area of the project; it's possible
| we might choose to write some hardened services in Rust
| communicating via Mojo with mixed C++/Carbon code.
| lenkite wrote:
| Please let them make a proper interpreter for dev efficiency!
| saagarjha wrote:
| (Speaking only for myself, I just watch from the sidelines and
| have no involvement)
|
| This seems like Google's response to
|
| 1. Rust not being sufficiently "Go-like" (in the sense of the
| "The key point here is our programmers are Googlers, they're not
| researchers" quote) where C++ lets a bunch of people who are not
| really experts in the language write footguns that Google has to
| deal with when they cause problems at scale. They want a dumbed-
| down language (some would use words like
| approachable/safer/whatever here) for them so nobody will send in
| CLs with "clever" code that causes headaches later. I guess
| they'll need to have generics but I'm guessing that choices will
| be made to avoid introducing advanced type theory, functional
| programming, etc into the language.
|
| 2. Google uses C++ differently than everyone else who uses C++.
| In particular, they have a lot of statically linked code from a
| monorepo that gets recompiled all the time. This has caused them
| to put up proposals to "fix" the language that nobody else will
| support and don't get adopted, because they break the ABI or
| backwards compatibility in ways that are unacceptable to the
| others who participate. It seems like this language is the result
| of that frustration and subsequent soft-withdrawal from the C++
| WG.
|
| I haven't looked at the design much yet beyond just the simple
| examples and I think it mostly looks reasonable, but I feel like
| Google designed this to solve their problems with C++ and is just
| throwing it out there if people are willing to adopt it because
| it's there and Google says it's good, just like how Go gained
| traction. Sometimes Google does make good things :) Some Go
| developers would say that about Go, I'm sure. But if you're using
| this, it seems pretty clear that the needs of this will be driven
| by Google, and the above two points are probably things you
| should keep in mind as you watch it evolve.
| zozbot234 wrote:
| My guess is that it's pretty much all about 2. They say
| explicitly in their FAQ that you should be using Rust, or any
| other well-established language, if not constrained by the need
| for deep, complex interop with C++ code bases. They're not
| positioning this as a "more approachable" alternative to Rust,
| only as one that sticks closer to existing C/C++ coding
| patterns.
| sudosysgen wrote:
| To be fair, for many many many people there is a requirement
| for deep, complex interop with C++. Even if you're getting
| started on a new project being able to easily leverage the
| C++ ecosystem could make or break it.
| pjmlp wrote:
| Hence why I love C++/CLI, way easier than getting P/Invoke
| attributes right.
| mkoubaa wrote:
| I work at smaller scale c++ than google and I found most of
| their proposals reasonable but undoable for practical reasons
| rather than first principles reasons. For instance compiler
| vendors who have a veto power over language changes strongly
| prefer not breaking ABI. ABI changes are fine if you build the
| world at every commit, but also if you don't have legacy. C++
| users 200 years from now would most likely benefit from the
| things Google wishes it could do in the language but can't
| Jabbles wrote:
| (1) does not seem true, they have documented some seemingly
| detailed reasons why Rust is not always the right choice, and
| acknowledge that in many cases it is:
| https://github.com/carbon-language/carbon-lang/blob/trunk/do...
| coder543 wrote:
| > 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, Carbon, or C++... the lifetime of shared
| memory _must_ be well-understood by the developer writing the
| code. Rust just makes this problem explicit and enforceable.
| Sweeping the problem under the rug _isn 't_ a better option.
|
| > However Rust imposes stricter rules than C++, disallowing
| some design choices that were valid in C++.
|
| The word "valid" is doing a lot of heavy lifting here, and
| I'm generally skeptical of these "valid" architectures. If it
| is so easy to know that these architectures are valid, why do
| we still see so many memory safety issues in Google's C++
| code? Incrementally restructuring C++ code to be more
| provably correct doesn't sound like a terrible thing... in
| fact, it sounds like exactly what they should be doing.
|
| > However, we are not certain that [C++ can be migrated to
| Rust incrementally]
|
| Firefox is a large, historically C++ codebase that has
| undergone incremental rewrite into Rust for years now. It
| seems _quite_ certain that this is both possible and
| practical! Where is the uncertainty? Of course, Mozilla 's
| budget pales in comparison to Google's.
|
| Rust is an extremely extensible language, and it is
| absolutely possible for Google to build their own version of
| `rust-bindgen` that suits their particular C++ codebase's
| idioms. That would be a much simpler undertaking that
| achieves their goal of incrementally adopting memory safety.
|
| I hate to disparage new languages, but this feels like Swift
| all over again... it's just NIH. At this point, the die has
| been cast, and I'm sure it would be career suicide in Google
| for anyone behind the Carbon project to admit at this stage
| that " _actually_ , the project turned out to be unnecessary
| after a discussion on HN!", so I don't expect to change
| anyone's mind. I'm just wasting my breath making obvious
| counterarguments that I'm sure have already been considered
| and ignored.
|
| To be extra clear, I would love to see a company like Google
| take on the challenge of building an ergonomic language that
| _exceeds_ Rust in terms of safety, but Carbon is a half-
| measure that doesn 't pretend otherwise. If all of Google's
| C++ code is magically rewritten in Carbon, they will still
| apparently have memory safety problems based on what Carbon's
| README says... and then it'll be time once again to consider
| "maybe we should have ported to Rust after all". It just
| feels like such a waste.
| zozbot234 wrote:
| > 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-pinned
| (non-movable) data. This creates unneeded pitfalls in
| Rust-C /C++ interop. The counterargument is that _future_
| versions of that library code might benefit from those
| stronger preconditions, but that 's more of a theoretical
| point, it just doesn't apply in most cases.
| coder543 wrote:
| 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 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.
| zozbot234 wrote:
| 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). It's a recurring topic on the
| Rust Internals forum.
|
| "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.
| coder543 wrote:
| > 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 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.
| joshuamorton wrote:
| > Rust compiler that makes this behavior well-defined in
| a way that suits them during the transition period as C++
| code is rewritten
|
| 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.
| coder543 wrote:
| > To be clear, this is "forever"
|
| I guess I didn't finish my thought in that comment,
| because it isn't forever... it's only until either the
| C++ is gone, _or_ the Rust language has developed an
| equally acceptable alternative (which could be upstreamed
| by Google, or come from somewhere else).
|
| And realistically, the C++ would never have to go away
| entirely for this UB handling fork to become unnecessary,
| depending on the driving factors. Some code paths are
| more performance sensitive than others, and these tend to
| represent a small portion of the overall code. Once the
| performance sensitive code paths are rewritten, it
| matters less whether there is a small performance penalty
| for the remaining C++ code that is less sensitive to
| performance. But, at Google Scale, the cost of the
| developer-hours to maintain that fork would probably be
| less than the cost of the small increase in CPU hours
| that removing the fork would result in, so... yeah, maybe
| forever or until there is an upstream solution.
| Maintaining a patchset like this would still cost way
| less than maintaining an entire compiler and all the
| language tooling needed to support that language... does
| anyone really disagree? A new language is far more than
| just a compiler, let alone a patch for a compiler.
|
| > Would that be a good idea for anyone?
|
| IMHO, it definitely seems better than Carbon.
| zozbot234 wrote:
| But the way the Rust compiler works today is quite
| acceptable already. This isn't a Rust-the-language
| problem other than in secondary ways that are hard to
| address by definition (such as "movable" data being the
| default and Pin<> references being special), it's a Rust-
| the-library-ecosystem (including, but not limited to, std
| and/or core) issue. It can only be addressed as such.
| saagarjha wrote:
| Google can have many reasons why they do something. Not all
| of them will always be listed publicly, or even be written
| down :)
| germandiago wrote:
| True for sure. This made me laugh. Lol.
| germandiago wrote:
| Wow, this one looks really interesting. It is 100% interoperable?
| underdeserver wrote:
| If you want to me to buy it, show me an automatically translated
| C++ snippet.
| StillBored wrote:
| I've seen this fn/var argument a few times, but its a really that
| much harder to write a parser that can intuit the difference
| between a function/variable/statement without explicitly putting
| function/var/let/etc all over the place?
|
| I like the verbosity of a language like pascal, but I just find
| it jarring in a C replacement these days. (and rust's structure
| definitions/etc I just find needlessly verbose for the way I use
| C structures).
|
| C is nice because its fairly easy to mentally parse (C++ less so)
| vs some of the alternatives, while still being extremely concise.
| xigoi wrote:
| The C way makes it hard to find the name of the function (or
| even tell that it's a function declaration) when the return
| type is long.
| std::vector<std::unordered_map<std::string,
| std::pair<std::string, std::string>>>
| foo(std::vector<std::vector<int>> x,
| std::unordered_map<std::string, std::string> y);
| StillBored wrote:
| I said C++ was diff, but how about: using
| namespace std; typedef vector<unordered_map<string,
| pair<string, string>> foo_bar_xref; foo_bar_xref
| foo( vector<vector<int>> x, unordered_map<string, string> y);
|
| not sprinkling std:: everywhere helps with readability, but
| so does defining a couple types used frequently, especially
| if they are particularly verbose. And of course the parser
| doesn't really have a problem with this, so your editor
| should be able to find it with its 'goto declaration'
| function. I don't feel pity for people who chose to use
| editors/IDEs that make this difficult.
| xigoi wrote:
| > not sprinkling std:: everywhere helps with readability
|
| I agree, but most C++ programmers don't :/
|
| > And of course the parser doesn't really have a problem
| with this, so your editor should be able to find it with
| its 'goto declaration' function.
|
| C++ syntax is Turing-complete, so due to the halting
| problem, finding the declaration can take a long time,
| potentially unlimited in pathological cases.
| int0x80 wrote:
| >C++ syntax is Turing-complete, so due to the halting
| problem, finding the declaration can take a long time,
| potentially unlimited in pathological cases.
|
| Absolutely not unlimited time. Once it's parsed and
| semantically analyzed you can find the declaration in no
| time. Exactly like the compiler does.
|
| edit: to clarify, I was not taking into account unbounded
| recursion on template instantiation, which should be
| limited in any case by the compiler.
| vitno wrote:
| It's not immediately obvious from this page and GitHub org, but
| this is a Google led project. It's led by Chandler and the c++
| toolchain team. I have no idea of it's endgoals or how open to
| non-Google ideas it will be.
| epage wrote:
| > this is a Google led project
|
| This doesn't give me much confidence if its Corporate
| governance rather than open governance.
| vitno wrote:
| The governance of the project is not immediately clear to me,
| and I have to assume that the Google team is working in good
| faith. That team cares a lot about C++ and its future. They
| are obviously aware of this stigma. I also think that Google
| is pretty bad at open source governance though :/
|
| Disclosure: Former Google engineer who worked sorta adjacent
| to some of those people.
| chandlerc1024 wrote:
| FWIW, our governance structure is here:
| https://github.com/carbon-language/carbon-
| lang/blob/trunk/do...
| runevault wrote:
| Huh looking at that page and saw Kate Gregory is
| involved. She's someone who, as a mostly outsider who
| dabbles in C++ occasionally, seemed incredibly dedicated
| to seeing C++ thrive and people come to understand the
| language. Her involvement here seems like a huge positive
| to me, but maybe that's coming from a place of ignorance.
| vitno wrote:
| Hahaha, I really like the "painter" terminology. A+
| foonathan wrote:
| Based on what they've told me the long term governance plan
| is to establish an independent foundation, with development
| controlled by three equal lead developers from different
| companies.
|
| It may have been started by mostly Googlers but they want
| other companies and individuals to participate
| vitno wrote:
| Official governance vs the effective governance is the real
| crux of this issue. Immediately starting from the lead
| developers separated by companies already puts a deep
| corporate interest spin on the project. Choosing to do a
| lot of the initial work in secret and then disclosing is
| also a pretty big data point.
|
| I think this is going to be an uphill battle for them and I
| hope they win it but I'll be skeptical unless if I start
| seeing radical (for google) transparency basically
| immediately.
|
| Also worth pointing out that the language is not
| immediately worthless even if they fail or only partially
| succeed in this endeavor!!
| dleslie wrote:
| Nor does it convey any confidence that Google will support
| it.
| DashAnimal wrote:
| Can we not with this tired joke. Yes we're talking about
| the company with hundreds of chat apps, but we're also
| talking about the 100,000+ employee company that developed
| and support Golang, Dart and Flutter. But ignoring all
| this, the GitHub page is pretty clear: "Carbon is currently
| an experimental project." You shouldn't have confidence
| that it will be supported but they are pretty clear about
| it, they're trying to find the right fit.
| dleslie wrote:
| I wasn't joking.
|
| But yes, I agree, we should have no expectation of
| support for experimental or beta products.
| thesuperbigfrog wrote:
| >> Can we not with this tired joke. . . . You shouldn't
| have confidence that it will be supported . . .
|
| It is not a joke.
|
| It is a reputation that Google has earned through its
| actions and inactions.
|
| As shown by https://killedbygoogle.com/ and numerous
| desperate posts for help [1][2][3] on this and other web
| sites, Google's "must launch a new shiny thing" promotion
| culture and abysmal customer service have eroded public
| trust in the long-term viability of anything that Google
| creates.
|
| [1] https://news.ycombinator.com/item?id=5523992
|
| [2] https://news.ycombinator.com/item?id=13145927
|
| [3] https://news.ycombinator.com/item?id=31837795
| rvz wrote:
| So you had no problem with Golang being led by Google for
| more than 10 years and now this new language is somehow a
| problem because that one is also led by Google?
| epage wrote:
| This is assuming a lot about me when in fact
|
| - I don't use golang - As an outsider, the governance has
| seemed unhealthy like with how dependency management was
| dropped out of no where
|
| However, it has been relatively successful. Dart's success
| has been more mixed. I am also looking more broadly at
| projects like Bazel.
| pif wrote:
| No good can result from the interaction between the most
| complex and powerful programming language and the corporation
| who created the programming language for dummies.
| endtime wrote:
| They also created Dart, which is a joy to write.
| brandmeyer wrote:
| > A key example of this is the committee's struggle to converge
| on a clear set of high-level and long-term goals and priorities
| aligned with ours [https://wg21.link/p2137].
|
| I was frankly shocked by that goals and priorities document.
| The non-goals section reads like an open declaration of war
| against anyone whose use cases for C++ differ from GOOG and
| NVDA. My interpretation of Carbon is that since GOOG failed to
| take over the standard in favor of its narrow use cases, that
| they are building a new language optimized specifically for
| them.
|
| > I have no idea ... how open to non-Google ideas it will be.
|
| The most-generous attitude to take is that it will be managed
| similarly to Go. If your use cases and priorities are well-
| aligned with theirs, then feel free to use it. But while they
| may listen to third-party feedback, it will be their own use
| cases and opinions which dominate the language's development.
| gpderetta wrote:
| I don't necessarily agree with all their design goals, but it
| is unfortunately true that getting a large coherent change
| through the C++ committe is an herculean task. The language
| ends up doing a random walk via small steps through the
| design space without a coherent long term vision, because
| nothing else is feasible.
|
| Implementing a coherent vision might lead to a better
| language even if most stakeholders might disagree with every
| single change.
| compiler-guy wrote:
| There are weird governance issues with the C++ committee
| too. Acceptance or rejection of a feature can depend on
| which reps just happen to show up that day.
| throw827474737 wrote:
| > GOOG and NVDA
|
| Why use these stock index abbrevs (or whatever they are) in
| this context here? GEEZ!
|
| To the topic, it sounds a bit grumpy. If we look at languages
| and how many evolve... many suffer the phenomenon that they
| almost all are Turing complete, and try to gain concise (or
| simple understandable) expressiveness somehow, and then they
| try to not break compatibility too much to varying degrees -
| net result: they grow and grow where at one point they feel
| like too big, too much legacy dragged around (C++), the "one
| obvious way" lost (Python) when they cater for use case after
| use case.
|
| Limiting can be good in that regard. So having key goals
| defined and not to cater to every small new usecase by
| someone is a valid attempt to not let this happen, so while I
| dislike Googles power, I wouldn't feel to bad with attempting
| this by anyone on their fresh language?!
| baxuz wrote:
| Oh so that's what they are.
| grimfang4 wrote:
| It's an implication that the driving force for the
| development is money. By the way, jump on the GEEZ train,
| that stock's gonna go through the roof!
| jcranmer wrote:
| Bits are in such short supply these days that it's
| necessary to save 32 of them. Think of all the things you
| could be doing with those 32 bits!
| chandlerc1024 wrote:
| (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 already seeing strong
| interest from other companies and organizations in
| participating in this experiment.
| the_duke wrote:
| 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 careful and audit lots".
|
| But if all code can freely interoperate with C++, how do
| you improve upon C++, apart from relatively isolated
| features like a better generics system?
|
| To what extend can a Carbon compiler that is deeply aware
| of C++ semantics mitigate the pitfalls?
| IshKebab wrote:
| C++ has many many issues other than memory safety. For
| example implicit type conversion, template duck typing,
| the include system, the very very _very_ complicated name
| lookup system, a gazillion footguns inherited from C.
|
| You can definitely massively improve upon C++ without
| touching its actual computation model.
| pjmlp wrote:
| Starting by using a sane set of compiler flags to make
| code safer by default.
| gpderetta wrote:
| while we have you here, may I ask why is it called Carbon?
| It is because the symbol for atomic carbon is C ? :)
| unethical_ban wrote:
| To make it as hard to search for solutions online as it
| is for "go".
| fractalb wrote:
| Tangent. Absolutely loved your CPPCON talks. Thanks.
| overgard wrote:
| I really don't see that. At the very start they say
|
| > That said, our experience, use cases, and needs are clearly
| not those of every user. We aren't pushing to directly build
| consensus on these points. Rather, this is presented as a
| vehicle to advertise our needs from C++ as a high-performance
| systems language.
|
| The point of the non-goals is simply stating things they
| don't care about, which is pretty reasonable. After all, it's
| easy to say what you want, but what are you willing to give
| up for it?
| zozbot234 wrote:
| Sounds a bit like "C++ but we get to change the ABI, and maybe
| break some old code for the sake of better-enforced safety
| guidelines".
| klodolph wrote:
| C++ also has a very hard-line "you don't pay for what you
| don't use" philosophy, which sometimes lead to standard
| library APIs or language semantics which are a bit tortured.
|
| Compare C++ <random> or <chrono> against, say, the equivalent
| functionality in Rust, Go, Java, C#, etc. C++'s APIs are a
| bit overcomplicated, or at least they look that way if you
| don't know the various reasons why the C++ standard defined
| them that way (reasons which are probably not relevant to
| your use cases).
| Kukumber wrote:
| This is the proper way to replace C++, being able to fully
| consume it
|
| Just like Kotlin did to Java
|
| The only viable alternative to C++ imo
| anarazel wrote:
| Requiring Google's CLA to be signed to contribute seems pretty
| limiting...
| smallstepforman wrote:
| Not for gamedev or protocol stacks since no pointer arithmetic
| ...
| hobo_mark wrote:
| Looks like this experiment has been going on for a couple of
| years, a bunch of familiar (internet-familiar, have met Chandler
| a couple of times but do not know any personally) names were
| secretly working on it, and it was only made public a few days
| ago:
|
| https://github.com/carbon-language/carbon-lang/pull/1363
| epage wrote:
| It seems that the goal is a new language with full interop with
| C++, kind of like Zig's interop with C.
|
| - I wonder how much baggage had to be maintained for interop. If
| some of it could be isolated, how did they do it?
|
| - Does this fall into any of the traps that D initially did where
| it allowed C interop but was, by default, more limited in what C
| environments it could run in or is this as flexible as C++ for
| environments?
|
| As for the language itself, I've not had a chance to dig into it
| too much but I am sad to see that it uses explicit local
| inference by replacing the type name with `auto` rather than
| eliding the type completely [0]. While it has its pains at times,
| this is something I've come to enjoy in Rust.
|
| I also didn't see mention of tooling. Having out-of-the-box
| build, test, and code formatting would be a big help for
| establishing community standards / practices, even if the
| build/test tool might get limited when having to do C++ interop.
| At least for pure-Carbon libraries it would be a big help!
|
| > Once we can migrate code into Carbon, we will have a simplified
| language with room in the design space to add any necessary
| annotations or features, and infrastructure like generics to
| support safer design patterns. Longer term, we will build on this
| to introduce a safe Carbon subset. This will be a large and
| complex undertaking, and won't be in the 0.1 design. Meanwhile,
| we are closely watching and learning from efforts to add memory
| safe semantics onto C++ such as Rust-inspired lifetime
| annotations.
|
| I'm a bit skeptical if they push off lifetime annotations too
| far.
|
| [0] https://github.com/carbon-language/carbon-
| lang/blob/trunk/do...
| [deleted]
| ape4 wrote:
| I know lots of languages are going with exactly saying the size
| of your numbers like "i64". In C/C++ you would say "int". Of
| course sometimes you want to declare and exact size but for a
| regular integer it seems simpler to say just "int".
| nikolay wrote:
| Well, `returned var` is totally unnecessary - why didn't they
| borrow the syntax from Go?!
| masklinn wrote:
| https://github.com/carbon-language/carbon-lang/blob/trunk/pr...
|
| > Disadvantages:
|
| > - The syntax space of the return type is very crowded
| already, and this would add more complexity there rather than
| fitting in cleanly with existing declaration spaces within the
| body of the function.
|
| > - Likely to be an implementation detail and valid to use on a
| function with a normal return type in its forward declaration.
| This isn't obvious when placed in the declaration position, and
| it might well be unnecessarily added to forward declarations
| just because of its position.
|
| > - Removes the ability to both specify a specific return type
| and a pattern for binding parts of that object to names.
| Instead, the type must be inferred from the pattern. This ended
| up feeling like a deep and fundamental problem where we would
| lose important expressivity to disambiguate the return type
| from patterns. For example, when the return type is some form
| of sum type or variant, the pattern space is both especially
| attractive to use and fundamentally fails to express enough
| information to capture the type.
| mlinksva wrote:
| I don't see the name explained anywhere in the excellent FAQ and
| other documents, but I wonder if it a play on
| Rust/Oxidize/Oxidization -> Carbon/Carbonize/Carbonization.
|
| Only mention of those terms seems to be
| https://github.com/carbon-language/carbon-lang/issues/505 which
| seems like weak evidence against naming conjecture.
| sparkie wrote:
| I'm still waiting on SPECS (1998)
| (https://users.monash.edu/~damian/papers/HTML/ModestProposal....)
|
| But I don't think a re-sugaring of syntax is enough to make
| people switch.
___________________________________________________________________
(page generated 2022-07-19 23:00 UTC)