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

Incremental Parsing in Go

dev-nonsense.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Incremental Parsing in Go

#71

Post by bbkane »

diffxx wrote: post #43

> The parsers produce a sequence to tokens, not a full syntax tree. Writing a tokenizer is much easier than parsing full syntax trees...Most other editors don’t construct the full syntax tree. Syntax highlighting is nice, but fast semantic analysis is the real holy grail. I have come to think that the best way to develop a new language would be to implement a text editor in that language before releasing the language…

I know of two languages trying something similar to this:

- https://dion.systems/faq.html - https://www.roc-lang.org/

They're both experimental, but fun to read about!

Re: Incremental Parsing in Go

#72

Post by bbkane »

tester756 wrote: post #13

Difference in complexity of IDE's parser and Compiler's parser feels like order of magnitude IDE's you want to be very fast, so you use techniques like partial tree reparse and now when I think about it, then you also may need to update other places like you use type that is defined somewhere below and at first parse that type definition doesn't compile, so type usage above shows an error and when you change type def…

You would like https://rust-analyzer.github.io/blog/2020/07/20/three-archit...

Re: Incremental Parsing in Go

#73

Post by geodel »

kaba0 wrote: post #64
geodel wrote: post #57

Earlier quoted context omitted.

> this is also the reason why java is quite ahead on “energy efficiency” reports as well. Very soon businesses would be asking for "dollar efficiency" also. I think going by effort on Java and their frameworks vendors to pack more instances of Java process/pods on a VM, it is already been asked by tech savvy customers. So that old fact that on sever side programing customers only care for raw throughput and not on ma…

To be honest, I really don’t get this microservice/cloud hype, stackoverflow (which let’s be honest will be bigger than that 34th startup) runs on a single (very beefy though) dedicated server machine. I pay like 5 dollars a month for a VM with very low params, but even that will happily run anything. Especially that the DB likely can’t be shared the bus factor will remain 1.

> To be honest, I really don’t get this microservice/cloud hype, ..

I agree on that. And the bureaucracy evolved around "Microservice Architecture" of Kube pods, service mesh and so many other pieces required for it feel like something we are trying to do it well, what should not be done in first place.

Re: Incremental Parsing in Go

#74

Post by frou_dh »

xyzzy4747 wrote: post #2

For max optimization, wouldn’t it be better to create a Rust or C library for parsing that Go links into? I personally don’t see the usefulness of trying to optimize Go itself too much as it’s handicapped by the runtime and garbage collection.

None of your ideas in this thread mention involving a profiler, so I take it you're from the Wild-Ass-Guess school of optimization?

Re: Incremental Parsing in Go

#75

Post by foldr »

super_flanker wrote: post #56
foldr wrote: post #17

Earlier quoted context omitted.

You’d generally expect Rust and Go to perform about the same for CPU bound workloads. Rust has access to more advanced codegen and optimizations via LLVM, but Go’s garbage collector will often be faster than refcounting (or whatever manual memory management technique your Rust code ends up using). This is especially so given that the GC runs on a separate thread without any additional effort on your part, making it a…

> Go’s garbage collector will often be faster than refcounting (or whatever manual memory management technique your Rust code ends up using) I'm not supporting the argument that everything should be written in Rust (or whatever) for good performance. However blanket statement like this is not true; micro-benchmarks are often misleading. There are many factors which affect the performance and they come with tradeoffs,…

Rust doesn’t offer the option of using a multi-threaded garbage collector. And ‘will often be faster’ is not a blanket statement; it’s just a rough generalization. I was basing the statement not on microbenchmarks but on the profiling done by the author of esbuild: https://news.ycombinator.com/item?id=22336284

Re: Incremental Parsing in Go

#76

Post by theta_d »

diffxx wrote: post #43

> The parsers produce a sequence to tokens, not a full syntax tree. Writing a tokenizer is much easier than parsing full syntax trees...Most other editors don’t construct the full syntax tree. Syntax highlighting is nice, but fast semantic analysis is the real holy grail. I have come to think that the best way to develop a new language would be to implement a text editor in that language before releasing the language…

So smalltalk?

Re: Incremental Parsing in Go

#77

Post by super_flanker »

foldr wrote: post #75
super_flanker wrote: post #56

Earlier quoted context omitted.

> Go’s garbage collector will often be faster than refcounting (or whatever manual memory management technique your Rust code ends up using) I'm not supporting the argument that everything should be written in Rust (or whatever) for good performance. However blanket statement like this is not true; micro-benchmarks are often misleading. There are many factors which affect the performance and they come with tradeoffs,…

Rust doesn’t offer the option of using a multi-threaded garbage collector. And ‘will often be faster’ is not a blanket statement; it’s just a rough generalization. I was basing the statement not on microbenchmarks but on the profiling done by the author of esbuild: https://news.ycombinator.com/item?id=22336284

> Rust doesn’t offer the option of using a multi-threaded garbage collector. I'm not sure why do you want a garbage collector in rust, most likely an arena allocator would be sufficient for what you may be looking for.

> esbuild That's an interesting situation. I'll have to take the author's word here since rust's version is not available for us to see. I write both go and rust (go for living and rust for side projects), I can see some situation where a naive implementation in go could perform better than naive implementation in rust (assuming both are implementing same algorithm). Again rust provides options to mitigate performance problems once you decide to optimize a bottleneck, but if you touch the upper ceiling in go program, there is not much you can do about it.

Re: Incremental Parsing in Go

#78

Post by foldr »

super_flanker wrote: post #77
foldr wrote: post #75

Earlier quoted context omitted.

Rust doesn’t offer the option of using a multi-threaded garbage collector. And ‘will often be faster’ is not a blanket statement; it’s just a rough generalization. I was basing the statement not on microbenchmarks but on the profiling done by the author of esbuild: https://news.ycombinator.com/item?id=22336284

> Rust doesn’t offer the option of using a multi-threaded garbage collector. I'm not sure why do you want a garbage collector in rust, most likely an arena allocator would be sufficient for what you may be looking for. > esbuild That's an interesting situation. I'll have to take the author's word here since rust's version is not available for us to see. I write both go and rust (go for living and rust for side projec…

You’d want a garbage collector in Rust for the same reason you’d want it in any other language. Manual memory management adds code complexity and can often be slower. Arena allocators only work in certain situations and considerably complicate management of lifetimes.

> , but if you touch the upper ceiling in go program, there is not much you can do about it

I’m not seeing this. There’s lots you can do to optimize Go code. Could you give a concrete example?

Post reply on HN