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

Solod: Go can be a better C

solod.dev

Post reply on HN
Print view View original

181–188 of 188 posts

Re: Solod: Go can be a better C

#181

Post by loup-vaillant »

win311fwg wrote: post #177
throwaway894345 wrote: post #175

Earlier quoted context omitted.

malloc and free are part of the C standard library. I don’t see the point in picking nits between language features you don’t have to use and standard library functions that you don’t have to use.

When you called attention to Rust you clearly understood the point of picking nits. Why pretend you have no idea what we are talking about now? malloc/free, not being a language feature, cannot be reasoned about. Since the larger discussion is about Go, consider using malloc/free in Go. Of course you can do it. There is nothing stopping you. Since it is not part of a language it can be bolted on to any language, not…

> malloc/free, not being a language feature, cannot be reasoned about.

They’re defined in the standard all the same. Of course they can be reasoned with. The defined parts at least. You may argue that the undefined parts cannot, but those are explicitly outside the scope of the C standard, no need to discuss them any further.

Re: Solod: Go can be a better C

#182

Post by pizza234 »

pjmlp wrote: post #70
pizza234 wrote: post #45

Earlier quoted context omitted.

> Go's runtime is written in Go. The whole compiler toolchain, GC, compiler, linker, Assembler, is written in Go. There's some nuance to this. The runtime code uses specific compiler support and restrictions that are not ordinary Go - possible (or even done, like this case) ≠ ergonomic. No doubt of course that for the Go project, this is still a win.

Do you think libc is also written in pure ISO C? I love how language extensions, and subsets are always valid for C and C++, but used as an attack against other languages, as if to prove they are not good enough for a specific use case. Well, neither are C and C++, as they either have to rely on hand written Assembly code, language extensions, or be gutted down into subsets outside the official language standard.

> but used as an attack against other languages, as if to prove they are not good enough for a specific use case.

Ultimately, it comes down to the (subjective, sure) ergonomic limitations of a language. To me, Go without garbage collection and implemented using specific compiler support and significant amount of unsafe operations, does not really represent Go, just as, so to speak, a Rust project containing 90% unsafe code does not really represent Rust. Both are possible of course, and there are even use cases in which they may be desirable in the broader context (ie. the Go runtime).

Therefore, this is not an attack on the language; it is simply an assessment of its ergonomics for particular use cases.

Re: Solod: Go can be a better C

#183

Post by throwaway894345 »

loup-vaillant wrote: post #179
throwaway894345 wrote: post #168

Earlier quoted context omitted.

> As long as it’s crystal clear from the source code, or I have a tool that tells me which line of mine is responsible for the allocation. The tool is the escape analyzer, but I don’t think anyone has made it ergonomic yet.

Then it needs to be made standard. Without that, or an equivalent solution, garbage collected languages will remain unusable in constrained environments.

I'm not sure I agree (or maybe I misunderstand--I assume you're saying "the tool needs to be standard"?), but people use non-standard tools in C all the time. Every build tool or package management solution in C is non-standard. Every memory analyzer or static analysis solution is non-standard.

I think the real impediment isn't related to garbage collection, but it's just ecosystem inertia and industry knowledge inertia--the same forces that inhibit Rust adoption or C++ adoption or Ada adoption. Does that seem reasonable, or am I misunderstanding? What do you think?

Re: Solod: Go can be a better C

#184

Post by loup-vaillant »

throwaway894345 wrote: post #183
loup-vaillant wrote: post #179

Earlier quoted context omitted.

Then it needs to be made standard. Without that, or an equivalent solution, garbage collected languages will remain unusable in constrained environments.

I'm not sure I agree (or maybe I misunderstand--I assume you're saying "the tool needs to be standard"?), but people use non-standard tools in C all the time. Every build tool or package management solution in C is non-standard. Every memory analyzer or static analysis solution is non-standard. I think the real impediment isn't related to garbage collection, but it's just ecosystem inertia and industry knowledge iner…

I mean it needs to be made standard because of how bloody useful that is. More people need to be made aware (industry knowledge inertia), and it needs to be usable pretty much everywhere (ecosystem inertia).

C and C++ start out so unsafe, I can hardly use them on substantial projects without sanitisers now. Sanitisers need to be made standard so I can use them everywhere.

Garbage collected languages start out with unpredictable memory usage, making them unusable on constrained environments without the relevant memory analysers (static or dynamic). Such tools need to be made standard so garbage collection may be an option on more platforms.

Re: Solod: Go can be a better C

#185

Post by derekbsnider »

convivialdingo wrote: post #132
loup-vaillant wrote: post #82

Earlier quoted context omitted.

> A better C++ is by definition a better C The definition is wrong, then. I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in…

I've been toying with a better C... https://github.com/panaflexx/classyc Started with the excellent MIR compiler, and I wrote much of the class/string/json/dict, exceptions and AI made the generics,ownership tracking, and safety checks/traps. Added some go The memory model is mixed, I ended up using arenas for dictionaries and adding a full ownership checking / safety checking compiler stage. It's purely for the joy…

Oh wow, interesting project... I've also been working on a "better c" for a few years, and while it was originally a JIT language (using jitasm), I recently switch to MIR, but since I already had my own lexer/parser/etc stack, I ended up changing it to basically lower everything into a node_t compatible AST tree and handing that off directly to c2mir, bypassing its parser.

Maybe you're interested in collaborating? :)

https://github.com/derekbsnider/madc

Re: Solod: Go can be a better C

#186

Post by derekbsnider »

So this makes me think that a "better" idea is let C be the actual underlying foundation for all of these languages because most languages are written in C (and C++) in the first place, so instead of forcing this strict divide, why not allow for every language to be transpilable into C so that the end result is that you could code in any language you like, because in the end, it can all be compiled with a standard c compiler? This could just be the new rule going forward... want to make a new programming language? Sounds good... so long as it can be transpiled into C code. Doing some weird shady stuff that generates machine code directly? No problem -- put it into a library that can be linked in.

Re: Solod: Go can be a better C

#187

Post by derekbsnider »

sylware wrote: post #162
win311fwg wrote: post #149

Earlier quoted context omitted.

> but free ourself from the very few toxic and real-life c++ compilers out there. Funny because the canonical C++ compiler for the first decade of the language's life did compile to C. People eventually moved on to other compilers to free themselves from having to deal with the toxicity of C output. What's old is new again.

You are an odd one: we all know that c++ syntax complexity is beyond salvation : it has reach such an absurd and grotesque level, we are in mental pathology realm: Rube Goldberg Machine accute syndrome. And it is not even a matter of argumentation, unless being of accutely bad faith. It seems you are failing to see that this is this very syntax complexity which makes most of this toxicity. And having a modern c++ tra…

I'm actually working on one... well, it's a lot more than a C++ to C transpiler, but it's just one of the features it contains. It's actually a C/C++ derived language which currently aims to fully support C23 and C++17 in addition to its own extensions which bring in features from other languages like PHP, Rust, Python, Perl, Ruby, JS, etc, as well as auto-including headers, and auto-resolving namespaces. It can JIT execute and also generate executables, as well as emit standard C code you can compile with GCC or CLANG.

https://github.com/derekbsnider/madc

Re: Solod: Go can be a better C

#188

Post by convivialdingo »

derekbsnider wrote: post #185
convivialdingo wrote: post #132

Earlier quoted context omitted.

I've been toying with a better C... https://github.com/panaflexx/classyc Started with the excellent MIR compiler, and I wrote much of the class/string/json/dict, exceptions and AI made the generics,ownership tracking, and safety checks/traps. Added some go The memory model is mixed, I ended up using arenas for dictionaries and adding a full ownership checking / safety checking compiler stage. It's purely for the joy…

Oh wow, interesting project... I've also been working on a "better c" for a few years, and while it was originally a JIT language (using jitasm), I recently switch to MIR, but since I already had my own lexer/parser/etc stack, I ended up changing it to basically lower everything into a node_t compatible AST tree and handing that off directly to c2mir, bypassing its parser. Maybe you're interested in collaborating? :)…

That's incredible! I see you ran into many of the same MIR issues and limitations I did. I pulled several fork patches and wrote a thread local stack extension.

I'll definitely check it out and see what I could do. I added two compiler stages - a decent memory ptr ownership tracker and midopt compiler optimizer you could likely use without many changes that improved performance 35% over c2mir.

Post reply on HN