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

121–130 of 188 posts

Re: Solod: Go can be a better C

#121

Post by bruce343434 »

lou1306 wrote: post #69
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…

Oof that's not a good look. You can trivially avoid this by just prefixing all variable names with a salt. By the way this (or a variant thereof) is called "avoiding unwanted name capture" if you want to sound all sophisticated :)

C++ compilers do this too, thats why so many to-be-linked symbols start with "Z"

Re: Solod: Go can be a better C

#122

Post by inigyou »

nvme0n1p1 wrote: post #15
wrs wrote: post #8

Earlier quoted context omitted.

Exactly as well as C does, it seems. func newPerson() *Person { p := Person{Name: "Alice", Age: 30} return &p } becomes static main_Person* newPerson(void) { main_Person p = (main_Person){.Name = so_str("Alice"), .Age = 30}; return &p; } Quoting the FAQ: "So itself has few safeguards other than the default Go type checking. It will panic on out-of-bounds array access, but it won't stop you from returning a dangling p…

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.

Re: Solod: Go can be a better C

#123

Post by benj111 »

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…

Add prefix 'noso_' to user variables.

So even if someone creates 'so_int' it becomes 'noso_so_int'

Re: Solod: Go can be a better C

#124

Post by oddthink »

win311fwg wrote: post #101
owaislone wrote: post #72

Earlier quoted context omitted.

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.

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

Oof, I don't think so. It's just ridiculous how many things Google uses C++ for where something like Go or Java would be a better fit, and everyone I talked to agreed. No one liked C++ for search-like things.

I think they just underestimated how powerful the network effects were. People wanted to use Go, but then it didn't have Flume support forever, so what can you actually do with it? And all the NLP libraries were in C++. And the vector-search library was C++, and graph clustering, and so on. One of the basic data formats was super-clunky for ages as well, but I forget if it was SSTable / RecordIO / Capacitor or what.

Or perhaps the Go creators were just writing very different code in very different domains from what I saw as the bread-and-butter C++/flume data-crunching pipelines of Search and Maps.

Re: Solod: Go can be a better C

#125

Post by benj111 »

leoedin wrote: post #117
jamiejquinn wrote: post #57

Earlier quoted context omitted.

I'm really sorry to be harsh but if you don't use programming languages and have never written a transpiler, why should anyone read your comment? You critique the approach as brittle and yet the approach you propose doesn't solve the thorny problem gp described of a growing ball of reserved keywords.

It's kind of hilarious isn't it? "I don't even write code, yet here is my technical assessment of how a tricky software problem should work".

Are you suggesting Ada Lovelace isn't capable of reasoning about a problem?

You can come up with an algorithm or system without knowing programming. Presumably we can agree the opposite, that being a programmer doesn't give you mystical insight into every programming problem.

Ultimately this isn't even a programming problem.

Timmy writes homework, Jimmy writes homework. They can name the homework however they want. Both go in the same pigeon hole. How can the teacher tell who did which homework?

Re: Solod: Go can be a better C

#126

Post by lioeters »

dzonga wrote: post #92
pjmlp wrote: post #22

Go is a better C already, designed by C authors themselves, with other UNIX key figures. Which while some of the design decisions might be debatable, they actually knew what C is all about, informed by their own experience with what worked in C, Alef and Limbo, across UNIX, Plan 9 and Inferno.

ZIG is already the better C.

I really wish it had more industry buy-in, in terms of funding and community participation. The language has so much to love about it, and even the typical criticisms - some deserved, some not - can be improved or solved over time because it has solid design and foundation. Like most well-built systems, there's a single person (or few people) with coherent vision driving the development, in contrast to C++ and other "design by committee" style projects.

Re: Solod: Go can be a better C

#127

Post by CyberDildonics »

pjmlp wrote: post #107
loup-vaillant wrote: post #77

Earlier quoted context omitted.

> Go is a better C already It’s not. Garbage collection made sure of it. I believe everyone agrees that a "better C" has to have manual memory management. Most even rule out Go as a systems language because of GC. Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it.

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.

Most of those folks would never manage to replicate something like Xerox Cedar on their own, from 1980 in their beloved 2026 computers.

What are you talking about

Re: Solod: Go can be a better C

#128

Post by tocariimaa »

pjmlp wrote: post #106
dzonga wrote: post #92

Earlier quoted context omitted.

ZIG is already the better C.

Zig is what Modula-2 already offered in 1978, Ada in 1983, Object Pascal in 1986, revamped in curly bracket syntax. We need a little more in 2026, besides compile time execution.

Aside from a GC, what other features are "more 2026"? I'm curious.

Re: Solod: Go can be a better C

#129

Post by throwaway894345 »

loup-vaillant wrote: post #77
pjmlp wrote: post #22

Go is a better C already, designed by C authors themselves, with other UNIX key figures. Which while some of the design decisions might be debatable, they actually knew what C is all about, informed by their own experience with what worked in C, Alef and Limbo, across UNIX, Plan 9 and Inferno.

> Go is a better C already It’s not. Garbage collection made sure of it. I believe everyone agrees that a "better C" has to have manual memory management. Most even rule out Go as a systems language because of GC. Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it.

> I believe everyone agrees that a "better C" has to have manual memory management.

This seems completely wrong. Manual memory management is perhaps C's most famous issue. I'm sure _someone_ thinks manual memory management is a feature rather than a bug, but I don't think there's any broad consensus about this at all.

Moreover, Go gives you a lot of levers to control your allocations, and with some care (probably less care than writing correct C code) you can avoid allocating at all (this is how Go's own runtime works).

Re: Solod: Go can be a better C

#130

Post by throwaway894345 »

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.

Go already runs on microcontrollers, but _just like C_, care must be taken to avoid using features that are not compatible with microcontrollers (such as dynamic memory).
Post reply on HN