I'm yearning for the Golang of functional programming. That is, excellent std lib, clear documentation, awesome tooling, active community.. and after typing this, maybe that's Elixir? Though I do love static typing.
The State of Go
121–130 of 402 posts
Re: The State of Go
#122Earlier quoted context omitted.
Especially when compared to working with something like Spring Boot every day it's fantastic. Getting rid of all the bloat is a bigger win than any of its unique features in my opinion.
What are your problems with spring boot? What bloat are you referring to?
For me, I imagine the dropwizard guys sat round asking each other what the best servlet container is, web MVC tool, ORM, DI framework, etc, etc. and they choose the very best they can think of for a dev to work with.
Then a couple of years later that company comes along where they ask the same questions and but there's a guy with Tourette's in the corner and Every. Single. Time. the answer to the question is SPRING!! SPRING!! SPRING'S THE RIGHT ANSWER!! SPRING!
From the moment you boot spring boot and discover how much longer it takes to boot it's a struggle not to question the motivations of a place where the answer's the same no matter the question.
Sorry. I know some people love it!
Re: The State of Go
#123Earlier quoted context omitted.
Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…
I don't know go, can't you write a map in it?
Not a type safe one that works on your own types.
Re: The State of Go
#124Earlier quoted context omitted.
I dunno... in some ways, the problem is that they didn't think it through to begin with, and chose something widely-known-to-be-ambiguous-and-problematic like "time.Now()", instead of choosing unambiguous names / structures from the start. It's kinda the equivalent of making a new language (nowadays) and not defining what encoding your native strings use. Of course it's going to cause problems. Except the timer issue…
Fair point! And I certainly don't claim that the Go devs don't make mistakes. They started with the theory that the problem should solved as Google does, by arranging that clocks don't run backwards. When it become clear that wasn't reasonable, they moved towards a new solution in a way that I felt was impressive.
It's mostly-impressively backwards compatible, I'll definitely agree there. It's clever, and in many cases it'll do the right thing automatically. Since it seems that's their goal, they achieved it quite elegantly, and that's a tricky thing to do. (edit: and quite quickly! seriously, this is an example of a healthy community at its best)
But personally I don't agree with the decision - it adds surprises when you try to convert times to other types and then compare things. Or convert to something else and then back to a time instance. I've watched things like this become the source of bugs many, many times - this will only make that worse, since now a "time" is two values but you can really only access one of them (the one that's equivalent to wall-clock, which is causing the problems). And they're particularly painful bugs, because the cause lies in implicit conversions and behavior. That seems to run counter to the "minimal surprises" that Go seems to prioritize.
Re: The State of Go
#125Earlier quoted context omitted.
Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…
Maps and folds are implicit loops. For some explicit is simpler.
No, maps are conversions between types containing other types. Maps are much more powerful than just doing something over an array in languages that support a functional style.
Re: The State of Go
#126I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…
I don't know. I feel like if I need something productive, I would go very high level like Python. In the VERY rare case Python is too slow, I would go really low level like rust. I don't see the interest for something that not really low level, but not realy high level either like Go. If concurrency is the main issue and is the niche I'm targeting, I would go Erlang or Elixir. I have a hard time finding any use case…
For me Go is the goto language for usecases where Python and Java were used. Python is great for tooling, and Java was the primary language for the backend.
So now, whenever i think about tooling or backend, Go is the primary answer, because its good in both paradigms.
The other languages i use is C++, and Swift, each one with their own niches. C++ for complex machinery, that requires more control and integration with other libs, and Swift for general applications, specially the ones that are user focused.
In my case, i cant find a niche for Rust. And thats because C++ is already covering that ground for me. I can see why i would use Rust instead of C++, but in the majority of cases where i use C++, there are huge complementary source code already in C++, making the effort to code everything in Rust from scratch, a complete nonsense.
So for me the language in "limbo" right now is Rust. (and i dont think that people with big C++ codebases would rewrite in Rust, because there's little advantage, at least compared to modern C++)
Re: The State of Go
#127Earlier quoted context omitted.
Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…
Maps and folds are implicit loops. For some explicit is simpler.
Maps are explicit transformations of data. For some, making the business logic explicit is simpler.
Re: The State of Go
#128The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…
Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/…
Clever? Sure.
Elegant? Hell, no. It's an ugly hack.
Re: The State of Go
#129Conversion rules seem like an awfully specific language feature to introduce just to scratch a very particular itch. The rest of the slides are pretty standard-fare, and that's a good thing. Would've liked a reference to the lack of monotonic time, though; either an acknowledgment that it's a problem (because it's now fairly widely known), or a mention that a new proposal to fix it [1] is in the works. [1] https://ne…
The conversion feature is in fact very convenient.
We often keep different types for what we get from the user (JSON) and what we write on the database (e.g: BSON). Having the ability to convert between them without having to re-type everything is useful for a lot of code out there.
Re: The State of Go
#130My impression is that Go is a language that was cobbled together to simplify the coding of some specific applications, such as simple servers. It lacks any kind of purity, is not the best choice for any specific task, but is just good enough for some (many?) tasks. And poor type safety! Frankly, I can't help being disappointed by how bland this language is, and I have zero interest in using it. Maybe because I like c…
I don't disagree about the type safety and general qualities of the language, but saying "Maybe because I like coding" is really unnecessary language egotism. There are many, many people who love coding and love doing it in Go.