5 ms·

What other languages of comparable popularity do you know that had concurrency similar to Go's, and interfaces? Actually, name just one that has either, even t

by tomp 3y ago

What other languages of comparable popularity do you know that had concurrency similar to Go's, and interfaces? Actually, name just one that has either, even today!

ninepoints 3y ago
Erlang
- phinnaeus 3y ago
  > of comparable popularity
  - throwawaymaths 3y ago
    It was more popular than go in 2009
- Thaxll 3y ago
  Erlang is not a popular language.
- tomp 3y ago
  Erlang's processes might have similar semantics to Go's goroutines (green threads) but Erlang is a much simpler language, because it doesn't have shared state. A lot of work went into optimizing Go's GC to be able to cope with concurrency.
easton 3y ago
C#? It has channels and good concurrency stuff. I don’t know if it was as mature in 2007 when they did this work. edit: Concurrency, not the language itself. That was mature.
- moomin 3y ago
  C# not only has channels, it has async/await, which he concedes is the actually popular form of concurrency in that others have adopted it.
dwattttt 3y ago
Java has had interfaces for a _long_ time, and it definitely meets the popularity requirement. EDIT: Since its 1.0 release in 1996
- tomp 3y ago
  There's nothing similar about Java's and Go's interfaces, except the name. Java interfaces must be implemented explicitly (they're nominal). Go interfaces are automatically satisfied by any type that declares matching methods (similar to protocols in other languages) (they're structural).
  - twic 3y ago
    They are certainly different, but to say there is nothing similar is plainly untrue - apart from nominal vs structural, they are pretty much the same. I'm not sure how significant the nominal vs structural distinction even is. In Go, a struct can implement an interface without declaring it, but the programmer still needs to deliberately write the struct to conform to the definition of the interface, so they're still coupled, just not explicitly [1]. Yes, it is possible to define a new interface which fits existing structs which weren't designed for it - but how common is that? That is, how common is it for two or more structs to have a meaningful overlapping set of methods without being designed to conform to some pre-existing interface? [1] which is obviously a bad thing
  - dwattttt 3y ago
    Go's nominal interface feature is definitely interesting, but that section doesn't talk about how amazing it was to implement interfaces implicitly: > That notion quickly grew into the idea that value types had behaviors, defined as methods, and that sets of methods could provide interfaces that functions could operate on. Go's interfaces arose pretty much right away. If you replace Go with Java, this would've accurately described Java ~30 years ago.
    - tomp 3y ago
      You missed this: > Making interfaces dynamic, with no need to announce ahead of time which types implement them
scythe 3y ago
Fibers were implemented by Microsoft in Win32 API in 1996: https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=102989 https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10... As the review Chen links discusses, it turns out that M:N threading (i.e. goroutines) and good C compatibility are mutually exclusive. Go went one way, every other language went the other way. The most common alternative is stackless coroutines, which are much more widely implemented than the Go model.
- zozbot234 3y ago
  That review is by Gor Nishanov: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136... The most relevant quote: > DO NOT USE FIBERS!
- tomp 3y ago
  Even stackless coroutines aren't very popular. No other popular language specification has them (except maybe Haskell/GHC, but it's not that popular).
  - iainmerrick 3y ago
    JavaScript?
- magicalhippo 3y ago
  And COM interfaces. They could be clunky in C/C++ but Delphi implemented interfaces quite nicely[1] back in 1999[2]. And being for Windows, Delphi had full access to Win32 API. [1]: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_Interfaces_Across_the_Hierarchy https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_In... [2]: https://en.wikipedia.org/wiki/History_of_Delphi_(software)#Borland_Delphi_5 https://en.wikipedia.org/wiki/History_of_Delphi_(software)#B...
neonsunset 3y ago
Go's concurrency isn't even that good. It just looks good for anyone coming from the languages which don't have that (which are the majority). One of the earliest high level languages with powerful concurrency and parallelism APIs are C# and F# (TPL and Parallel/PLINQ, some of which was available back in 2010).
OkayPhysicist 3y ago
Elixir and Erlang have both, and Go's concurrency model is just a poor imitation of what you get from Erlang, that's been around since the 80's.
moomin 3y ago
To the extent that Go has features that no other popular language has, it is not influential. To the extent to which it invented those things, it's not influential. And that's why he didn't make that claim, he made a much broader one. The only problem is, if you make the broader one, it's obvious it's F#/C# that's been influential.

by tomp 3y ago

What other languages of comparable popularity do you know that had concurrency similar to Go's, and interfaces? Actually, name just one that has either, even today!

ninepoints 3y ago

Erlang

phinnaeus 3y ago
> of comparable popularity
- throwawaymaths 3y ago
  It was more popular than go in 2009
Thaxll 3y ago
Erlang is not a popular language.
tomp 3y ago
Erlang's processes might have similar semantics to Go's goroutines (green threads) but Erlang is a much simpler language, because it doesn't have shared state. A lot of work went into optimizing Go's GC to be able to cope with concurrency.

easton 3y ago

C#? It has channels and good concurrency stuff. I don’t know if it was as mature in 2007 when they did this work. edit: Concurrency, not the language itself. That was mature.

moomin 3y ago
C# not only has channels, it has async/await, which he concedes is the actually popular form of concurrency in that others have adopted it.

dwattttt 3y ago

Java has had interfaces for a _long_ time, and it definitely meets the popularity requirement. EDIT: Since its 1.0 release in 1996

tomp 3y ago
There's nothing similar about Java's and Go's interfaces, except the name. Java interfaces must be implemented explicitly (they're nominal). Go interfaces are automatically satisfied by any type that declares matching methods (similar to protocols in other languages) (they're structural).
- twic 3y ago
  They are certainly different, but to say there is nothing similar is plainly untrue - apart from nominal vs structural, they are pretty much the same. I'm not sure how significant the nominal vs structural distinction even is. In Go, a struct can implement an interface without declaring it, but the programmer still needs to deliberately write the struct to conform to the definition of the interface, so they're still coupled, just not explicitly [1]. Yes, it is possible to define a new interface which fits existing structs which weren't designed for it - but how common is that? That is, how common is it for two or more structs to have a meaningful overlapping set of methods without being designed to conform to some pre-existing interface? [1] which is obviously a bad thing
- dwattttt 3y ago
  Go's nominal interface feature is definitely interesting, but that section doesn't talk about how amazing it was to implement interfaces implicitly: > That notion quickly grew into the idea that value types had behaviors, defined as methods, and that sets of methods could provide interfaces that functions could operate on. Go's interfaces arose pretty much right away. If you replace Go with Java, this would've accurately described Java ~30 years ago.
  - tomp 3y ago
    You missed this: > Making interfaces dynamic, with no need to announce ahead of time which types implement them

scythe 3y ago

Fibers were implemented by Microsoft in Win32 API in 1996: https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=102989 https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10... As the review Chen links discusses, it turns out that M:N threading (i.e. goroutines) and good C compatibility are mutually exclusive. Go went one way, every other language went the other way. The most common alternative is stackless coroutines, which are much more widely implemented than the Go model.

zozbot234 3y ago
That review is by Gor Nishanov: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136... The most relevant quote: > DO NOT USE FIBERS!
tomp 3y ago
Even stackless coroutines aren't very popular. No other popular language specification has them (except maybe Haskell/GHC, but it's not that popular).
- iainmerrick 3y ago
  JavaScript?
magicalhippo 3y ago
And COM interfaces. They could be clunky in C/C++ but Delphi implemented interfaces quite nicely[1] back in 1999[2]. And being for Windows, Delphi had full access to Win32 API. [1]: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_Interfaces_Across_the_Hierarchy https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_In... [2]: https://en.wikipedia.org/wiki/History_of_Delphi_(software)#Borland_Delphi_5 https://en.wikipedia.org/wiki/History_of_Delphi_(software)#B...

neonsunset 3y ago

Go's concurrency isn't even that good. It just looks good for anyone coming from the languages which don't have that (which are the majority). One of the earliest high level languages with powerful concurrency and parallelism APIs are C# and F# (TPL and Parallel/PLINQ, some of which was available back in 2010).

OkayPhysicist 3y ago

Elixir and Erlang have both, and Go's concurrency model is just a poor imitation of what you get from Erlang, that's been around since the 80's.

moomin 3y ago

To the extent that Go has features that no other popular language has, it is not influential. To the extent to which it invented those things, it's not influential. And that's why he didn't make that claim, he made a much broader one. The only problem is, if you make the broader one, it's obvious it's F#/C# that's been influential.