[HN Gopher] Circle Evolves C++ [video]
___________________________________________________________________
Circle Evolves C++ [video]
Author : pjmlp
Score : 58 points
Date : 2023-08-15 06:51 UTC (1 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| olliej wrote:
| I do love the co_await, co_..., saga because JS has the same
| issue, only worse because all JS on the web always starts as
| source code, at least when you're running shipped C++ it has
| already been compiled and hence language changes don't impact
| already shipped code.
|
| For example when JSC first implemented support for `let`
| (apparently first or with the most effective testing?) we rapidly
| found site breakages. The first one I looked at was (IIRC) the Le
| Monde newspaper in France, which was doing some kind of parsing
| with a variable named `let` for the current letter. Rather than
| making the language more annoying to use, we updated the spec to
| allow let to be an identifier, which is perfectly reasonable as
| the let syntax is unambiguous. That's a tiny amount of complexity
| for the implementer to produce a much cleaner to use language for
| developers.
|
| There's similar with `of` in for loops - `of` is syntactically
| only valid in that location, there's negligible implementation
| cost in not requiring it to be a keyword, but it allowed the
| improved iteration syntax to be introduced to the language
| (Obviously there are a bunch of more common syntaxes that are
| more consistent with other languages, but for imo stupid reasons
| I couldn't use any of them and had to come up with a new one
| :-/).
| carterschonwald wrote:
| I tried to find where i could get ahold of the circle compiler a
| few months ago, and ... i couldn't find any info about license or
| where to download!
| jbverschoor wrote:
| They need an audio engineer
| kitanata wrote:
| [flagged]
| morby wrote:
| I didn't watch the whole thing due to the audio, but what I have
| seen is this still not ultimately a new language? As someone else
| here stated, the compiler is determining if the code it sees is
| Circle or C++ so that means it's handling them differently. Which
| means all the legacy cpp code would never touch this and people
| who already started cpp would need to maintain two separate
| flavors of the language. Maybe I am misunderstanding this
| project.
| hmry wrote:
| Don't see how that follows. Typescript treats code as either TS
| or JS depending on the file extension. But that doesn't mean
| nobody who has JavaScript code would switch to Typescript. The
| idea is, you migrate one file at a time. With Circle it's even
| more gradual, since you can migrate one file one feature at a
| time.
| gpderetta wrote:
| I think the idea is that you can migrate a translation unit at
| a time anda feature ata time while still being able to link
| your whole application. Not differently from the migration path
| between c++ revisions.
| benji-york wrote:
| As someone with a lot of live audio background, I lament bad
| audio at conferences. I keep thinking that there is a product
| need there, but it feels too much like selling vitamins.
| AlexanderDhoore wrote:
| In Rust each crate can be compiled with a different edition. If
| we had this in C++ you could compile one file/module with C++11
| and another with C++20. The compiler defaults could change for
| new code, but be kept the same for old code. Nothing breaks. You
| opt-in to the new standard one file/module at the time.
| pornel wrote:
| Fun fact: internally it's not per crate, but per AST node. This
| is because macros can be imported across crates that use
| different editions, and still work as expected.
| senkora wrote:
| > If we had this in C++ you could compile one file/module with
| C++11 and another with C++20.
|
| I'm not 100% confident but I think you can do this already*.
| What you can't do, is compile each file with a different
| compiler or stdlib release.
|
| There's just no reason to do it because C++11 and C++20 are
| forwards and backwards compatible, so you might as well compile
| everything with C++20 if you're already going to compile it all
| from source.
|
| * An exception is omnibus libraries like abseil that take it
| upon themselves to backport stdlib features to older language
| versions. For example, abseil uses typedefs to define e.g.
| absl::optional as std::optional on newer versions or a custom
| implementation on older versions. If you compile abseil with
| C++11 and your client code with C++20, then you may end up with
| scary runtime errors (not compiletime, because templates are
| compiled in every translation unit, and not linktime, because
| the linker ignores types).
| ithkuil wrote:
| File != Compilation unit
|
| In circle the features are literally per-file. Which means
| you can have a source file that enables a feature and which
| include headers which doesn't use that feature, which in turn
| includes another one that includes that header etc.
|
| At first look it seems that the problem is self inflicted and
| that if we got rid of headers and use modules c++ would be
| like rust.
|
| But even in rust, editions can only be applied at the level
| of a crate. Crates are effectively the compilation units of
| rust
|
| What circle does is more granular and it would be the
| equivalent of a rust edition per module or pet file.
| rewmie wrote:
| > There's just no reason to do it because C++11 and C++20 are
| forwards and backwards compatible, so you might as well
| compile everything with C++20 if you're already going to
| compile it all from source.
|
| This isn't exactly true. The programming language version is
| one dimension of the problem, but there are a few other
| dimensions. For instance, some projects enable/disable
| features based on the language version, and that leads to
| unexpected errors. I recall that Boost caused a bunch of
| problems when upgrading a compiler version on a old legacy
| project just because the subproject enabled constexpr on
| C++11 which caused obscure linker errors out of nowhere.
|
| There is far more to language version upgrades, and even
| compiler version upgrades, than flipping a switch.
| senkora wrote:
| Yep, that's right. I would include that in the same
| exception that I listed, where libraries can choose to
| reflect on the language version that they are compiled with
| and expose different behavior that can cause issues.
|
| I should mention that the pedantic reason why I have
| experience with this is that it is usually okay to compile
| and link with distribution-provided binary packages (where
| you don't control the language version) as long as you use
| the distribution-provided toolchain, and upgrading the
| language version that you use for your code won't cause any
| issues unless one of your dependencies is doing this kind
| of reflection. Some Linux distros will provide separate
| versions of packages for each language version in order to
| solve the problem for libraries like abseil and boost.
| steveklabnik wrote:
| There was an attempt to bring this to C++ but it ran into some
| roadblocks https://github.com/cplusplus/papers/issues/631
| rnikander wrote:
| I agree with his approach but I'm on macOS so I don't think I can
| even use this currently. Anyone know if he has a plan to get this
| out so everyone can use it? It's not like the authors of Clang
| are going to implement this. Is he trying to get the C++
| committee to standardize this idea? Or will he make a commercial
| product? If it were cross-platform I would pay for it.
| [deleted]
| gavinray wrote:
| Circle is the "C++ Successor" language I am most excited about,
| after writing a fair amount of D, and trying the Carbon
| interpreter.
|
| The issue with D is that while it's a great language, and it has
| C++ interop, it doesn't have _direct_ C++ interop. As in, "just
| import an existing header and it works." You have to write or try
| to auto-generate "extern C++" definitions.
|
| The issue with Carbon is that it is slowly-progressing vaporware
| at this point with as-yet-untested C++ interop.
|
| Circle is real, has a "Carbon" mode that makes it syntactically
| identical, and yet has "just import it" interop. It's not open-
| source yet but hey, you can't have everything at once I guess.
|
| ---
|
| (I want to add that I think D is a great language in it's own
| right, just not as "C++ successor")
| geertj wrote:
| I had the same vibes with Herb Sutter's cppfront. It offers
| full source compatibility by introducing a new syntax that can
| be mixed freely with the traditional syntax. Seems like it's
| actively being worked on here
| https://github.com/hsutter/cppfront.
|
| I've not looked at Circle in depth. Do you or anyone else have
| a perspective on how they compare?
| [deleted]
| mokash wrote:
| i believe cppfront is more of a way to try out and
| demonstrate ideas in the hopes that they are adopted by the
| cpp standard
| geertj wrote:
| Not really the way I understand cppfront.
|
| While Herb uses modest language when describing his
| project, my take is that's because it's a huge effort that
| might fail, but it does not indicate lack of ambition. If
| anything, I think this is hugely ambitious. The work in the
| standards committee provides the necessary infrastructure
| to make this feasible in the first place. On his Github he
| lists the changes that went into C++ over the last years
| that enable this prototype.
|
| It's pretty clever really, and dare I say, it seems
| feasible. This essentially creates syntax bubbles inside
| the language where there are different defaults, and then
| transpiles those bubbles to regular C++ while copying the
| rest verbatim. See this https://godbolt.org/z/nPPMYM3Yj as
| an example how array accesses are transpiled to do bounds
| checking.
| pjmlp wrote:
| For me, it is the only one that deserves "TypeScript for C++"
| nickname, given its evolution approach.
| tantalor wrote:
| It's there another version of this talk with tolerable audio?
| katzdm wrote:
| In fact, there is: https://www.youtube.com/watch?v=x7fxeNqSK2k
| bmacho wrote:
| Audio is better, but now the slides are intolerable.
| pjmlp wrote:
| Oh thanks, I missed that one.
| lifthrasiir wrote:
| Context: https://github.com/seanbaxter/circle/blob/master/new-
| circle/...
|
| Note that Circle is not an F/OSS compiler as someone pointed out
| before. This however doesn't make Circle less relevant, because
| it is actually a testament to show that C++ could have been much
| better without the claimed breakage. If Circle does provide a
| number of desirable features and its compiler can be built by a
| single person, then why shouldn't the committee do the same?
| suby wrote:
| > If Circle does provide a number of desirable features and its
| compiler can be built by a single person, then why shouldn't
| the committee do the same?
|
| Well, there are downsides to taking Circle's approach which I
| think are worthwhile to mention. Languages are preferable to
| everyone creating their own custom DSL. They provide a single
| target that everyone is able to learn, it allows one to work in
| a much larger body of work without friction.
|
| When I pull down a library or codebase, I want to be able to
| immediately hit the ground running instead of having to
| understand every aspect of how the developers have tweaked the
| language to suit their preferences, and how each of these
| tweaks interact with each other. You probably shouldn't rely on
| people making these choices themselves, because you don't want
| everyone being a language designer -- it invites a
| combinatorial explosion with conflicting features that don't
| play nicely with each other. But mostly, it's about maximizing
| one's ability to pull down and work in foreign codebases
| without having to learn a new dialect of a language.
| vanderZwan wrote:
| This isn't quite a DSL approach though: the features are
| turned on and off locally, and don't "escape" from that local
| source. So provided that one knows the features that can be
| turned on or off they can just read the source code top to
| bottom without having to trace which feature was accidentally
| set in a different file.
|
| Also, re:
|
| > _You probably shouldn 't rely on people making these
| choices themselves, because you don't want everyone being a
| language designer_
|
| This would be true for any other language, but with C++ one
| _already_ has to figure out which subset of features to use,
| which is basically the same type of choice as turning Circle
| features on or off.
| pjmlp wrote:
| Because politics, mostly.
|
| ISO processes are a complex beast, you will notice that C++ is
| the exception of having the language author still around, all
| other programming languages under ISO, the authors kind of
| moved on after the first revision.
|
| Note even Plan 9 and Inferno's C, isn't quite ISO C89, with
| Dennis Ritchie hardly taking part in meetings afterwards.
| rewmie wrote:
| > ISO processes are a complex beast, you will notice that C++
| is the exception of having the language author still around,
| all other programming languages under ISO, the authors kind
| of moved on after the first revision.
|
| I don't see your point. What leads you to believe that
| Stroudtrup being involved in C++'s standardization effort is
| any relevant with regards to where the language is going?
|
| Also, if a standardization process is driven by consensus,
| what would be the point of trying to force your personal
| ideas over everyone else's?
| pjmlp wrote:
| On the contrary, many people like to blame him for the
| direction some decisions have been made, while completely
| lacking the understanding that he only has one vote among
| about 300 something.
|
| He has been a kind of C++ consciousness with his books and
| papers, but C++ isn't a language with BDFL.
|
| HP, IBM and Dec made the point the language had to be part
| of ISO for industrial adoption. As most languages back
| then.
|
| Maybe had the language evolved as a foundation with BDFL,
| many of its warts had been sorted out already.
| tialaramex wrote:
| > he only has one vote
|
| I don't think that's a very helpful understanding of the
| situation. Bjarne's influence isn't limited to one of 300
| votes. Some random guy from Microsoft with voting rights
| isn't the same _in practice_. As an example it seemed
| pretty clear to me from evidence viewed now, that ~15
| years ago Bjarne undermined C++ 0x Concepts in favour of
| his own simpler less capable design, which C++ eventually
| got in C++ 20.
|
| Circle has this feature, since Bjarne's C++ 20 feature is
| called concepts, Sean calls this "interfaces" instead,
| but it's the C++ 0x Concepts functionality.
|
| I also don't buy the story that poor Bjarne was strong
| armed into his leading role on WG21 (the C++ language
| committee). Does Brain Kernighan play a similar role at
| WG14 (the C language committee)? No. He's moved on,
| Bjarne has not.
|
| _Are_ people suggesting that a BDFL would be better? I
| see a lot of dissatisfaction with ISO but that 's not the
| same thing. Rust doesn't have a BDFL, and these days
| neither does Python. Maybe neither BDFLs nor ISO
| committees (well, specifically JTC1 sub-sub-committees,
| these are all under JTC1's SC22, a sub-committee for
| programming languages) are a good way to develop
| programming languages.
| FpUser wrote:
| >"Context:
| https://github.com/seanbaxter/circle/blob/master/new-
| circle/..."
|
| "simpler by disabling features ..."
|
| "By construction, the resulting edition is fully compatible
| with existing C++ code."
|
| I do not understand how "disabling features" can be "compatible
| with existing C++ code".
| gavinray wrote:
| You use pragmas to disable/enable features on a file-by-file
| basis.
|
| Since existing code contains no Circle pragmas, it's compiled
| by the Circle compiler as "standard" C++.
|
| I urge you to try it -- there's binaries and Docker
| containers available. Takes two seconds.
| rewmie wrote:
| > You use pragmas to disable/enable features on a file-by-
| file basis.
|
| No, I don't. Some compilers support that, though, namely
| MSVC, but those practices are a huge code smell that are
| heavily discouraged for decades.
| LoganDark wrote:
| > No, I don't.
|
| Wrong "you". They were describing how Circle implements
| C++ compatibility, not how you personally use non-Circle
| compilers.
| rewmie wrote:
| > This however doesn't make Circle less relevant, because it is
| actually a testament to show that C++ could have been much
| better without the claimed breakage.
|
| But it does break backwards compatibility, doesn't it? Meaning,
| if you pass Circle code to a C++ compiler, that's a no-go from
| the start, isn't it?
|
| What aspect are you focusing on to argue that Circle introducss
| no breakage?
| celrod wrote:
| Every new C++ standard introduces new things that will not
| work under an old standard.
|
| Not breaking backwards compatibility means that code for old
| standards should generally still work if recompiled. Not
| breaking ABI means it should still work if not recompiled.
___________________________________________________________________
(page generated 2023-08-16 23:01 UTC)