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

141–150 of 188 posts

Re: Solod: Go can be a better C

#141

Post by win311fwg »

throwaway894345 wrote: post #131
win311fwg wrote: post #101

Earlier quoted context omitted.

> Yeah but they were so that intentionally trying to build a better C++/Java They were trying to build a faster Python, thinking that would appeal to C++ developers. The theory was that developers were using C++ at Google because they had to, not because they wanted to, and would choose something like Python instead if it were up to the performance task. Although it turned out in the end that C++ developers actually…

> Although it turned out in the end that C++ developers actually wanted to use C++. Survivorship bias. You're only looking at the people who remained C++ developers. A bit like a politician bragging that they have 100% approval rating among their supporters even as their supporter count dwindles.

Google kept on building C++ services despite Go being available and fully backed by the company. Developers could have used Go if they wanted to, but they didn't.

There are obviously exceptions. There always are. But the reality is that Go was picked up by the Python crowd instead. Which was noted as being surprising at the time as it was assumed that Python users didn't need another Python. What was hard for the Googlers to fathom was that anyone would use Python in a performance-sensitive area to begin with.

Re: Solod: Go can be a better C

#142

Post by win311fwg »

throwway120385 wrote: post #96

Does it generate the same extremely fat binaries? I've seen Go binaries get into hundreds of megabytes for things you could do with C/C++ with a few megabytes. Most of it seemed to be string tables and other things that could be reduced but not eliminated with compression.

A large part of that depends if we get something equivalent to gc's scheduler or not. Concurrency is still under development. Most likely it will take a simpler approach, like tinygo, which won't require tons and tons of code.

Re: Solod: Go can be a better C

#143

Post by Chu4eeno »

sylware wrote: post #84
ventana wrote: post #43

Translating a language into a different language is a popular thing to do these days, but still not a very easy one. I feel it's like peeling an infinite onion of misery. First, you write a parser of your source language, figure out the translation of the instructions, and emit the code in the target language, and you're very happy when your translated Hello world compiles. Then, a user (like me) tries writing someth…

A good test is to try to port significant from c++ to plain and simple C using "AI". Maybe it can retain some of the semantics for the original code. There is a more brutal option: AI could help write a c++ to plain and simple C transpiler... then we would lose the semantics of the original program, but free ourself from the very few toxic and real-life c++ compilers out there.

> A good test is to try to port significant from c++ to plain and simple C using "AI". Maybe it can retain some of the semantics for the original code.

So updating cfront for modern C++.

Re: Solod: Go can be a better C

#144

Post by nine_k »

Panzerschrek wrote: post #38
nine_k wrote: post #30

Earlier quoted context omitted.

C++ is like PHP: it used to be a terrible language, and you can still reach for everything terrible if you wish. But during last maybe 10 years, C++ made a lot of effort to become a language with fewer footguns and more safe, high-level tools. Still I won't start a new project in C++. If I wanted high-level features and zero-cost abstractions, I'd take Rust. If I wanted working really close to hardware, do bit-twiddl…

> If I wanted working really close to hardware, do bit-twiddling and knowing where every byte is allocated, I'd take Zig Why not C++? It allows as many low-level operations as one wishes, but don't forces you to manage memory manually where it isn't necessary. > If I wanted to write a small piece of code intended to run absolutely everywhere GCC and Clang have support of C++ since many years. Is there any modern plat…

Why not C++: build system(s), stdlib, modularity (though C++20 has modules, who uses them?), presence of UD. Better languages don't carry the unfortunate baggage of 1970s which C++ needs to be compatible with.

Re: Solod: Go can be a better C

#145

Post by odo1242 »

fragmede wrote: post #53
rob74 wrote: post #51

Earlier quoted context omitted.

So much for "Go's safety" in the quote above. Ok, it doesn't explicitly say memory safety, but what other safety could if be referring to?

comparing it with c? thread safety maybe?

The language also does not support goroutines, locks, or channels, except through using the C threading libraries.

(I think the original author meant type safety when they made that statement. Though it still doesn't make all that much sense to me)

Re: Solod: Go can be a better C

#146

Post by nvme0n1p1 »

inigyou wrote: post #122
nvme0n1p1 wrote: post #15

Earlier quoted context omitted.

Yeah that's not great. It's easy to be faster than go if you haven't thought about memory management yet. I bet go with GOGC=off is faster than plain go too.

This is impossible. General words like "faster" are subjective, and useless in a technical context unless you ground the discussion by giving them specific definitions. Otherwise everyone ends up talking past each other.

Whoa, I have my very first crazy internet stalker. What fun!

Do an internet search for "go garbage collector benchmark" if you're curious what the grownups are talking about.

Re: Solod: Go can be a better C

#148

Post by [deleted] »

sylware wrote: post #84
ventana wrote: post #43

Translating a language into a different language is a popular thing to do these days, but still not a very easy one. I feel it's like peeling an infinite onion of misery. First, you write a parser of your source language, figure out the translation of the instructions, and emit the code in the target language, and you're very happy when your translated Hello world compiles. Then, a user (like me) tries writing someth…

A good test is to try to port significant from c++ to plain and simple C using "AI". Maybe it can retain some of the semantics for the original code. There is a more brutal option: AI could help write a c++ to plain and simple C transpiler... then we would lose the semantics of the original program, but free ourself from the very few toxic and real-life c++ compilers out there.

[deleted]

Re: Solod: Go can be a better C

#149

Post by win311fwg »

sylware wrote: post #84
ventana wrote: post #43

Translating a language into a different language is a popular thing to do these days, but still not a very easy one. I feel it's like peeling an infinite onion of misery. First, you write a parser of your source language, figure out the translation of the instructions, and emit the code in the target language, and you're very happy when your translated Hello world compiles. Then, a user (like me) tries writing someth…

A good test is to try to port significant from c++ to plain and simple C using "AI". Maybe it can retain some of the semantics for the original code. There is a more brutal option: AI could help write a c++ to plain and simple C transpiler... then we would lose the semantics of the original program, but free ourself from the very few toxic and real-life c++ compilers out there.

> 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.

Re: Solod: Go can be a better C

#150

Post by [deleted] »

jack_h wrote: post #114
pjmlp wrote: post #107

Earlier quoted context omitted.

Nope, only the anti-GC religion would agree to that. Most of those folks would never manage to replicate something like Xerox Cedar on their own, from 1980 in their beloved 2026 computers. Thankfully we have the likes of Apple and Google, that have a my way or the highway education system for such developers, that want to go through their magical gardens.

There are roughly two orders of magnitude more microcontrollers in the world running code than application processors. GC is not acceptable on a microcontroller due to the extreme resource constraints. The GP post is correct, Go can replace some use cases for C, but it does not replace all use cases and GC is part of the reason.

[deleted]
Post reply on HN