81–90 of 135 posts
Mods, please add (podcast) warning to title. There is no transcript.
Transcripts are delayed a few days but there will be a transcript. We have a human on staff (Alex) to ensure every podcast we produce a highly readable transcript that can also be contributed to via Github.
No progress bar. No fast forward button. No speed-up. Man this UX is frustrating.
https://i.imgur.com/TMe45IJ.png
Also a download link for mp3.
Earlier quoted context omitted.
Like a standard library that doesn't even have a max function for integers, or a set type?
It is trivial to write both of these on your own, why do we need unnecessary abstraction for such a simple task.
Earlier quoted context omitted.
\o I still use GOPATH structure since it's such a nice way to organize my code.
I didn’t like it at first but didn’t have much choice. After a while I liked the structure. I don’t even write go anymore and I still use gopath structure for my work
Earlier quoted context omitted.
The Go implementation has gotten more sophisticated over time. It now has an optimizing SSA backend, a rather intricate GC, etc. I still disagree with a fair number of the Go implementation design decisions, but I certainly wouldn't call the compiler a basic implementation anymore.
Having worked on the Go port for SPARC with another person (don't know if it was ever completed), I have to agree with the parent here. The implementation of Go itself (based on 1.5-1.8 when I worked on it) was actually very complex. Large swaths of the codebase were completely uncommented and much of the knowledge about how the system is intended to work resides in the heads of the core Go team.
Earlier quoted context omitted.
Having worked on the Go port for SPARC with another person (don't know if it was ever completed), I have to agree with the parent here. The implementation of Go itself (based on 1.5-1.8 when I worked on it) was actually very complex. Large swaths of the codebase were completely uncommented and much of the knowledge about how the system is intended to work resides in the heads of the core Go team.
If only y’all could have just used llvm
In my view, if Cranelift had been around when Go was announced, it would have been the clear best choice over LLVM, due to compile times and relative simplicity allowing for easy modifications to add things like precise moving GC and moving stacks.
Earlier quoted context omitted.
Having worked on the Go port for SPARC with another person (don't know if it was ever completed), I have to agree with the parent here. The implementation of Go itself (based on 1.5-1.8 when I worked on it) was actually very complex. Large swaths of the codebase were completely uncommented and much of the knowledge about how the system is intended to work resides in the heads of the core Go team.
If only y’all could have just used llvm
Earlier quoted context omitted.
> Google's developer marketing Like Google did marketing for Dart and it picked up?
Dart lost the support from Chrome team, it was rescued by AdWords team and Flutter is trying to make it relevant, but given Android team answers, it is clear that a power struggle is going on across teams. Giliad is also a personality from language research hardly known by UNIX fans.
What this has got to do with Dart's popularity outside Google?
> Giliad is also a personality from language research hardly known by UNIX fans.
So unix fans did not let a superior language which was designed by real language researcher like Dart win?
Earlier quoted context omitted.
Having worked on the Go port for SPARC with another person (don't know if it was ever completed), I have to agree with the parent here. The implementation of Go itself (based on 1.5-1.8 when I worked on it) was actually very complex. Large swaths of the codebase were completely uncommented and much of the knowledge about how the system is intended to work resides in the heads of the core Go team.
If only y’all could have just used llvm
