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

131–140 of 188 posts

Re: Solod: Go can be a better C

#131

Post by throwaway894345 »

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

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.

Re: Solod: Go can be a better C

#132

Post by convivialdingo »

loup-vaillant wrote: post #82
pjmlp wrote: post #74

Earlier quoted context omitted.

A better C++ is by definition a better C, no one should be using C in 21st century beyond UNIX clones, and embedded devs that are religiously against C++, even all modern C compilers are written in C++ nowadays. Anything you can think C is better, it isn't ISO C, rather non standard C compiler specific extensions, which can language can also be. Just do like in K&R C days, use Assembly for what language isn't directl…

> 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 of making something interesting.

Re: Solod: Go can be a better C

#133

Post by belmarca »

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…

There is a lot of confusion around those words. I personally make a distinction between a "compiler" and a "transpiler".

A compiler preserves the semantics - if you compile Scheme to C, you get a real Scheme program in C, with full semantics.

A transpiler does not have to guarantee that. It is much easier to transpile Python to JavaScript than it is to truly compile Python to JavaScript. A transpiler can tolerate some amount of leakage between worlds (think 'arguments' as a variable name in Python vs JS).

It really depends on your needs. Sometimes a transpiler is okay, sometimes totally inadequate.

Re: Solod: Go can be a better C

#134

Post by ventana »

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 :)

I think maybe the idea of all these transpilers is to keep the generated code readable and as close to the original code as possible. Mangling names into unreadable garbage is not difficult, but that would also make the the transpiler act more like an obfuscator, which is probably what the authors want to avoid.

Protobuf has similar problem: whatever names you use for your proto messages should be translated to the target language as is, and with multiple target languages, chances are that you'll hit a keyword in one of them; each language plugin should figure out how to resolve this.

  $ cat test.proto
  syntax = "proto3";
  
  package test;
  
  message TestMessage {
    int32 register = 1;
    int32 foo = 2;
  }
  
  $ protoc --cpp_out=. test.proto
  
  $ grep 'register\|foo' test.pb.cc | head -n 2
        : register__{0},
          foo_{0},
(I may understand `register__`, but why `foo_`? no idea)

Re: Solod: Go can be a better C

#135

Post by kfreds »

jamiejquinn wrote: post #57
kfreds wrote: post #50

Earlier quoted context omitted.

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.

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

Lots of reasons. If you can't come up with one then you're not the intended audience, and that's fine.

I made the comment for several reasons. Here's two: (1) I had high confidence that my understanding is correct and wanted to share my knowledge with others. (2) In case my understanding wasn't correct I was hoping someone would correct me, resulting in both me and others learning some interesting nuance.

As for why you in particular should read my comment: Curiosity. There are few traits that are as important to strategic thinking, creativity and success in reaching ones goals as curiosity. When I see something that doesn't map to my understanding of the world my reaction is to wonder whether I'm missing something. It has served me incredibly well so far.

Re: Solod: Go can be a better C

#136

Post by ventana »

bruce343434 wrote: post #121
lou1306 wrote: post #69

Earlier quoted context omitted.

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"

Not only for the conflicts, but mostly to encode the parameter types into the name for method overloading, because the linker has no idea about it.

Re: Solod: Go can be a better C

#137

Post by [deleted] »

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.

[deleted]

Re: Solod: Go can be a better C

#138

Post by kfreds »

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

> It's kind of hilarious isn't it?

It is. I too find my competence profile a bit weird.

I've been interested in security since I was 12 yet never worked full time as a software developer. I have done some coding, but that was over a decade ago, and even then it wasn't very much.

On the other hand I understand the theoretical foundations of formal languages quite well, as well as the engineering required to implement them. I'm comfortable talking about any stage of the compiler pipeline, I can recite the Lambda cube and which logics the interesting corners correspond to, and I'm designing a family of programming languages in my free time.

I understand digital design fairly well too for that matter.

Re: Solod: Go can be a better C

#139

Post by win311fwg »

mpyne wrote: post #119
win311fwg wrote: post #93

Earlier quoted context omitted.

> Transcompile languages have always had tons of issues, and there is a reason why non became popular. While implementations have all died out now in favour of direct compilation, C++ the language was designed to be a transpiled language, and was for many years with C as the target. You can likely find many who agree that it has tons of issues, but unpopular it is not.

Typescript is an even better example. And there are some domain-specific languages that aren't meant to become popular general-purpose languages, but succeed in their niche through the help of transpilation to a general-purpose language.

Typescript isn't nearly as popular as C++ and, aside from a couple of legacy features that don't seem to be commonly used, it can be erased without needing transpilation. What makes it a better example?

Re: Solod: Go can be a better C

#140

Post by sureglymop »

kitd wrote: post #31

The idea of using a subset of an existing popular language is very wise IMHO. We can (and apparently are) debating the merits of the language runtime, but what a subset gives you is immediate access to a large pile of existing tooling that you'd have to write yourself, eg linters, formatters, lsps, etc. Stuff that is purely source-oriented. That hadn't really occurred to me before.

That seems like a smart insight... but, if you're going to use an existing linter it will lint the full existing language and not your subset.

So, if you accidentally code something that is not in the subset but is in the full language, the linter would then happily accept that. Imo there will be similar issues for lsps and formatters also. You're going to probably end up in a situation where you have to fork all of those anyway.

Post reply on HN