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

Cooperative C++ Evolution – Toward a TypeScript for C++

herbsutter.com

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#201

Post by kangalioo »

mgaunard wrote: post #84
bigfudge wrote: post #48

Earlier quoted context omitted.

I’m not sure how people are supposed to do that in the browser. This feels like an excessively dismissive comment.

Have you not heard of WebAssembly?

WebAssembly is not without tradeoffs either. I'm not an expert, but it's often heavier due to bundling the native language's stdlib; it's annoying to interop with the browser environment because that's still JavaScript-tailored; it's also just hard to write code that can be compiled into WASM (e.g. in Rust, it needs to be `#[no_std]`)

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#202

Post by tialaramex »

pjmlp wrote: post #196
tialaramex wrote: post #190

Earlier quoted context omitted.

This is differently bad because it may mean tight loops are enormously slower under debug for no good reason, it's an adverse consequence of the C++ "wrong defaults" problem. Because they're defaults, we can't detect whether they're what was specifically needed or just nobody cared, so we guess nobody cared and act accordingly.

It isn't as if Rust is any different in this regard.

I'd argue exactly the contrary. In Rust you went out of your way to write the unsafe thing because that's specifically what you intended. As a result there's no need to try to guess whether this code doesn't care, if it didn't care it would be checked because that's the default.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#203

Post by tialaramex »

jandrewrogers wrote: post #193
tialaramex wrote: post #189

Earlier quoted context omitted.

> C++20 is remarkably safe and concise if you take full advantage of the type system. Against what sort of laughably low bar are you measuring to make C++ "remarkably" safe ? This is a language which delights in deliberately adding more footguns, on the rationale that well, it's less safe so surely it'll be faster right? No need to measure, no need to investigate what actual performance optimisations might somehow be…

You can replace almost everything in C++ with stricter implementations of your own design if you don't like the behaviors or guarantees of the standard/default implementation. Many people do because the language is very amenable to it and the codegen is usually optimal. Living entirely within the standard library and the constraints it imposes to support backward compatibility is a choice, not a requirement. The stan…

The "Eh, we'll just throw it away and build a new one" attitude in C++ is part of how you got into this mess. Slices are a vocabulary type, without one what can you do? Well of course you just pass raw pointers around. Huh I wonder why we're having so many safety problems in C++...

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#204

Post by jonex »

chandlerc1024 wrote: post #181
nemetroid wrote: post #175

Earlier quoted context omitted.

Sure, there might be other interop stories that are a better fit, and Dart is a pretty unflattering comparison (perhaps chosen intentionally). But within Herb's dichotomy, I think Carbon falls into the "Dart" category, since the "Typescript" category is rather narrow.

If you're going to create a dichotomy between two languages, I think we're dramatically closer to TypeScript. The whole point of Carbon is to integrate into and re-use an existing ecosystem of software written in C++. It's as far from the Dart approach as it can get without literally being a TypeScript style approach. Ultimately, this dichotomy doesn't help discuss Carbon. I think it is useful for looking at Rust (un…

The dichotomy is relevant if you are of the opinion that some of the foundational design choices of Carbon makes it less viable as a C++ successor based on the similarity of those choices to other projects that were struggling due to this. The talk is arguing for the validity of the construct with various examples, not just Dart.

The construct can be useful without being the end-all answer to what should be done and I would definitely advice you to watch the full talk if you haven't yet. And the consider how each point may apply or not apply to Carbon. Don't just dismiss it on the notion that Carbon is different from Dart.

Actually, I'd encourage you to reach out to Herb Sutter and ideally meet up in person to discuss the matter. Your goals are aligned in many ways and while you have different approaches a lot of good can come out of sharing ideas.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#205

Post by mgaunard »

kangalioo wrote: post #201
mgaunard wrote: post #84

Earlier quoted context omitted.

Have you not heard of WebAssembly?

WebAssembly is not without tradeoffs either. I'm not an expert, but it's often heavier due to bundling the native language's stdlib; it's annoying to interop with the browser environment because that's still JavaScript-tailored; it's also just hard to write code that can be compiled into WASM (e.g. in Rust, it needs to be `#[no_std]`)

If you're doing real work, you don't interact with the browser.

If you're just glueing things together between APIs, then JavaScript is fine, and static typing would just get in the way.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#206

Post by ravenstine »

mgaunard wrote: post #20
zukzuk wrote: post #9

Earlier quoted context omitted.

Typescript has a lot of momentum on all fronts and is almost certainly the future of Javascript. The big problem is that it still requires transpilation, which can set up all sorts of shitty traps. Not to mention that the Javascript ecosystem in general is a horrendous mess, which Typescript on its own can’t fix.

The future of JavaScript is in the past. Get rid of all the stupid transpilers and frameworks and just use plain JavaScript in the browser.

With possibly the exception of Typescript, I agree. Practically all the tools commonly being thrown at JavaScript today are destroying the developer experience and causing more problems that begat even more tools. It's easier than ever to use plain JavaScript in ways that use proper scoping, but so many developers today speak as if this is impossible ("it just doesn't scale bruh"). That's how you know you're talking to someone who didn't write software before ~2011. It's fine if someone prefers to use said tools, but the idea that more tools are are necessary is an example of poor engineering.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#207

Post by deterministic »

IshKebab wrote: post #168
seabird wrote: post #152

Herb is infinitely more qualified to speak on the matter than I am, but I don't think I understand the point. We've had multiple decades to bring C++ under control for safe general purpose usage and it's still very loosey-goosey, to the point where people are rightly afraid to start work in it not because it's a bad or deficient language, but because keeping codebases sane is challenging and requires a lot of discipl…

I don't think it's really any more difficult to build sane C++ codebases than any other language. The issue is not sanity; it's safety. It's extraordinarily difficult to build a significant C++ codebase without segfaults and UB. You end up wasting a huge amount of time debugging that stuff. Any time I've lost fighting Rust's borrow checker has easily been paid off by not having to debug segfaults.

Not my experience at all. I work on very large C++ code bases and haven’t had a bug in production for more than 5 years. The trick is solid tests and using tools like Valgrind/Helgrind to remove all memory issues.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#208

Post by cylemons »

deterministic wrote: post #207
IshKebab wrote: post #168

Earlier quoted context omitted.

I don't think it's really any more difficult to build sane C++ codebases than any other language. The issue is not sanity; it's safety. It's extraordinarily difficult to build a significant C++ codebase without segfaults and UB. You end up wasting a huge amount of time debugging that stuff. Any time I've lost fighting Rust's borrow checker has easily been paid off by not having to debug segfaults.

Not my experience at all. I work on very large C++ code bases and haven’t had a bug in production for more than 5 years. The trick is solid tests and using tools like Valgrind/Helgrind to remove all memory issues.

It also depends on what kind of application you're developing and the resource usage patterns.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#209

Post by deterministic »

cylemons wrote: post #208
deterministic wrote: post #207

Earlier quoted context omitted.

Not my experience at all. I work on very large C++ code bases and haven’t had a bug in production for more than 5 years. The trick is solid tests and using tools like Valgrind/Helgrind to remove all memory issues.

It also depends on what kind of application you're developing and the resource usage patterns.

Not at all. Tests + Valgrind/Helgrind (and similar tools) can cope with pretty much anything.
Post reply on HN