cool stuff
Incremental Parsing in Go
31–40 of 78 posts
Re: Incremental Parsing in Go
#32Earlier quoted context omitted.
I don’t know, not implementing generics when it was pretty obviously needed was a huge oversight, so I’m not sure. Also, the reason for compiler bootstrapping is more of a “beauty thing”, then practicality. It would definitely be faster in a low-level language, but I doubt it would matter as an end user.
You aren't sure if Ken Thompson knows what he's doing?
As a software architect? Absolutely. Programming language designer? Not sure, neither C or Go are good languages in my personal opinion.
EDIT: I meant to write that I think very highly of him as an architect/developer.
Re: Incremental Parsing in Go
#33Earlier quoted context omitted.
> not implementing generics when it was pretty obviously needed was a huge oversight I get the desire for generics. I do a lot of C# and have used generics for a very many years. Yet I've been writing Go for around 6 or 7 years and other than in the beginning (when I was new to it) I haven't found myself missing them at all. In other words, for many people the lack of generics comes across as an oversight. For others…
Well, it is not a blanket statement, it’s just the generic truth (pun not intended) based on decades of evolution of programming languages and a relatively expensive mistake for Java, which would have been a perfect opportunity to learn from. Sure, it is seldom missed as an end user, but as a library user it is essential. That’s why map and the like had to be hard coded into the language, and why concurrent versions…
> Well, it is not a blanket statement, it’s just the generic truth
A bit contradictory, really, but that's just semantics I suppose.
More importantly even if you could say 99% of devs agree (and you can't because they don't) that still doesn't make it an oversight.
If they'd neglected to add generics because it wasn't considered, that's an oversight. If it was neglected because in the opinion of the creators of the language it wasn't needed for the purposes they created it for, that isn't an oversight but a thought-through engineering decision.
Of course you're free to disagree with that decision, but an oversight it was not.
Re: Incremental Parsing in Go
#34Earlier quoted context omitted.
Well, it is not a blanket statement, it’s just the generic truth (pun not intended) based on decades of evolution of programming languages and a relatively expensive mistake for Java, which would have been a perfect opportunity to learn from. Sure, it is seldom missed as an end user, but as a library user it is essential. That’s why map and the like had to be hard coded into the language, and why concurrent versions…
> Well, it is not a blanket statement, it’s just the generic truth A bit contradictory, really, but that's just semantics I suppose. More importantly even if you could say 99% of devs agree (and you can't because they don't) that still doesn't make it an oversight . If they'd neglected to add generics because it wasn't considered , that's an oversight. If it was neglected because in the opinion of the creators of the…
Fair enough, I may not have used the correct word, but it is still a typical “told you” situation, both during development, after go’s initial appearance and ever since until it finally was decided that it should be indeed implemented.
Re: Incremental Parsing in Go
#35Earlier quoted context omitted.
This is kind of a test of how nuanced your understanding of programming languages can be. Rust with a bit of effort put into optimization will be faster than Go with a bit of effort put into optimization, it is true. However, you need to double-check your intuition for how big and how consequential the delta is, because I'd guesstimate it as roughly a factor of two, possibly a touch less. It is true that Rust does a…
Not sure if rust vs go would be the best example here. Rust vs Java would be a better one — go has a very primitive GC in comparison, and java does optimize hot loops to a higher degree, so a naive code base would be very hard to beat in a lower level language.
I do a lot of “high throughput” stuff at work in both Go and Java, and the Go stuff is usually faster by default.
Java tends to win for really naive programs where the author didn’t bother caring about performance or allocations at all, but if any care was put into it at all Go usually wins in my experience.
The trope that Go’s GC is primitive in comparison to Javas is not really accurate. You can’t consider a language’s GC in isolation.
Java’s GC and JIT are extremely complex because the language semantics are terrible for performance by default. The “everything is an object” model made sense when the language was designed and main memory access times were roughly equal to a CPU cycles, but that’s no longer true by a factor 100 to 200 now.
Go’s GC makes different trade offs (low latency, extremely high concurrency, tight integration with the runtime and scheduler) because the language semantics are much more sympathetic to modern hardware (“true” structs, automatic escape analysis, etc), so it can.
Re: Incremental Parsing in Go
#36Earlier quoted context omitted.
> Well, it is not a blanket statement, it’s just the generic truth A bit contradictory, really, but that's just semantics I suppose. More importantly even if you could say 99% of devs agree (and you can't because they don't) that still doesn't make it an oversight . If they'd neglected to add generics because it wasn't considered , that's an oversight. If it was neglected because in the opinion of the creators of the…
Fair enough, I may not have used the correct word, but it is still a typical “told you” situation, both during development, after go’s initial appearance and ever since until it finally was decided that it should be indeed implemented.
True.
Whilst I haven't missed it in Go myself, enough other people say they do that its inclusion was inevitable. Which means it probably should have gone in sooner.
Re: Incremental Parsing in Go
#37Earlier quoted context omitted.
This is kind of a test of how nuanced your understanding of programming languages can be. Rust with a bit of effort put into optimization will be faster than Go with a bit of effort put into optimization, it is true. However, you need to double-check your intuition for how big and how consequential the delta is, because I'd guesstimate it as roughly a factor of two, possibly a touch less. It is true that Rust does a…
Not sure if rust vs go would be the best example here. Rust vs Java would be a better one — go has a very primitive GC in comparison, and java does optimize hot loops to a higher degree, so a naive code base would be very hard to beat in a lower level language.
Java requires a much more advanced GC and JIT because Java programs tend to allocate a lot more and have extremely bad memory layout when you're not restricting yourself to primitives. Project Valhalla's value types will significantly improve the situation. Relying so heavily on the JIT also has other problems especially in programs that have widely varying execution paths.
Re: Incremental Parsing in Go
#38If you want a hard/interesting parsing challenge, try Clojure’s #_ reader macro. It’s a powerful construct that allows you to comment the next form. If you’re not used to Clojure, it’s like writing #_ in front of anything --a function, an array, a keyword, etc-- to comment it, even if it’s on multiple lines.
For example:
#_ (defn foo
[x y]
(println x y))
(let [a #_ b 43] #_ #_ hello (H N) (print a))
(let [a 43] (print a))
The hard/interesting bit is that to tokenize you must construct a syntax tree in order to correctly parse the next form, but in order to construct a syntax tree you first need to tokenize the code.
Re: Incremental Parsing in Go
#39Earlier quoted context omitted.
Not sure if rust vs go would be the best example here. Rust vs Java would be a better one — go has a very primitive GC in comparison, and java does optimize hot loops to a higher degree, so a naive code base would be very hard to beat in a lower level language.
I do a lot of “high throughput” stuff at work in both Go and Java, and the Go stuff is usually faster by default. Java tends to win for really naive programs where the author didn’t bother caring about performance or allocations at all, but if any care was put into it at all Go usually wins in my experience. The trope that Go’s GC is primitive in comparison to Javas is not really accurate. You can’t consider a langua…
Sure, Go can get away with more primitive GC exactly because it has “value types”, so less garbage is created. But they are still much worse, lower latency only means that they pause threads to get more breathing space if they have been allocating too heavily, they are absolutely not even close to the same league Java’s low latency ZGC does.
Re: Incremental Parsing in Go
#40Earlier quoted context omitted.
> Well, it is not a blanket statement, it’s just the generic truth A bit contradictory, really, but that's just semantics I suppose. More importantly even if you could say 99% of devs agree (and you can't because they don't) that still doesn't make it an oversight . If they'd neglected to add generics because it wasn't considered , that's an oversight. If it was neglected because in the opinion of the creators of the…
Fair enough, I may not have used the correct word, but it is still a typical “told you” situation, both during development, after go’s initial appearance and ever since until it finally was decided that it should be indeed implemented.
There's a big misconception that the creators of go didn't want generics. They've stated a number of times that they didn't have a design that they all thought was adequate.
After several years and attempts at a good enough proposal, Ian Lance Taylor put one out that was able to cross the finish line, and now we have generics.