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

51–60 of 188 posts

Re: Solod: Go can be a better C

#51

Post by rob74 »

odo1242 wrote: post #35
gnull wrote: post #23

> So is for Go developers who want systems-level control without learning a new language. And for C programmers who like Go's safety, structure, and tooling. Wut? Also, how do you preserve garbage collector semantics without garbage collector?

The answer is apparently "you don't": - Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things - The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation) - Interfaces (the only variable size struct Go has) ar…

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?

Re: Solod: Go can be a better C

#52

Post by [deleted] »

rob74 wrote: post #51
odo1242 wrote: post #35

Earlier quoted context omitted.

The answer is apparently "you don't": - Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things - The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation) - Interfaces (the only variable size struct Go has) ar…

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?

[deleted]

Re: Solod: Go can be a better C

#53

Post by fragmede »

rob74 wrote: post #51
odo1242 wrote: post #35

Earlier quoted context omitted.

The answer is apparently "you don't": - Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things - The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation) - Interfaces (the only variable size struct Go has) ar…

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?

Re: Solod: Go can be a better C

#54

Post by z0ltan »

RossBencina wrote: post #39

The "a better C" meme needs to die. It's ill defined. Everyone wants something different. For me, GC disqualifies any language as a better C. Bjarne Stroustrup promoted C++ as a better C. But C++ killed off some of C's killer low-level features like type-punning via unions. Indeed it's only in recent years that low-level memory manipulation, such as std::start_lifetime_as and the implicit lifetime rules were standard…

[dead]

Re: Solod: Go can be a better C

#55

Post by arnsholt »

RossBencina wrote: post #39

The "a better C" meme needs to die. It's ill defined. Everyone wants something different. For me, GC disqualifies any language as a better C. Bjarne Stroustrup promoted C++ as a better C. But C++ killed off some of C's killer low-level features like type-punning via unions. Indeed it's only in recent years that low-level memory manipulation, such as std::start_lifetime_as and the implicit lifetime rules were standard…

John Regehr tried to start an initiative to make what he called Friendly C, removing some of the most blatant C footguns, and even that turned out to be extremely hard to get consensus on: https://blog.regehr.org/archives/1287

Re: Solod: Go can be a better C

#56

Post by ventana »

kfreds wrote: post #50
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…

That seems like a brittle approach to transpilation. A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language. Also, there is so much more to a language than its surface syntax. I've never designed a transpiler (I'm not a programmer), but surely the correct approach is to transform the source code into its ty…

> A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language.

Yes, it should; but it also makes things much more difficult. This specific transpiler indeed builds an AST, but does not care about identifiers, just emitting them as is [1] (I hope I found the correct place in the code).

[1]: https://github.com/solod-dev/solod/blob/8485bc867ae0f0269d75...

Re: Solod: Go can be a better C

#57

Post by jamiejquinn »

kfreds wrote: post #50
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…

That seems like a brittle approach to transpilation. A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language. Also, there is so much more to a language than its surface syntax. I've never designed a transpiler (I'm not a programmer), but surely the correct approach is to transform the source code into its ty…

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.

Re: Solod: Go can be a better C

#58

Post by cjs_ac »

RossBencina wrote: post #39

The "a better C" meme needs to die. It's ill defined. Everyone wants something different. For me, GC disqualifies any language as a better C. Bjarne Stroustrup promoted C++ as a better C. But C++ killed off some of C's killer low-level features like type-punning via unions. Indeed it's only in recent years that low-level memory manipulation, such as std::start_lifetime_as and the implicit lifetime rules were standard…

Everyone agrees C has problems, but there’s no consensus on what those problems are. People build ‘better Cs’ to solve the problems they see in the language, and offer them to the community for the benefit of those who share their tastes.

It’s perfectly fine for you to disagree with them, but it’s also perfectly fine for them to publish their solutions to their problems.

‘A better C’ is a good description for these projects. ‘The better C’ would not be.

Re: Solod: Go can be a better C

#59

Post by aw1621107 »

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…

> The next bad thing is when you step on your own toes and see that the new names you invented, like `so_int` or `so_println`, will inevitably pollute the global namespace. We'll either cross our fingers and hope that no one will create a variable named `so_int`, or we'll need to add all our new kind-of-reserved words to our already big list of exceptions.

To be fair, it's not like it's a completely foreign concept; consider C's categories of reserved identifiers (e.g., no double underscores or underscore followed by a capital letter) as well as the identifier ugilification that needs to be done in the C/C++ stdlibs to avoid collisions with user code.

In that vein, the transpiler could pick some prefix which users are highly unlikely to use and document that said prefix is off limits (e.g., "You can't use identifiers starting with `_solod_id_`") or maybe it could use C's reserved IDs (idk if such a transpiler would count as an "implementation" as far as the C standard is concerned).

Re: Solod: Go can be a better C

#60

Post by aw1621107 »

nixon_why69 wrote: post #42
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…

That's undefined behavior in C I thought? You're addressing the memory of a stack frame that already collapsed when it returned. I think it's ok for compilers to either segfault or work like you'd think they would for that example in C. You can pass pointers to earlier frames in the stack, they're still active, but you can't return a pointer to an expired stack frame.

I think you're basically agreeing with the person you're replying to; they're pointing out that Solod doesn't really provide the "safety of Go" since the translation trivially exposes the user to UB that would not be present in Go.
Post reply on HN