3 ms·

I had use VC and VB a long time (15+ years) ago and have since moved to Linux + gcc, python, golang, mobile etc. After watching this video for 20 minutes of al

by tkinom 12y ago

I had use VC and VB a long time (15+ years) ago and have since moved to Linux + gcc, python, golang, mobile etc. After watching this video for 20 minutes of all the fancy GUI details, I have couple of higher level questions: 1) Do C#/VB still only build for Windows, Win Mobile? Can they build targets for IOS, Android, Linux? I heard the new CEO of MSFT suppose to be more supportive of cross platforms. 2) I began to like the concurrency model in golang a lot. Does the C#, VB support that kind of concurrency in their language design?

Sir_Cmpwn 12y ago
1 - Mono still works well and Rosyln compiles and runs in Mono. 2 - Not at a syntax level, but there is good concurrency support in the .NET stack.
- mariusmg 12y ago
  "Concurrency" at syntax level is kind of dumb anyway.
  - tkinom 12y ago
    The way golang works seems to be follow the model of Unix pipe (stdio pipe) between process. They are simple channel between go-routines (kind of) light weight threads. The concept is built into the language itself. Anything wrong with that?
    - mariusmg 12y ago
      Yeah. Goroutines not backed by real threads (afaik there's also gorountine -> os thread), those "green" threads from Ruby and fibers are just ugly hacks. Sorry but from my point of view, "real" concurrency is done at the OS level. The OS schedules threads to the CPU depending on their priority and "other" things. Having a single OS thread and runtime code that "yields" so another piece of code can run in the same thread, that's not concurrency...that's a toy. Sorry for being so blunt.....but that's my opinion.
      - cjslep 12y ago
        At least initially, the gccgo compiler implemented goroutines as OS native threads and am wanting to say it still does.
      - pritambaral 12y ago
        Switching goroutines is much lighter than switching OS threads. When this "toy" and "hack" becomes as heavy or slow and thus no more useful than OS threads, then you can make a point. As I see it, you aren't making a point right now, just explaining what OS threads do and calling goroutines names. So let me point in the direction of an explanation of what goroutines do: http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_Desh...

by tkinom 12y ago

Sir_Cmpwn 12y ago

1 - Mono still works well and Rosyln compiles and runs in Mono. 2 - Not at a syntax level, but there is good concurrency support in the .NET stack.

mariusmg 12y ago
"Concurrency" at syntax level is kind of dumb anyway.
- tkinom 12y ago
  The way golang works seems to be follow the model of Unix pipe (stdio pipe) between process. They are simple channel between go-routines (kind of) light weight threads. The concept is built into the language itself. Anything wrong with that?
  - mariusmg 12y ago
    Yeah. Goroutines not backed by real threads (afaik there's also gorountine -> os thread), those "green" threads from Ruby and fibers are just ugly hacks. Sorry but from my point of view, "real" concurrency is done at the OS level. The OS schedules threads to the CPU depending on their priority and "other" things. Having a single OS thread and runtime code that "yields" so another piece of code can run in the same thread, that's not concurrency...that's a toy. Sorry for being so blunt.....but that's my opinion.
    - cjslep 12y ago
      At least initially, the gccgo compiler implemented goroutines as OS native threads and am wanting to say it still does.
    - pritambaral 12y ago
      Switching goroutines is much lighter than switching OS threads. When this "toy" and "hack" becomes as heavy or slow and thus no more useful than OS threads, then you can make a point. As I see it, you aren't making a point right now, just explaining what OS threads do and calling goroutines names. So let me point in the direction of an explanation of what goroutines do: http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_Desh...