Hacker News new | past | comments | ask | show | jobs | submit login
GCC now includes Modula-2 and Rust. Do they work on OpenBSD? (briancallahan.net)
196 points by solene 9 months ago | hide | past | favorite | 37 comments

Very cool. Pascal can be compiled with GCC by feeding it through the p2c front end. Obviously this isn't native support, but it's something!


and more here:




Wonder who had enough motivation and time for Modula-2 work.

It was definitely Wirth the effort.

I’m not familiar enough with the GCC stack. I’m curious how much effort was necessary for the M2 front end developer to concentrate on efficiency and optimization in contrast to writing something straightforward and having GCC optimize the intermediate form.

I’m sure both components have some responsibility, just curious how much the intermediate form gives the compiler author “for free”.

Modula-2! Now that’s a name I’ve not heard in a long time. A long time.

Indeed. Used it for one semester in my undergrad CS program.

Ugh; one of our profs had spent some years in Switzerland working on control systems for tunnels or something like that, and made modula-2 mandatory for our data comm course even though students were proficient in C/C++ at this point and preferred it.

This is the first I've heard of Objective-C++ [1]. What kind of masochist would you have to be to pick that?

[1] https://en.wikipedia.org/wiki/Objective-C#Objective-C++

The OS X platform code for Firefox is written in Objective-C++. It's not without issues, but overall it's a nice way to use Objective-C from within a larger C++ code base. I didn't find it difficult to work with, particularly as opposed to what we'd have to do if Objective-C++ didn't exist.

If you want to see what this looks like, look at the .mm files here:


If you want a specific file to look at with good examples of how this works, here's one:


Basically what you're looking for is being able to make Obj-C calls (e.g. [[ChildView alloc] initWithFrame:r geckoChild:this]) from within what is otherwise normal C++, and vice-versa.

Thanks! I remember hearing it existed long ago but I’ve never heard of it being used. Great explanation.

Ahhh, that makes sense. So you can have a cross platform c++ and then bind cocoa. Thanks!

It’s really great when you need to call ObjC APIs from C++ or vice versa.

For the most part you can keep things as regular C++ and then just mix in some ObjC APIs when needed without splitting out your files and targets.

It’s extra useful because macOS provides a lot of really great utility libraries like dealing with media or networking, which means you can greatly reduce your dependency count on Apple platforms.

I try and take the approach of reducing dependencies in favour of platform native APIs where possible when making multi platform code, and this is great for that.

Of course it means you have different details on each platform, but I find it much more pleasant than having to keep building dependencies, and dealing with all the corresponding issues like security, size or dealing with platform specific acceleration.

> I try and take the approach of reducing dependencies in favour of platform native APIs where possible when making multi platform code, and this is great for that.

We need more developers like you!

I did, mostly for Metal-based rendering. It's great if you want to mix Apple's Objective-C APIs with your own C++ code.

Which is a much better solution than using the incomplete C++ bindings released earlier this year.

this? https://developer.apple.com/metal/cpp/

Doesn't it just use objc/runtime.h and if anything is missing you can just add your custom api calls?

That is exactly it, the additional effort to add missing calls, no Metal frameworks integration, it is mostly for basic workloads.

Objective-C is a superset of C, and Objective-C++ extends that to C++. It's really only meant as a shim layer to bridge C++ libraries with Objective-C. Or at least, that was the case in the pre-Swift days.

So much of macOS is built in Objective-C++. Like so fucking much. It's kind of nice actually. Not Rust or Swift nice but kinda nice.

NeXT, as means to bring C++ software into NeXTSTEP.

Objective-C++ was introduced in the early aughts (https://luminaryapps.com/blog/objective-c-a-history/index.ht... says 2002; I remember watching the WWDC video in which it was introduced but I'm having trouble finding it now, sorry).

You're talking to someone that has hold NeXT manuals for an university porting project, and in fact the very first editions of Apple documentation have exactly the very same manual, rebranded for Apple.

And just not to be a random dude in the Internet, here are the NeXT documents straight out of 1993, page 173.


Page 31 on "Developing business applications with OpenStep"


Finally, from the language authors themselves, chapter 15, Objective-C++ (1989-1990)

"The Origins of Objective-C at PPI/Stepstone and Its Evolution at NeXT"


My guess is println! wasn't defined because the std crate isn't supported for the OpenBSD target yet

From looking at the supported platforms, the standard library seems to work for most OpenBSD targets, but they don't provide official builds (presumably due to not having anyone volunteering to maintain dedicated hardware for them to use for CI); the Tier 3 platforms[1] list OpenBSD on x86_64, i686, aarch64, sparc64, powerpc64, and riscv64gc as all having the standard library functioning. Due to there not being official builds, I'm guessing that there would either have to be an officially maintained package to install or you'd have to build it from scratch, though, but it seems likely that having a functioning compiler already means that you wouldn't have to fully bootstrap everything (and if you did, maybe it would be possible to bootstrap from rustc?)

[1]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

I think the simpler answer is that regardless of platform, gccrs can't yet compile core or std libraries, so println! won't work (https://github.com/Rust-GCC/gccrs/issues/1389).

I don't think it's about what tier is supported in rustc, as that's compiled by LLVM in that case.

Ah okay, that makes sense. Sorry for my confusion!

Why add support for a rarely used old language like Modula-2? (I'm not going to call it "mostly dead" though [1]).

[1] https://news.ycombinator.com/item?id=34040397

Because someone wanted to and did the work.

Why add support for a rarely used old language like Modula-2?

I assume someone wanted it, and was willing to put in the effort.

By adding it to upstream GCC, I assume that it incurs some maintenance burden. So I think the more interesting question would be "Why would upstream GCC merge support for Modula-2, and with that accept some work and risk for little reward?".

Stupid question, but doesn't rust have it's own, highly praised compiler? I'm just genuinely curious - would using gcc be better under any practical circumstance? Do they both generate low level code with/for LLVM?

Rust-GCC has an FAQ section that lists the benefits of having a GCC frontend:


I'm in no way a compiler expert, but from what I understood, they specifically want to avoid mixing GCC and LLVM: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

You can also use rustc as a frontend to GCC through rustc_codegen_gcc.


Actually, if they can provide a stable release with the most important nightly features I might pick this over rustc.

The rust team don't seem to understand anything about production software, quality assurance and maintenance. Hopefully competing with a more organised compiler with TLS support that is not crippled will put some pressure on them.

When I was a CS undergrad the first language studied was Modula 2. I still think of it as a great simple language to introduce people to programming.

Seems a nice way to bury a lede :) No links back to GCC including the languages, and a look at https://gcc.gnu.org/ doesn't reveal it either, even if you click on changes for GCC 13.

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact