Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are We Modules Yet?

arewemodulesyet.org

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Are We Modules Yet?

#81

Post by isopede »

dlivingston wrote: post #65
isopede wrote: post #32

Earlier quoted context omitted.

C++ has long surpassed the point where mere mortals like me can understand it; It's so loaded with baggage, footguns, and inscrutable standards language that honestly I think the only thing keeping it going is institutional inertia and "backwards compatbility" (air quotes). I work extensively in the embedded space and unfortunately C and C++ are still pretty much the only viable languages. I can not wait until the da…

What's stopping Rust from being used in embedded?

Among other things, tooling and vendor libraries. Vendor libraries are often composed of thousands upon thousands of lines of auto-generated C headers and written in some bespoke format. Demonstration code and/or sample drivers are almost invariably provided in C. Of course you _can_ rewrite these in Rust, but if you're an engineer trying to get shit working, you'd first basically have to reinvent the whole wheel just to do bringup.

I don't even want to talk about the state of proprietary vendor tooling...

Re: Are We Modules Yet?

#83

Post by no_way »

neilv wrote: post #22

Who all are doing the `arewe yet` Web sites, other than Rust and this C++ one?

There quite a few in javascript/browser world: - Browser Houdini effort https://ishoudinireadyyet.com/ - Service workers https://jakearchibald.github.io/isserviceworkerready/ - Svelte 5 new version https://svelte-5-preview.vercel.app/status - Turbo bundler rust rewrite https://areweturboyet.com/

And prob much more

Re: Are We Modules Yet?

#85

Post by 10000truths »

t43562 wrote: post #35

After writing build systems for a C/C++ operating system and years optimising builds for C/C++ operating systems the major disaster by far is the C preprocessor. This is the source of all the evil. Even a hello world program involves reading through 100s of kilobytes, often megabytes, of headers that have to be parsed again and again for every source file but which can produce totally different outcomes in each case…

C/C++ sucks to write dev tooling (e.g. syntax highlighting, LSPs, static analyzers) for. Pretty much everyone leans on libclang for parsing because very few people are insane enough to try to reimplement a parser themselves, let alone all the GNU extensions. And even then, macros make robust parsing really difficult. Imagine trying to parse a file that contains two programming languages that can be arbitrarily interleaved at almost the character level. That's basically what C/C++ are.

Re: Are We Modules Yet?

#86

Post by izacus »

Longhanks wrote: post #73
hot_gril wrote: post #62

Earlier quoted context omitted.

It's called putting all your code in the .h

Which is going to murder your compilation times. Modules do it better, the MS Office team claims the following: Worst case: 0.9% regression compared to PCH - Best case: 21.2% improvement compared to PCH (From https://m.youtube.com/live/H6GQUg5JquU?si=1iC_OvRQ_MprzDTQ&t... )

And what are the metrics in comparison to not using PCH?

Re: Are We Modules Yet?

#87

Post by Maxatar »

stonemetal12 wrote: post #71
schaefer wrote: post #34

I've been working professionally with c++ since 2001, and I'm currently a team lead. The compensation packages we are able to offer to new hires means we're generally hiring from the middle of the talent pool, not the upper tier. The complexity of c++ has long since outpaced the pace of fluency of the hiring pool. In my experience, the average c++ professional (that applies for our open job ads) knows c++14, and migh…

Why not use them as soon as the compiler supports them? Your teammates will either ask you what it is (since you are the team lead), or look it up on cppreference.com.

I used to do this back when C++11 came out and ended up regretting it. When a feature just comes out, you can understand it possibly in isolation, but it's very hard to understand how that feature will fit in with other features, tools, libraries etc... and so you use it in a certain way according to how various blog posts and thought leaders say you should use it, and then after a year you end up realizing that no one could anticipate that the new feature has all kinds of footguns and certain features even end up being deprecated or superseded by yet another new feature.

When a new feature comes out, it's best to let it settle in a bit, maybe experiment using it on smaller side projects, but avoid diving into using it too early before it's really well understood.

For example I now cringe every time I see the curly bracket initialization of the form T{...} and how that was advocated as the one true way to initialize everything in C++, only for everyone to realize a year later that it has its own footguns (like with initialize lists) and with C++20 fixing almost all of the original problems that led to T{...}, the best practice nowadays is to go back to just using plain old T(...) and there's little to no reason to use T{...} anymore.

There was also Herb Sutter's Always Use Auto, which then was revised to Almost Always Use Auto, and now I think most developers take the sensible approach of use auto for redundant names like iterators, or unnamable types like lambda expressions, and avoid using it everywhere so as to turn your codebase into an opaque soup of inscrutable keywords.

Re: Are We Modules Yet?

#88

Post by kevindamm »

schaefer wrote: post #34

I've been working professionally with c++ since 2001, and I'm currently a team lead. The compensation packages we are able to offer to new hires means we're generally hiring from the middle of the talent pool, not the upper tier. The complexity of c++ has long since outpaced the pace of fluency of the hiring pool. In my experience, the average c++ professional (that applies for our open job ads) knows c++14, and migh…

re: changes coming from generative AI, it would need fluency in modules and other modern formulae. It would get that by being trained on modern conventions. So it's the same problem then, isn't it?

Re: Are We Modules Yet?

#89

Post by bombcar »

Longhanks wrote: post #55
bombcar wrote: post #53

Earlier quoted context omitted.

In every major project I've been involved in (and it's not terribly many, to be fair) things keeping us on previous versions were almost always libraries or other support software, rarely if ever was it the devs.

Really? For me, it has been almost exclusively management not wanting to invest the manpower necessary for the adoption. If the technology stack allows it, I assume most passionate developers would develop rather with newer than older toolchains.

These might be two sides of the same coin - usually the reason there is a huge manpower requirement is because of the libraries and supporting tools.

Most developers want to use the newest and greatest, but are held back.

Re: Are We Modules Yet?

#90

Post by ctxc »

paulddraper wrote: post #49
fuomag9 wrote: post #15

Earlier quoted context omitted.

Agreed, I’m not a C++ developer and I’ve barely guessed what’s this about

> I’m not a C++ developer and I’ve barely guessed what’s this about I feel those statements are related.

But concepts are easily transferable, so a line or two could help a lot :)
Post reply on HN