61–70 of 175 posts
This is discouraging considering go was initially designed as a systems programming language. I wonder if there is another way for go to handle blocking syscall such that this use case would become reliable.
Earlier quoted context omitted.
> The only reason Go is as popular as it is is because of Google's marketing budget. Every programmer on Earth heard of Go within a few days of it's official release. I think Google put lot of marketing budget for Dart. But I don't see it ever comes in discussion regarding popularity or lack of it. It is fine a lot of people do not like Go but claiming its popular just because of Google seems baseless.
Well, Go is obviously not a bad language. That said, I do think that it's adoption was primarily fueled by Google's popularity. Imagine go being released by a single person or small group of people. How would people have heard about it?
It is fair to say that without those names attached I would have likely passed it by. Google is boring, but those three names, for me at least, I had to take a look.
Earlier quoted context omitted.
It's more than fine to be enthusiastic about programming languages. However, some of your points about Go are dubious. The reasons Go doesn't (yet) have generics are practical rather than philosophical. And well-documented. I also don't believe Google's marketing budget contributed much if anything to supporting Go. The _reputation_ of Google and the Go authors was far more important. (Personally, when I saw people l…
No, I encourage you to shill in fact. > The reasons Go doesn't (yet) have generics are practical rather than philosophical. And well-documented. Can you give an example? I guess I fail to understand why a statically typed language would choose to forgo all of the advantages generics provide. Does it have something to do with Goroutines? > I also don't believe Google's marketing budget contributed much if anything to…
Like I said, the objections are practical, not philosophical:
They published four past design docs for generics in Go that simply didn't pass technical muster (https://github.com/golang/proposal/blob/master/design/15292-...)
Also, rsc stated he plans to understand generics better in 2017: https://research.swtch.com/go2017#generics
Also, bradfitz said recently on the GoTimeFM podcast that doing Generics and Go2 together makes sense.
> I didn't necessarily mean their marketing budget. I should probably edit that. I meant that anything they do is news.
I feel like the comments from others about Dart give the lie to this one. Go is fantastically, dramatically, massively more popular than Dart, which is also from Google.
Earlier quoted context omitted.
Sorry, I don't understand what you mean by "Go hijacks control flow". Could you elaborate cases, where Go did not behave as you expected? And where syntactic and semantic correct Go code did not compile?
So, keep in mind that my experience with Go is not at a professional level. Take this example: https://gobyexample.com/channel-buffering As far as my understanding is concerned, channels are a way for goroutines to pass data between one another, correct? Yet in this particular case, the channel `messages` is operating in the same manner as a generator or array. So, am I creating goroutines by passing messages to the…
Earlier quoted context omitted.
Sorry, I don't understand what you mean by "Go hijacks control flow". Could you elaborate cases, where Go did not behave as you expected? And where syntactic and semantic correct Go code did not compile?
So, keep in mind that my experience with Go is not at a professional level. Take this example: https://gobyexample.com/channel-buffering As far as my understanding is concerned, channels are a way for goroutines to pass data between one another, correct? Yet in this particular case, the channel `messages` is operating in the same manner as a generator or array. So, am I creating goroutines by passing messages to the…
The flow of data through channels can be confusing until the concept becomes familiar, but the behavior is well-defined, so the behavior is as easy or difficult to predict as of any program of the given complexity.
Earlier quoted context omitted.
No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…
This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics withou…
It's not as easy as threads (M:N vs 1:1 is a red herring as far as this is concerned), but there's no free lunch.
Earlier quoted context omitted.
This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics withou…
You can see for yourself [1]. Seems many users are not following the patterns of Async IO in Rust. 1. https://www.reddit.com/r/rust/comments/6enj5d/what_does_rust...
Earlier quoted context omitted.
Because C++ is vastly more complex than either C or Go.
In C, I could not find good libraries for basic stuff (dynamic string manipulation, variable-sized arrays, hash tables). I tried glib but it was much worse than C++'s STL. It is entirely possible to write C-style programs in C++ (very few classes, globals all over the place) and so on, and at least for me, C-style software in C++ are much safer/easier to debug than C-style software in C .
But I'm like you, if I know that I'm going to need "advanced" data structures I'll pick C++ over C (or these days more likely Rust).
Earlier quoted context omitted.
Historically, much (I would probably argue most) C concurrency has been implemented with fork. Certainly not all, and there are many ways to handle it in C...but fork is really common, and I don't think it's considered all that big of a deal to do so. It is idiomatic (at least historically and across maybe billions of lines of C code), and not much harder to reason about than many kinds of thread implementation in C;…
> C concurrency has been implemented with fork. Arguably it has been implemented with clone(2) which has flags. > in fact, it's easier to reason about fork than something like POSIX threads, IMHO. Not if you call fork() in a multi-threaded program. That ends _exceptionally_ badly (let's just say there's a reason Go doesn't expose syscall.Fork and it has to do with horrific deadlocks). > I just didn't see the problem…
Namespace based code while doing the same is like setting your hair on fire while running through the gasoline forest..but caveat emptor is usually spelled out pretty critically in the API and docs.
Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language.