111–120 of 178 posts
I know it's cliche, but I still can't live without generics or a macro-like approximation thereof. I suffered under Java 2 for too long to go back to that.
It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in: div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a)) than it is in (-b+sqrt(b^2-3 a c))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably…
(-b + math.Sqrt(bb - 4ac)) / (2 a)
though if you're using a ton of matrices it could be.
I for one have found Go great for computing. The really quick compile times with static checking plus the composability are great. It definitely depends though; while the native concurrency is great there aren't a lot of easy solutions for non-shared memory computations. (I saw an MPI package at one point, but I haven't tried to use it)
Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java. If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more com…
I have to admit, I don't agree with the assertion that the cognitive dissonance associated with programming in an imperative way versus a functional way is a major problem to Scala. I realize personal preference is a very big part of this, but there are many problems which are just easier to solve in a functional way versus an imperative way. Of course, the opposite holds true as well. This is the beauty of Scala; one can write performance-critical imperative code while exposing a functional interface; or, one can consume a fluent functional interface to produce imperative code.
Frankly, I guess I've become something of a functional zealot, so my problem with Go is that it's so stubbornly imperative. This is why I can't get behind Go, as much as I want to. I feel like it doesn't consider many of the lessons that have been learned about FP making life easier. Set operations (map, filter, reduce) are insanely common, yet doing them imperatively sucks to the point of discouraging them. Excessive mutability is difficult to reason about. Nobody expects the nil/null/none inquisition. We tend to forget about side effects. Without an extensible language, which requires truly first-class functions, you're at the language designer's mercy.
Hell, Scala probably isn't the be-all, end-all answer to all of this. I just don't think that a doggedly-imperative, non-composable, statement-oriented language is the future of programming "in the large", not when the past has shown us that we tend to produce buggy, unmaintainable software this way. I'm pragmatic enough to realize that pure FP isn't a solution, but I feel strongly that sticking to traditional imperative because it's familiar is a costly mistake.
I can't argue with your take on the syntax, though, since that's personal preference. =) If you have any thoughts on why you feel productive in Go, I'd love to hear them; as I've said, I've been really struggling with motivating myself to learn and enjoy it.
Earlier quoted context omitted.
I, as a user interested in both, did find value in the comment regardless of his/her intentions. This comes off as a 'shut up' when really, it could be a good opportunity to look at what Go does right for implementation in Rust, no?
Because it's plainly a troll. ("Go will make you cry for using Rust" made that clear, especially considering the user's comment history, in which I've already explained why at least visibility on case doesn't make sense.)
That particular quote is related to "cleanliness of the language" obviously it's not an apples to apples comparison.
My apologies to all of you Rust devs who might get offended with my comment, wasn't my intention, you are doing an awesome job I'm looking for 1.0 meanwhile I'll keep toying around with the language.
Earlier quoted context omitted.
> Not so relevant Then why post?
I, as a user interested in both, did find value in the comment regardless of his/her intentions. This comes off as a 'shut up' when really, it could be a good opportunity to look at what Go does right for implementation in Rust, no?
My apologies again to rust devs.
Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java. If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more com…
What it needs is some leadership. A few weeks ago Rob Pike and Andrew Gerrand (developers of Go) appeared on The Changelog podcast, which I recommend listening to, and one thing that Rob Pike said really intrigued me. He said that a policy they have when designing Go is to ensure that all members of the core team agree on any design decision before it gets put into the language. If one of them disagrees it gets tossed.
That's probably one of the main reasons why Go is such an "opinionated" language and very small in nature. This probably infuriates some people as their favourite feature from other languages is missing in Go, but it keeps the language where it is and steers it on a path that the designers are maintaining complete control of.
Earlier quoted context omitted.
Has anyone here used Haskell in a production environment? I want a language that is small, clean, and can provide a lot of static guarantees . I know many people find static guarantees and unacceptable curtailment of their "programming freedom", but frankly I think it's the answer to many of the problems we face in software today. Small is another thing. E.g. Go and Scheme are small . C++ and Scala are large . You kn…
"(In Haskell, all function are pure by default, and you escape the confines of purity via monads.)" This is not true. Nothing about monads, in themselves, allows you to write impure functions.
Earlier quoted context omitted.
Exactly. The maturity level is about the same--obviously in different ways--but I think you get what I mean. Will they ever add generics? Not sure. Will Java ever have proper first-class functions? Not sure.
why generics? Have you really understood how to write Go? Generics are not needed, you have interfaces.
As a developer on the Python stack, I would love to know when would be a good time to start using Go in serious production work. It seems to me that it solves a lot of the backend services infrastructure problems associated with interpretive languages (one of the reasons I was considering diving in Scala or other JVM languages), is relatively reliable, and has a fairly strong core library. It still seems bleeding edg…
> I would love to know when would be a good time to start using Go in serious production work Now would be a good time. No language, runtime, compiler, library, or framework is ever going to be perfect, but now is a great time to dive in. > It still seems bleeding edge This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable peop…
As was Javascript plus Node.js two years ago, Ruby and RoR five years ago, etc.
You'd think that more reasons are required than 'it is new, doesn't have baggage in was created by smart people'.