9 ms·
The first new build of Circle, a new C++20 compiler, since April 2022 is online
- homarp 4y agoprevious discussion: https://news.ycombinator.com/item?id=23086227 https://news.ycombinator.com/item?id=23086227
- rogerclark 4y agoTruly an amazing project. One person implementing the entire C++ standard, and then countless new, useful features on top of it. Circle did the interpreted, compile-time pass idea before any of the other new systems languages. Carbon and C++Next both seem very directly "inspired" by Circle, but neither of those efforts seem to have actually produced anything yet. Ideally, Circle it would be open source. But I understand wanting to hold out for some amount of corporate sponsorship first.
- anonymoushn 4y ago> Circle did the interpreted, compile-time pass idea before any of the other new systems languages. constexpr is in C++11, Jai is from 2014, and Zig 0.1.1 is from 2017. This project looks quite cool though.
- pjmlp 4y agoWith the small difference that Circle can use the complete language at compile time, constexpr is still far from it, and also gave birth to constinit and consteval.
- tialaramex 4y agoJai gets to use the entire language. constexpr in C++ 11 is indeed very limited, arguably even more than Rust's const functions today.
- pjmlp 4y agoExcept that almost no one has access to Jai.
- tialaramex 4y agoSure, I'm not commending Jai in general, but it's a clear existence proof on this particular matter.
- pjmlp 4y agoWell, Lisp and Dylan also did it first.
- vadiml 4y agoI think the first take on the subject was IBM with their PL/I Checkout and Optimizing compilers. They've integrated almost full PL/I language interpreter in the macro pre-processor stage. I was using it in the beginning of 80ies.
- WalterBright 4y agoD has had compile time function execution since 2007 or so.
- reisse 4y ago> One person implementing the entire C++ standard, and then countless new, useful features on top of it. Isn't it done on top of LLVM/Clang++?
- Kranar 4y agoLLVM? Yes. Clang? No. The front-end compiler and standard library are written from scratch, but it uses LLVM as the backend. The standard library is not yet complete, but it's amazing how it uses Circle's unique features to implement in a very elegant and efficient manner certain classes like variant and tuple which are absolute monstrosities of complexity in clang/g++/MSVC.
- carabiner 4y agoHe seems like a wonderboy. His linkedin has a recommendation: "Cannot say enough good things about this guy--probably the most capable programmer I've ever met."
- hobo_mark 4y agoAbsolutely, also Sean made enough money in his previous life to be able to work on Circle full-time (while living in NYC), truly living the dream.
- fidgewidge 4y ago100x programmer.
- GPMueller 4y agoDon’t forget about cpp2/cppfront — Herb Sutter has been in direct contact with Sean and it seems their discussions have had some impact on both their projects. cpp2 is currently my favorite contender in this arena
- pjmlp 4y agoFrom all possible wannabe be replacements for C++ that poped up in 2022, Circle is definitely the one that has the most going for it. Everything else requires rewriting everything, and they can only support a limited subset of C++ features, so if the goal is full compatibility with existing code they aren't going to achieve it anyway. For full rewrites, we already have enough alternatives with more maturity years behind them.
- erik_seaberg 4y agoThis lays groundwork for opt-in safety per file, but safety should affect API design. Once you get done doing this to every file and refactoring every public API, have you really spent less effort than would have gone into a rewrite? If you only get halfway there, is the new version going to blow up any less often?
- pjmlp 4y agoDepends if the goal is to improve the safety of existing C++ code, or fully rewrite into something else. Until the likes of LLVM, GCC, CUDA, V8 and co get rewritten into something else, improving existing C++ codebases is still an issue.
- fidgewidge 4y agoKotlin managed it in some cases with clever forwards compatible type system tricks, so it's not impossible
- pjmlp 4y agoExcept it does so by compiling into the same bytecode as Java, javap will just output Java like code from class files, and some stuff like co-routines cannot be called from existing Java code without wrappers that setup the runtime semantics as expected by Kotlin libraries.
- fidgewidge 4y agoYes, but so? When they can implement a feature in a forwards compatible way they do, when they can't, they don't and it's caveated as such. That's why nullable types and other Kotlin specific type stuff are encoded using annotations. It's the same strategy here. Carbon is (was?) also intended to compile to the C++ ABI and so does Circle, that's why it says it doesn't run on Windows (commercially a huge error. many of the biggest C++ codebases that could benefit are running on Windows like game engines, and Windows doesn't impose a specific C++ ABI anyway). But there's no way to take existing code files and switch them to the new language in Carbon, at least not yet. Kotlin was carefully designed at every step of the way such that every Java program can be expressed in Kotlin without change, even if that meant compromising on some things. Seems like the Carbon guys are being sucked up by the lure of safetyism and just want to make their own version of Rust that happens to compile to the Itanium C++ ABI.
- fidgewidge 4y agoYes yes yes. Everything about this document screams good sense and logic. It's clear why Carbon looks the way it does - they want to do what Kotlin did for Java and using the same strategy. But, it won't work. They understood Kotlin's strategy as binary compatibility at the per source file level but that's only half the story. The quiet monster of Kotlin's success is j2k which is a source translation tool built into the IDE. It rewrites a Java file to Kotlin and then applies all the intelligence in the ide plug-in to clean up the results, meaning even idioms get translated properly. Jetbrains could do that because they were developing the IDE plug-in alongside the compiler from day one, and because Java is quite easy to parse, and because Kotlin deliberately constrained itself to Java semantics even when sub optimal. I had high hopes for Carbon when I first heard about it but that number of proposals without even having a compiler is crazy. How do you port existing code? You can only use it for newly added code, presumably, and only if your new code doesn't interact with any c++ using the bits the carbon team don't like? That's light years from the type of interop that made Kotlin a success. Sounds like this guy actually understands the problem in depth. I hope he's able to attract customers, though it's a tough sell to make your company codebase depends on a language maintained by only one guy.
- charcircuit 4y ago>simpler by disabling features that contribute to complexity, like multiple inheritance and function overloading. Seeing function overloading show up surprises me. The only thing I can think of is having different semantics between different overloads, but removing overloads doesn't remove the issue. You just now have a poorly named function that isn't an overload.
- tialaramex 4y agoIf what you meant was actually a polymorphic function, just write the polymorphic function. If that's not what you meant then stop using the same name. I think the contrast between string contains in Rust and C++ is illustrative. Overloading means you only get whatever parameter types the stdlib provides in C++.
- int_19h 4y agoFunction overloading is orthogonal to the ability to define additional methods on existing types. C# has both, for example. Overloading is a don't-repeat-yourself thing - if you have a bunch of functions that do fundamentally the same thing with different types, encoding those types in the function name when they're already explicit in the arguments is simply redundant. Then there's an issue with ABI stability. Adding a new function argument breaks any existing compiled code even if there is a default value, but adding a new overload and redirecting the old one to call the new one with the defaults is fine.
- tialaramex 4y ago> if you have a bunch of functions that do fundamentally the same thing with different types That's where you should use parametric polymorphism, that's my point. C++ 23 defines _3_ overloads of string.contains() with parameter defined as variously a char, a char * and a string view, enabling name.contains("Jim") name.contains("Steve"sv) and name.contains('Q'). But if you need a fourth, too bad. Rust doesn't have overloading, so it defines string.contains() as polymorphic over the parameter type Pattern, which enables name.contains("Jim") name.contains('J') name.contains(char::is_uppercase) name.contains(['B', 'o', 'b']) name.contains(|c| { my_fun(c, 206, local_var) }) and so on and so forth. One reason C++ doesn't do this is addressed in Circle, by offering "interfaces" which are approximately equivalent to Rust's traits or the C++ 0x Concepts (as Sean firmly points out, these were very different than Stroustrup's C++ 20 Concepts) The problem is, what does 'Q' have in common with "Jim" ? In conventional C++ polymorphism we want a base class and of course these are basic types, they don't have a base class, much less one which has the necessary commonality. With interfaces, we can say what we care about isn't some hypothetical "base class" of string_view and char, but instead a common interface they both have dedicated to string matching, and now we're writing polymorphic software again.
- skywal_l 4y agoNow, solve package management and I'll be ready to be back on board the C++ train!
- Yoric 4y agoOne impossible task at a time :)
- VadimPR 4y agovcpkg and conan are gaining momentum. vcpkg was just integrated into CLion!
- batty_alex 4y agoI usually hate Microsoft tools but, vcpkg works really well. Easy enough to use from a couple of build systems, too Can't comment on Conan but, I hear it's nice
- FpUser 4y agoFirst the acknowledgement: to produce this amount of work single handedly - the guy is undisputed genius. do not want to go through the whole article but have this question: fn ParseAsInt() The goal for this new languages like Rust, Carbon, Go etc. is to introduce "better" alternatives to C and C++ languages and move the developers over. Nothing is wrong with that. Now to syntax: I completely understand syntax constructs that actually add value and deal with new / changed concepts like memory management, concurrency safety etc. However what is the point of changing already established syntax just for the fuck of it. What is fucking wrong with int X(). Why change something that does not need changing and increase the impedance of getting into new language?
- gpderetta 4y agoI think the author is simply showing that Circle can implement Carbon syntax using its metaprogramming capabilities on top of C++. It is not making a statement that the syntax itself is desirable.
- seanbax 4y agoThat's right. I'm fine with normal C++ syntax. But other people have other opinions. And there is an allure of getting to a CFG so that non-compiler tooling could build a parse tree and do useful transformations. That's a good a goal. I'm basically looking to evolve on multiple fronts at once. If there's an interest in new syntax, put resources. If there's interest in a borrow checker (I'm sure there is), put resources there. Just move up the field however you can.
- tdiff 4y agoGuess it simplifies parsing, e.g. infamous "most vexing parse" etc.
- FpUser 4y agoConvenience should be for users of a tool not creator. And if it is fn than why not function instead. This single / double character constructs / modifiers in my opinion reduce readability. When reading Rust code apostrophe modifier for example is hard to see.