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

Why Go Rocks for Building a Lua Interpreter

zombiezen.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Why Go Rocks for Building a Lua Interpreter

#51

Post by skybrian »

pjmlp wrote: post #49
skybrian wrote: post #48

Earlier quoted context omitted.

It’s different because Go is garbage collected. See my other reply.

No it is not, that is the anti-GC folks agenda since Xerox PARC days, placing all GC languages into one big basket, not learning what actually makes one specially tick, the language features available for low level coding in each programming language and such. Just sticking to the old ways is why we don't get progress in some industry corners.

I’m not anti-GC. There’s nothing wrong with using a garbage collected language. However, if you use a built-in garbage collector, you do need to play by its rules, or it’s not going to work. These rules are language-specific and limit what you can do efficiently when writing an interpreter, versus writing your own GC that’s purpose-built.

For example, Go’s garbage collector isn’t going to do as well at JavaScript as V8’s garbage collector, because the only unions it understands are Go interfaces. Also, the garbage collectors for other languages mostly don’t support some features of the Go language, such as taking pointers into the middle of objects.

You can still write an interpreter in any language, but there will be an efficiency cost when the languages are too different.

Re: Why Go Rocks for Building a Lua Interpreter

#52

Post by azemetre »

foldr wrote: post #43
azemetre wrote: post #18

Earlier quoted context omitted.

Didn't MSFT also fire the lead engineer for this project shortly after?

Looks like he was laid off, not fired. But so what? Layoffs have their own weird logic. It doesn’t tell us anything about how the project is perceived internally to Microsoft.

No, but it does tell us that MSFT leadership are quite inept if they are firing a clearly qualified engineer capable of doing hard work under the guise of cost savings.

Re: Why Go Rocks for Building a Lua Interpreter

#54

Post by pjmlp »

jekwoooooe wrote: post #53
pjmlp wrote: post #45

Earlier quoted context omitted.

Except for having a modern type system.

What’s missing? It has generics and robust typing. Man this website must be full of old geezers with all the go hate I see

Maybe some Pascal like enumerations, something like this from 1976:

    type
      weekdays = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday);

      DailyActivity = array weekdays of string;
Instead of the ridiculous iota/const workaround.

You mention generics, but actually they still are quite constrained on capabilities.

Robust typing misses out on the famous gotcha with nil interfaces.

The error boilerplate, but granted that isn't a typesystem issue, rather grammar and semantics.

Package names tied to SCM domains, with a workaround using HTML Meta redirections when they change, and behind our back file rewrites remapping imports.

Re: Why Go Rocks for Building a Lua Interpreter

#55

Post by pjmlp »

skybrian wrote: post #51
pjmlp wrote: post #49

Earlier quoted context omitted.

No it is not, that is the anti-GC folks agenda since Xerox PARC days, placing all GC languages into one big basket, not learning what actually makes one specially tick, the language features available for low level coding in each programming language and such. Just sticking to the old ways is why we don't get progress in some industry corners.

I’m not anti-GC. There’s nothing wrong with using a garbage collected language. However, if you use a built-in garbage collector, you do need to play by its rules, or it’s not going to work. These rules are language-specific and limit what you can do efficiently when writing an interpreter, versus writing your own GC that’s purpose-built. For example, Go’s garbage collector isn’t going to do as well at JavaScript as…

I would say it is a matter of implementation, taking the best advantage of unsafe, Assembly, value types and generics.

Not everything has to try to replicate C in language XYZ.

But I do agree, among all languages I would rather reach out for D, C#, any of the MLs or Haskell, Lisp or Scheme variants, instead of Go.

Also if ultimate performance is the goal, then nothing beats handwriten Assembly, so that places both C and GC languages out of the game, as Android has been doing since Android 7, in case there is no PGO data available for the JIT.

Re: Why Go Rocks for Building a Lua Interpreter

#56

Post by mdaniel »

pjmlp wrote: post #54
jekwoooooe wrote: post #53

Earlier quoted context omitted.

What’s missing? It has generics and robust typing. Man this website must be full of old geezers with all the go hate I see

Maybe some Pascal like enumerations, something like this from 1976: type weekdays = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); DailyActivity = array weekdays of string; Instead of the ridiculous iota/const workaround. You mention generics, but actually they still are quite constrained on capabilities. Robust typing misses out on the famous gotcha with nil interfaces. The error boilerplate, but…

> and behind our back file rewrites remapping imports.

I've been bitten/misled by that so many times. How hard is it to just $(find -exec sed) to patch up the imports if you fork a project, versus later finding out oh, so that's why line 50 of some random dep doesn't at all do what it says in the repo

If I was Go Dictator For Life I'd make the compiler issue a warning for any replace statement in go.mod

Re: Why Go Rocks for Building a Lua Interpreter

#57

Post by shadowgovt »

skybrian wrote: post #47
foldr wrote: post #46

Earlier quoted context omitted.

You can do raw memory access via the ‘unsafe’ package, so I don’t think it would be impossible to do NaN boxing in Go. It would be somewhat less convenient than in C.

Unlike C, Go is garbage collected. Hiding pointers from the garbage collector so it can’t trace them without breaking something seems tricky. There would need to be pointers to that memory somewhere else to prevent it from being collected. And then since you’ve disabled the system GC, you need to write your own GC that understands NaN boxing to find out when memory can really be freed. I see it as so awkward that it’…

There are some advantages to constraining our runaway pointers to the part of the language written under the `unsafe` package, as opposed to doing the whole thing in C where we get the advantages of no language preconceptions of garbage collection getting in the way but the disadvantages of forever having to wonder whether we have vulnerabilities in the bog-standard steps like "reading from the input file."

Re: Why Go Rocks for Building a Lua Interpreter

#58

Post by foldr »

azemetre wrote: post #52
foldr wrote: post #43

Earlier quoted context omitted.

Looks like he was laid off, not fired. But so what? Layoffs have their own weird logic. It doesn’t tell us anything about how the project is perceived internally to Microsoft.

No, but it does tell us that MSFT leadership are quite inept if they are firing a clearly qualified engineer capable of doing hard work under the guise of cost savings.

Isn't general MSFT bashing a bit off topic in this thread?

Also, it's discourteous to the individual in question to keep incorrectly stating that they were fired. The distinction between being fired and being laid off is an important one (especially if the person in question is applying for jobs).

Re: Why Go Rocks for Building a Lua Interpreter

#59

Post by kristianp »

pjmlp wrote: post #54
jekwoooooe wrote: post #53

Earlier quoted context omitted.

What’s missing? It has generics and robust typing. Man this website must be full of old geezers with all the go hate I see

Maybe some Pascal like enumerations, something like this from 1976: type weekdays = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); DailyActivity = array weekdays of string; Instead of the ridiculous iota/const workaround. You mention generics, but actually they still are quite constrained on capabilities. Robust typing misses out on the famous gotcha with nil interfaces. The error boilerplate, but…

It does make you wonder about their thought process, not using 'real' enums for go. I think the language designers were of a minimalist mindset, but Pascal wouldn't be described as bloated by anyone with a computer larger than an original Apple II (it required an add-on card to run UCSD Pascal).

Re: Why Go Rocks for Building a Lua Interpreter

#60

Post by azemetre »

foldr wrote: post #58
azemetre wrote: post #52

Earlier quoted context omitted.

No, but it does tell us that MSFT leadership are quite inept if they are firing a clearly qualified engineer capable of doing hard work under the guise of cost savings.

Isn't general MSFT bashing a bit off topic in this thread? Also, it's discourteous to the individual in question to keep incorrectly stating that they were fired. The distinction between being fired and being laid off is an important one (especially if the person in question is applying for jobs).

Fired and layoffs are a distinction that no worker cares about, I'm sure he'd rather be working than getting laid off for "performance reasons."

If you were ever given the option to collect unemployment insurance, this includes taking a severance package where you stipulate to not pursue unemployment insurance, then you were fired.

It's also important to always note that these companies do not care about their workers, they will extract you dry and throw you out.

Post reply on HN