|
Clojure implements efficient persistent data structures as part of the language so clearly they should have used Clojure. 
|
#
¿
Aug 20, 2015 23:18
|
|
|
|
| # ¿ May 4, 2024 09:18 |
|
|
I kinda like Go as a language too, but I think the problem is that its applications are primarily lower-level and specialized - as people have said, it seems to do a specific few things:
It's not a surprise that Docker, Kubernetes, and Hashicorp stuff are written in Go - they're very low-level, systems-oriented solutions for things the grand majority of programmers and engineers take for granted and never have to think about. Way I see it, if what you're doing is relatively independent of platform, complicated enough to be handled by a framework like Rails or Phoenix, noticeably benefits from functional programming, has anything to do with game dev, or is particularly high-level in concept, it's not really a Go thing. Basically, Go is an ops language. Dangerllama posted:It's still a pretty niche language by overall usage, even though it seems like literally everything new and awesome is being written in it: Docker, Kubernetes, Prometheus, pretty much everything in the Hashicorp stack now. I'd argue that the reason Go is niche yet a bunch of cool stuff is made in it is because 1. these are solutions to real and difficult problems, 2. Go is specifically designed around enabling these solutions, and 3. these solutions are widely used and very much the backbone of the systems we use. These solutions are niche because not many people work in it yet heavily rely on what's written with it, and not many people work in it because the problems it is specialized in solving are really advanced and really hard. There's a reason it's Google's baby. Pollyanna fucked around with this message at 16:16 on Oct 18, 2016 |
|
#
¿
Oct 18, 2016 16:09
|
|
|
This may or may not be the best place to ask, but: We have a protobuf defined that represents a particular set of data, most of it nested. We want to expose filters based on that data, such that given a particular protobuf instance you know you can say “I want to filter on this message’s value between X and Y” or “I want to filter on this enum being of either value Foo or value Bar, and allow any others”. We currently have to define these filters manually by being aware of these data “leaves” and what type they are, and manually changing what our filters do and allow based on that. What I’m wondering is, is there a way to list all data leaves and their type so we can programmatically filter on them? I’m hoping there’s a way to know when a protobuf message has a new age value and thereby programmatically generate a filter on that new value, without having to manually do so. Is this something a protobuf can do? If it helps, we are using the Ruby implementation of gRPC and protobufs.
|
|
#
¿
Sep 7, 2018 15:48
|
|
|
I was hoping the Ruby gem or something intrinsic about protobufs would allow them to know about their own data leaves, but I don’t see any helper methods or anything for that. As it is, it will be impossible to programmatically list the specific stuff I want since it will also be accompanied by a bunch of irrelevant constants and members that aren’t what I want to filter on. That said, I just dug into the Descriptor API, and I think I got what I need. Thanks!
|
|
#
¿
Sep 7, 2018 16:57
|
|
|
How are you expected to keep protobuf definitions and compiled files up to date? Just constantly ping a GitHub repo until the file changes or something? That sounds dangerous.
|
|
#
¿
Sep 13, 2018 14:36
|
|
|
|
| # ¿ May 4, 2024 09:18 |
|
|
Jabor posted:That's the best part about protobufs - if you do them right, you don't have to. As long as your protobuf only changes in particular ways, servers and clients can keep using the definitions they were originally compiled with and continue to work correctly, even when the thing they're talking to is using updated definitions. We have some enums (a list of insurance agencies) that get updated with new entries e.g. a new “FooGroup Inc.” with id 180. Our old protobuf does not have that entry, so it can’t map 180 to the symbol “FooGroup Inc.”, and therefore bugs out because our “hey we can’t translate this symbol to a display string” exception handler logs “can’t translate symbol 180” instead of “can’t translate symbol FooGroup Inc.”. We need to know it’s symbol instead of just an integer so we know what entry we need to add to our translation dictionary.
|
|
#
¿
Sep 13, 2018 15:35
|
|