Earlier quoted context omitted.
If you are looking for X, Y will disappoint you. -or- If you are looking for X, use X.
Unless X is Python, then use Go (??)
When X is Python, and "time X" is too slow.
Leaving Go
131–140 of 220 posts
Re: Leaving Go
#132Earlier quoted context omitted.
As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.
> I'm not sure what the cause is, but it definitely gnaws at me. Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because th…
Or, in other words, advanced languages have some cognitive overhead that people working on extraordinarily complex applications can't spare?
Maybe. Then again, I've been using C++ again recently and I feel like the cognitive overhead there is so huge that I can barely understand my simple programs. Nonetheless, Microsoft pretty much runs on C++ (and C#).
Re: Leaving Go
#133I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html
Why do you feel this is worth pointing out?
Re: Leaving Go
#134Earlier quoted context omitted.
Unless X is Python, then use Go (??)
When X is Python, and "time X" is too slow.
Or "likelihood that program runs correctly if compiles correctly X" is too low, or "ability to write concurrent code in straight-line fashion rather than with callbacks X" is "too low".
Re: Leaving Go
#135Earlier quoted context omitted.
Go wasn't designed to replace C++, Go was designed to replace C++ at Google. And it totally succeeded at that, given the list of critical infrastructure at Google where Go is used, and in some cases has replaced existing C++ implementations.
Not sure if this was the same feel of Rob. > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
Yes, but he was talking programmers out there, not Google. IIRC, in 2012, they were still _very_ reluctant to talk about any use of Go within Google, with vitess being the only exception.
Re: Leaving Go
#136Earlier quoted context omitted.
This code doesn't actually compile. You can't assign v to x.(type) like that.
Are you sure? http://play.golang.org/p/dJC328-rh8 I did have to put "return x" as the last statement, though, not return v. And I'm not sure I'm happy about an "abs" that happily returns a string if fed a string, but, well, that's Go. Relevant bit of the spec: http://golang.org/ref/spec#Type_switches
Yes, the return statement was what I was referring to. You can't use a type switch to do some sort of an implicit conversion that exists outside of the switch statement.
Re: Leaving Go
#137Earlier quoted context omitted.
I know, I didn't say otherwise.
I think tptacek may have implying that, like all the REPLs for C, the REPLs for Go are more curiosities than anything anyone would want to use.
REPLs are for toying around and learning. The Go playground provides an alternative that seems to satisfy these needs for most people. If people really missed a Go REPL then the existing ones would not be "curiosities".
Re: Leaving Go
#138Earlier quoted context omitted.
As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.
> I'm not sure what the cause is, but it definitely gnaws at me. My theory is that it is because that is what we teach. If you go to school you learn Java (which is basically C#) and if you learn a language on your own most people recommend Java/C# because it will get you a job. By extension we end up with the vast majority of coders knowing Java/C#, thus most code gets written that way.
I think many experienced programmers forget how hard it was to write good code in the first place, whatever abstraction they started to use. I "learned" Java and C++ very quickly. I'm sure I was banging out code and stopped looking up most things within weeks. However, it took me years to actually understand how to write good code in those languages. I had to learn the patterns, I had to learn where the short-cuts and sharp edges were. I had to learn what features to avoid and which ones to embrace. It took a long time, but now it's all habit and instinct. I don't even have to think about it.
Asking someone to switch to using a new paradigm—like moving from OOP to FP—is asking them to relearn how to structure a program. All those habits and instincts no longer apply and new ones need to be learned. It takes years to learn how to write good high-quality FP programs. I know I'm still learning and I first picked up Haskell as a primary hobby four years ago. It probably took me a year before I really understood what a monad was and could apply that abstraction, similar to how long it took me to really understand and apply things like visitor patterns.
I believe that if you took an entirely untrained person you could get them to be at least as productive if you taught them with FP versus OOP from the start.
Re: Leaving Go
#139If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…
> Systems C programmers I don't know many (TBH none) c programmers that likes or actually uses go. The thing is that as for c++ if you are still writing in c is just for few reasons: portability (in terms of embedding your library) and speed. Especially the former seems very important. EDIT: I know => I know personally or I follow.
I'm a "C programmer" that loves working in Go.
Re: Leaving Go
#140[deleted]