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

Criticizing Hare language approach for generic data structures

ayende.com

Post reply on HN
Print view View original

261–270 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#261

Post by eatonphil »

pjmlp wrote: post #250
eatonphil wrote: post #192

Earlier quoted context omitted.

You can't even call a non-Go library without switching to cgo, which contradictorily basically everyone says not to use. Leaving aside the GC, until Go has a real FFI it's hard to to imagine it being a really great fit for systems programming when the systems are all not written in Go.

You can use the same FFI as K&R C, write a couple of Assembly helpers.

Any links to help me understand what you mean about the K&R C FFI? (Not easy to google for)

Possibly related, building against foreign objects and manually setting up the FFI call: https://words.filippo.io/rustgo/.

Re: Criticizing Hare language approach for generic data structures

#262

Post by pjmlp »

eatonphil wrote: post #261
pjmlp wrote: post #250

Earlier quoted context omitted.

You can use the same FFI as K&R C, write a couple of Assembly helpers.

Any links to help me understand what you mean about the K&R C FFI? (Not easy to google for) Possibly related, building against foreign objects and manually setting up the FFI call: https://words.filippo.io/rustgo/ .

Easy, K&R C was rather limited, inline Assembly wasn't yet a common extension, rather you would use the external assembler, and link both object files together.

What was good for C while it was gaining adoption, surely is good enough for Go.

Re: Criticizing Hare language approach for generic data structures

#263

Post by eatonphil »

pjmlp wrote: post #262
eatonphil wrote: post #261

Earlier quoted context omitted.

Any links to help me understand what you mean about the K&R C FFI? (Not easy to google for) Possibly related, building against foreign objects and manually setting up the FFI call: https://words.filippo.io/rustgo/ .

Easy, K&R C was rather limited, inline Assembly wasn't yet a common extension, rather you would use the external assembler, and link both object files together. What was good for C while it was gaining adoption, surely is good enough for Go.

Gotcha, that is along the same lines as the link I shared.

Re: Criticizing Hare language approach for generic data structures

#264

Post by pjmlp »

eatonphil wrote: post #263
pjmlp wrote: post #262

Earlier quoted context omitted.

Easy, K&R C was rather limited, inline Assembly wasn't yet a common extension, rather you would use the external assembler, and link both object files together. What was good for C while it was gaining adoption, surely is good enough for Go.

Gotcha, that is along the same lines as the link I shared.

For example,

https://en.m.wikipedia.org/wiki/Small-C

https://github.com/trcwm/smallc_v1

Re: Criticizing Hare language approach for generic data structures

#265

Post by ncmncm »

wheelerof4te wrote: post #255
ncmncm wrote: post #241

Earlier quoted context omitted.

Yes, a toy: inadequate for professional work. You can cut grass with scissors, but nobody who understands the task will hire you to do it. CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly , 'encapsulate complexity behind a language feature'. A rudimentary feature, true, but one identically the same as is found in modern languages, among their more powerful features.…

"Yes, a toy: inadequate for professional work. You can cut grass with scissors, but nobody who understands the task will hire you to do it." Can you explain what you mean here? In the context of structured programming. "CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'." That's right, CPUs execute instructions. Those…

It is not, in fact, the definition of structured programming.

Structured programming was defined by Edsger Dijkstra, and consisted originally of a model of programming with restrictions on where branches may go. Later programming language constructs if/then/else and while implemented this model. It does not address subroutines.

I describe C and similarly primitive languages as toys because they do not provide the expressive power needed to enable the levels of productivity and reliability demanded of serious work.

Re: Criticizing Hare language approach for generic data structures

#266

Post by avgcorrection »

mariusor wrote: post #191
HL33tibCe7 wrote: post #112

Earlier quoted context omitted.

If the author of Hare didn't want feedback on his language, or didn't want other people to use his language, he shouldn't have advertised it in blog posts and on sites like https://harelang.org/ , which is clearly an advertisement for the language. As it happens, he has. You might think "nobody will use the language", but if nobody pushes back and says why people shouldn't use the language, perhaps people will start…

So what you're saying is basically: "he's asking for it", right?

That counter doesn’t have much force to it when we’re talking about mere argumentation and not violence.

Re: Criticizing Hare language approach for generic data structures

#267

Post by User23 »

pjmlp wrote: post #245
User23 wrote: post #243

Earlier quoted context omitted.

I would say that they evidently felt the need to write a new compiler and runtime, which appears to be a species of agreement with my thesis.

Apparently writing compilers isn't systems programming....

In my prior comments above and in all the following I use "language" in the typical way, which is to say referring to not just the syntax but the semantics of the standard toolchain and runtime as well. I wanted to clarify that since perhaps there is some confusion there. So when I talk about Go I'm talking about what I get here[1] as is everyone else who isn't explicitly specifying some other implementation.

Writing compilers is not systems programming in the sense that it requires a systems programming language, no. One could easily write a C compiler in Ruby, but we don't consider Ruby to be a systems programming language.

Thus, obviously, Go, despite not being a systems programming language, could be used to write the compiler for a systems programming language. I guess that is what Tamago is? I'm not going to read through the source to find out and the web page you linked is boring marketing copy.

[1] https://go.dev/dl/

Re: Criticizing Hare language approach for generic data structures

#268

Post by avgcorrection »

netr0ute wrote: post #159
jolux wrote: post #141

Earlier quoted context omitted.

I’m allowed to have opinions about what tools should be used for what. I think it’s fair to say you shouldn’t write a production HTTP service in assembly, for example.

The problem with this is that you're now the Ministry Of Truth of programming tools.

We all have opinions. The 1984 reference is unhinged.

Re: Criticizing Hare language approach for generic data structures

#270

Post by pjmlp »

User23 wrote: post #267
pjmlp wrote: post #245

Earlier quoted context omitted.

Apparently writing compilers isn't systems programming....

In my prior comments above and in all the following I use "language" in the typical way, which is to say referring to not just the syntax but the semantics of the standard toolchain and runtime as well. I wanted to clarify that since perhaps there is some confusion there. So when I talk about Go I'm talking about what I get here[1] as is everyone else who isn't explicitly specifying some other implementation. Writing…

Go compiler toolchain is written in Go.

TamaGo is a bare metal runtime for unikernels, whose main use is a commercial product for secure USB keys, sold by F-Secure.

Back on my youth, writing compilers was considered systems programming, in parity with kernel drivers, how things change.

I guess writing userspace drivers in hybrid kernels is also not considered systems programming.

Post reply on HN