4 ms·

It's interesting, given that Joel Spolsky says of Swift "It feels exactly like go", and this person is saying, "Swift is a dialect of Scala". Does that then i

It's interesting, given that Joel Spolsky says of Swift "It feels exactly like go", and this person is saying, "Swift is a dialect of Scala". Does that then imply that Go is a dialect of Scala?

deleted 12y ago
[deleted]
wben 12y ago
Sadly Go chose to use Garbage Collection instead of Reference Counting. I love using Python or Swift for applications that allocate (and free) real hardware resources, like OpenGL texture maps, frame buffer objects and in memory images.
- pjmlp 12y ago
  Because they care about performance in multi-core contexts.
  - danieldk 12y ago
    Reference counting and multi-core performance are not mutually exclusive at all. In a lot of applications where you exploit parallelism, you parallelise loops (e.g. via OpenMP), usually objects go out of scope outside the parallelized loop (single threaded code), so you can use a bare pointer. In the loop you do mostly stack allocations. Of course, there are degenerate cases where there's a lot of lock contention on the reference count. However, there are degenerate cases in most garbage collectors for multi-core as well. Isn't Go still using a stop-the-world GC? Edit: I wanted to add that I am not against garbage collectors. You lose deterministic destructors, but a well-developed garbage collector like the JVM's is very performant in most situations, and in many cases indeed more performant than reference counting.
    - bjourne 12y ago
      Then what languages or virtual machines uses reference counting and is performant in a muti-core context? :-)
    - pjmlp 12y ago
      You can have deterministic destruction in GC enabled languages.
danieldk 12y ago
And they all feel like dialects of OCaml ;). (I am not saying 'Haskell' here, because it does not include object oriented programming.) The thing is that the current generation of languages have so many overlapping features, that they are not all that different language-wise. Just like moving between Pascal, Ada, and Modula-2 was not that hard. Also, I'd say that Go is the exception here, because in contrast to Go, Swift manages to adopt insights from the last 30 of 40 years of PL research. Go is an utterly boring language and has very little to do with Scala (or Swift).
- themartorana 12y ago
  Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? I'm not a language geek mind you, but if people find it useful (and plenty of large and small companies have had huge wins with it at rapid pace) who cares if it's utterly boring?
  - danieldk 12y ago
    Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? Most of those characteristics are also true for PHP, which is arguably also easier to deploy, since nearly every virtual hosting provider has mod_php enabled and it is 'platform-independent'. Sure, it gets the job done. However, a lot of PL research has gone into making languages safer. Allowing you to make bugs that manifest at runtime, compile time errors. And while large bugs may not be that big a deal for the average web application, not everyone writes web applications. Billions are wasted on software bugs, from research that turns out to be invalid due to multiplication of units of measurement that cannot be multiplied, to Bitcoins that are lost due to programming errors, to deaths caused by errors in life-critical software. Go does almost nothing to solve the one of the largest challenges of software, namely to make it safer. Sure, it's more safe than C. But arguable it's even a step back from Java by its refusal to include some form of parametric polymorphism, requiring developers to revert to runtime introspection instead.
mseepgood 12y ago
Joel Spolsky's comment was not very well-informed.

It's interesting, given that Joel Spolsky says of Swift "It feels exactly like go", and this person is saying, "Swift is a dialect of Scala". Does that then imply that Go is a dialect of Scala?

deleted 12y ago

[deleted]

wben 12y ago

Sadly Go chose to use Garbage Collection instead of Reference Counting. I love using Python or Swift for applications that allocate (and free) real hardware resources, like OpenGL texture maps, frame buffer objects and in memory images.

pjmlp 12y ago
Because they care about performance in multi-core contexts.
- danieldk 12y ago
  Reference counting and multi-core performance are not mutually exclusive at all. In a lot of applications where you exploit parallelism, you parallelise loops (e.g. via OpenMP), usually objects go out of scope outside the parallelized loop (single threaded code), so you can use a bare pointer. In the loop you do mostly stack allocations. Of course, there are degenerate cases where there's a lot of lock contention on the reference count. However, there are degenerate cases in most garbage collectors for multi-core as well. Isn't Go still using a stop-the-world GC? Edit: I wanted to add that I am not against garbage collectors. You lose deterministic destructors, but a well-developed garbage collector like the JVM's is very performant in most situations, and in many cases indeed more performant than reference counting.
  - bjourne 12y ago
    Then what languages or virtual machines uses reference counting and is performant in a muti-core context? :-)
  - pjmlp 12y ago
    You can have deterministic destruction in GC enabled languages.

danieldk 12y ago

And they all feel like dialects of OCaml ;). (I am not saying 'Haskell' here, because it does not include object oriented programming.) The thing is that the current generation of languages have so many overlapping features, that they are not all that different language-wise. Just like moving between Pascal, Ada, and Modula-2 was not that hard. Also, I'd say that Go is the exception here, because in contrast to Go, Swift manages to adopt insights from the last 30 of 40 years of PL research. Go is an utterly boring language and has very little to do with Scala (or Swift).

themartorana 12y ago
Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? I'm not a language geek mind you, but if people find it useful (and plenty of large and small companies have had huge wins with it at rapid pace) who cares if it's utterly boring?
- danieldk 12y ago
  Aw, but what about utterly fast to develop in, utterly awesome at concurrency, utterly easy for ruby/python/dynamic-language devs to pick up and gain huge performance boosts, utterly easy to get in to the ecosystem, and utterly simple to use? Most of those characteristics are also true for PHP, which is arguably also easier to deploy, since nearly every virtual hosting provider has mod_php enabled and it is 'platform-independent'. Sure, it gets the job done. However, a lot of PL research has gone into making languages safer. Allowing you to make bugs that manifest at runtime, compile time errors. And while large bugs may not be that big a deal for the average web application, not everyone writes web applications. Billions are wasted on software bugs, from research that turns out to be invalid due to multiplication of units of measurement that cannot be multiplied, to Bitcoins that are lost due to programming errors, to deaths caused by errors in life-critical software. Go does almost nothing to solve the one of the largest challenges of software, namely to make it safer. Sure, it's more safe than C. But arguable it's even a step back from Java by its refusal to include some form of parametric polymorphism, requiring developers to revert to runtime introspection instead.

mseepgood 12y ago

Joel Spolsky's comment was not very well-informed.