ngrilly

88 ms·

961.
by ngrilly 9y ago
I'm aware of the ongoing work to enable multicore parallelism in OCaml. It's the reason why I mentioned OCaml in my comment. My comment was rhetoric. My apologies if it was not clear. That said, I don't see the link between t
962.
by ngrilly 9y ago
Yes, but it completely ruins the argument about "it's easy to reason about" ;-)
963.
by ngrilly 9y ago
> In the simplest form, you do not give up control unless you use I/O, a synchronization primitive, or explicitly give up control (runtime.Gosched() in Go). This is not how Go works nowadays. There are other preemption points.
964.
by ngrilly 9y ago
Here is an excerpt from the recent proposal on non-cooperative goroutine preemption [1], relevant to our discussion on GC and interior pointers: > Many other garbage-collected languages use explicit safe-points on back-edges, or they use
965.
by ngrilly 9y ago
> .NET doesn't have heap interior pointers (today), but that doesn't matter for this argument. I think it matters for this argument. You are arguing that designing a garbage collector which is concurrent, low latency (pauses &l
966.
by ngrilly 9y ago
> Indeed, .NET has interior pointers, and it doesn't cause any problem at all. Are you sure about this (without using C# unsafe context)? I've spent a moment digging in C# documentation and been unable to confirm this.
967.
by ngrilly 9y ago
I didn't know about .NET permitting interior pointers. Thanks. I think you're right about HotSpot GC not using read barriers. I was mixing it up with the Azul GC, which uses read barriers. > If you have concurrent mark-and-swee
968.
by ngrilly 9y ago
If you are interested by this topic, here is a relevant discussion on golang-nuts: https://groups.google.com/d/topic/golang-nuts/KJiyv2mV2pU/di... One of the arguments mentioned against having a generati
969.
by ngrilly 9y ago
It's not "unfortunate". It's a known drawback of the tradeoff chosen by Go.
970.
by ngrilly 9y ago
Thanks for the link. Does Swift provide something similar to goroutines?
971.
by ngrilly 9y ago
> Go couldn't afford not to have a generational GC without value type And Java couldn't afford not to have value types without a generational GC ;-) > C, C++ and Rust can't use a bump allocator since you need a compacti
972.
by ngrilly 9y ago
I already agreed that allocation is faster in Java than in Go. What I'm saying is that allocation speed is less critical in Go than in Java. In Java, if you allocate an object containing 10 other objects, you have to allocate 11 object
973.
by ngrilly 9y ago
I always thought that generating one polymorphic version would be a better fit for Go than generating multiple specialized versions. It's interesting that Swift adopted this approach and confirms what you said earlier about Swift havin
974.
by ngrilly 9y ago
You're right about the issue I mentioned which is irrelevant since there is no overloading in Go. Thanks for pointing it out. I didn't know you worked on Rust and now on Swift :-) What strategy does Swift use to compile a generic
975.
by ngrilly 9y ago
> The difference is that Go relies on escape analysis a lot more than the JVM does, because Go's GC has much slower allocation due to not being generational. True, but this is only a part of the story. In Java, every custom type is
976.
by ngrilly 9y ago
I agree. I hope the Go team will tackle this issue, when they are done with dependency management.
977.
by ngrilly 9y ago
I remember Mono with AOT compilation had some limitations regarding generics in the past, but maybe this has been solved since then.
978.
by ngrilly 9y ago
I didn't mention Swift and I should have. I agree it's close enough to Go to provide useful inspiration. But even Swift implementation of generics has its issues and tradeoffs. Look for example at this thread about "Compile-t
979.
by ngrilly 9y ago
The main difference is that you cannot catch a specific block of code in the function body. You can only catch when leaving the function (in a defer clause in Go). try/catch/finally is really a control structure. panic/recove
980.
by ngrilly 9y ago
> in practice, Cargo doesn't even use a SAT solver anyway, so they didn't do their homework It's not fair to accuse people of not doing their homework when they actually are... Russ Cox published "Version SAT" in
981.
by ngrilly 9y ago
I meant that Go usually focuses more on solving practical issues than theoretical issues. But I have to agree that it is the exact opposite in the example I replied to ;-) Yes, Cargo doesn't use a SAT solver, but Cargo' source cod
982.
by ngrilly 9y ago
You can commit a go.modverify file in your project which contains a digest of each module used in the project.
983.
by ngrilly 9y ago
panic/recover is a bit different from exceptions because it can be used as a control structure (like if/for/switch) inside a function. Rust has something similar with panic!.
984.
by ngrilly 9y ago
I agree, but it's not a detail in practice. My feeling is that Rust is very attentive to theoretical details, and Go to practical details. Of course it's an over-simplification, and both approaches are pertinent and complementary
985.
by ngrilly 9y ago
Yes, but Go has specificities that make difficult to directly use the scheme used by other languages: Go is AOT compiled (we can't use C# generics), Go favors compilation speed (we can't use C++ template), Go lets the developer co
986.
by ngrilly 9y ago
> The popular criticism is that Go isn't reinventing enough; that it's stuck in the 70's and it's not sufficiently innovative. That's popular, but unfounded, in my opinion. I find ironic that some HN commenters a
987.
by ngrilly 9y ago
No, it's hardly a standard. It's just a common approach. The article presents another approach which differs on the three points you mention: manifest plus lock as separate declarations, SAT solver, single dependency version per c
988.
by ngrilly 9y ago
You're right, nothing in the spec prohibits "vendoring" the .zip modules in a directory in your project. It's purely an implementation issue. vgo already provides GOPROXY, but a built-in "vendoring" mechanism w
989.
by ngrilly 9y ago
You don't have to "pull sources from GitHub". You can host your code as a .zip file on any static web server. Look at under "Download Protocol" in this article: https://research.swtch.com/vgo-module
990.
by ngrilly 9y ago
There is only 24 hours in a day, and the Go team has limited resources. They focused on other issues in the last few years. Dependency management is the current focus now.

More ›