4 ms·

They certainly have a lot in common, either way: - Both compile to native code. - Both care a lot about performance. - Both care a lot about parallelism. -

They certainly have a lot in common, either way: - Both compile to native code. - Both care a lot about performance. - Both care a lot about parallelism. - Both care a lot about safety. - Both were invented by a major browser vendor, roughly around the same time. - Both include an unsafe fun zone that lets you play with raw pointers. Maybe some of that was inevitable just by following the trends in the field (safety and parallelism in particular), and we'll see other new languages making the same choices?

pjmlp 10y ago
> we'll see other new languages making the same choices? We are already seeing that, .NET and Java are finally paying more attention to the AOT story on their standard toolchains. And we also have Objective-C and Swift on iDevices.
MichaelGG 10y ago
Safety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP? Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I can use Rust basically anywhere I could use C, Go, not so much. That seems to put it squarely in a different segment than Go.
- codygman 10y ago
  > Go doesn't go beyond Java level safety Go doesn't reach Java level safety because of a lack of generics.
  - MichaelGG 10y ago
    Well it's still memory safe though, right? You'll just get a runtime error, not memory corruption.
    - weberc2 10y ago
      Mostly. Java puts a lock on every single object in a multithreaded context; Go doesn't do this as a performance tradeoff, so two goroutines manipulating a pointer simultaneously will likely corrupt it. FWIW, I've been using Go for 4 years and I've not yet seen a memory corruption.

pjmlp 10y ago

> we'll see other new languages making the same choices? We are already seeing that, .NET and Java are finally paying more attention to the AOT story on their standard toolchains. And we also have Objective-C and Swift on iDevices.

MichaelGG 10y ago

Safety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP? Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I can use Rust basically anywhere I could use C, Go, not so much. That seems to put it squarely in a different segment than Go.

codygman 10y ago
> Go doesn't go beyond Java level safety Go doesn't reach Java level safety because of a lack of generics.
- MichaelGG 10y ago
  Well it's still memory safe though, right? You'll just get a runtime error, not memory corruption.
  - weberc2 10y ago
    Mostly. Java puts a lock on every single object in a multithreaded context; Go doesn't do this as a performance tradeoff, so two goroutines manipulating a pointer simultaneously will likely corrupt it. FWIW, I've been using Go for 4 years and I've not yet seen a memory corruption.