Live data from Hacker News

A JavaScript parser and interpreter written in Go

github.com

31–40 of 72 posts

Re: A JavaScript parser and interpreter written in Go

#31
post #21

Earlier quoted context omitted.

Thank you for being one of the few gophers that put newlines between standard, third party, and local imports. I wish gofmt forced that standard on people.

It is a useful convention in C and C++ to group includes, but I don't see the benefit in Go. Since gofmt sorts imports, the grouping is soon undone. In any case, it is quite easy to distinguish the three kinds of imports if local imports share a common prefix or set of prefixes. Am I missing something here?

It's possible that if you have packages that understand flags (config package, with flags in init(), for example) that if you include it after the testing package, or before. One of them won't accept flags. (because flag.Parse() has already been called)

Re: A JavaScript parser and interpreter written in Go

#33
post #13

This is the most Hacker News sounding title I've ever heard.

I think the title has been changed. Can you say what the original was?

I could be wrong, but I think they're just poking fun at all the "An X interpreter written in Y" where X and Y are the current trendy languages. Usually one of X or Y are JavaScript or Go, so seeing both in the same headline is like some sort of Hacker News headline jackpot.

Re: A JavaScript parser and interpreter written in Go

#34
post #18

Alright, 90 points, most comments being meta about the title so I'll be the brave one and ask: What is this actually good for? I can't think of any reasonable use case. Grab little NPM ditties and incorporate them into your Go binary - Javascript to Go becomes as Lua is to C? Somebody enlighten me. Edit: Not that this needs a use case per say, just that the intent behind it is underspecified enough for me to wonder a…

Not everything needs a use case. But if you really want one, here's one: I'm a student and I want to write my own interpreter. Well, here's a good example of how to write your interpreter.

That's not a use case.

Re: A JavaScript parser and interpreter written in Go

#36
post #24

Can someone explain to me whats wrong with using V8 in Go? I mean what's the point in building js interpreter in Go, when you already have a better one made.

What's the point of starting anything new, when something like it already exists? Why become a doctor when there are already good doctors? Why write a book when there are already good books? Why sing a song when somebody else already sings it better?

By putting in the context the amount of money and number of one of the best programmers in the world building a V8, building a Go V8 alternative is probable not a best business choice unless you're a huge company with clear goals

Re: A JavaScript parser and interpreter written in Go

#37
post #11

A couple years ago for a programming languages course, we wrote a bytecode compiler and interpreter for a JavaScript-like language we were using in the class (objects, prototype-based inheritance, higher-order functions, etc), and we initially started building it in Go, but the biggest thing that made us switch to C++ at that time was the fact that Go didn't have a straightforward union type. It looks like this inter…

Excuse the silly question, but why was a union type so important?

Re: A JavaScript parser and interpreter written in Go

#38
post #11

A couple years ago for a programming languages course, we wrote a bytecode compiler and interpreter for a JavaScript-like language we were using in the class (objects, prototype-based inheritance, higher-order functions, etc), and we initially started building it in Go, but the biggest thing that made us switch to C++ at that time was the fact that Go didn't have a straightforward union type. It looks like this inter…

Casting to/from empty interfaces is kind of doing the same thing for void* pointers in C, right?

Re: A JavaScript parser and interpreter written in Go

#39
post #21

Earlier quoted context omitted.

Thank you for being one of the few gophers that put newlines between standard, third party, and local imports. I wish gofmt forced that standard on people.

It is a useful convention in C and C++ to group includes, but I don't see the benefit in Go. Since gofmt sorts imports, the grouping is soon undone. In any case, it is quite easy to distinguish the three kinds of imports if local imports share a common prefix or set of prefixes. Am I missing something here?

[deleted]

Re: A JavaScript parser and interpreter written in Go

#40
post #13

Earlier quoted context omitted.

I think the title has been changed. Can you say what the original was?

I could be wrong, but I think they're just poking fun at all the "An X interpreter written in Y" where X and Y are the current trendy languages. Usually one of X or Y are JavaScript or Go, so seeing both in the same headline is like some sort of Hacker News headline jackpot.

The comment was also probably poking fun. Yours too?
Post reply on HN