For now, I use either GitPod or GitHub CodeSpaces. No need to install anything on the laptop, although VS Code, when using CodeSpaces as its remote, sometimes does something that makes my laptop ask if I want to install the xcode command line utilities. I suspect it’s doing something git-related. For now I simply refuse and see no consequence in doing that. :D Both can be used with a local VS Code and Calva without issues (I didn’t work on big projects in this context, though).

Not heard of it before but notice it does not mention clojure as a supported language else I may have given it a try

Nix does have packages for clojure, but yeah, Devbox might yet be in need of a template to whip up a quick example project.

We use devenv, which is similar.

I’ve used nix directly, and also flox - which is similar to devbox. looking at devbox. it seems to have the same underpinnings, but with a different configuration language. Any machine you install it on will have the packages on the disk, but like other Nix uses, will alter the PATH based on the configuration present (I conjecture)

My experience with nix-based dev environment management is that: • package freshness can be an issue, if you are always trying to stay fully up to date from the main repo • per-directory reproduceable environments work very well • It can eat a lot of disk space if you don’t garbage collect often

Thanks - looks like https://devenv.sh/ might indeed be, or become, as good or better as devbox. It does look like these tools can be a worthy, lighter-weight alternative to running a docker dev container locally (or composing a set of docker container services). OTOH if one already deploys prod as docker containers, one might have a Dev-Prod parity argument against using these nix tools (unless they decide to use more generic docker containers, and configure them using these nix tools). Back to DevBox… comparing Devenv, the latter seems more open and more powerful. Do what you want as you learn Nix.

Note also that with devenv you can (in theory, though I haven’t been able to get it to work) deploy using containers.

> There's limited space available in your Dropbox. So, it's not infinite? Darn you, laws of physics!

Google drive has the same logic. It only regards percentage and not free space.

the best answer is always: do what https://www.eclipse.org/legal/epl-v10.html says, particularly section 3 Requirements

Wow, just read section 3, (thanks). Not a lawyer, but that section suggests that if you have commercial software, you can't offer product source code under contract without explicitly making the code itself EPL, if it contains EPL code.

I was thinking more in practical terms of adding headers to files. Do I ust list the name of previous author and my name?

@U077BEWNQ "When the Program is made available in source code form: a) it must be made available under this Agreement; and"

But perhaps additions to, or linking of The Program in a wider context doesn't make those additions or surrounds part of The Program. Still I don't like the ambiguity of it... of course I've only skimmed it and not read it from top to bottom (that wouldn't be any fun 😉 ). These things are settled by case law in a common law system.

> But perhaps additions to, or linking of The Program in a wider context doesn’t make those additions or surrounds part of The Program. That’s how I read it. Especially given 1.b.ii: “Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.” (my guess is that @U66G3SGP5’s modification of the EPL code would count as a contribution, though, since it’s derivative, but I assume the intention is to EPL that anyway? & that’s different from the case you’re talking about.) (also not to harp on this but I make no claim to be good at understanding these licenses, I’m just tossing out my own reading of it)

yeah I just wanna copy paste some code into my library that is also EPL

or MIT

and I don’t want to run into any legal issues

It performs well for sending a large amount of data over the wire

one way is because property names are not needed for each "object" of data. COBOL is back! Seriously though, it's not a bad idea for the above use case

I see people using it instead of JSON just “because types”.

Yeah, types give you faster [de]serialization,

Yeah, that's too bad. We used gRPC with Clojure. I think we had some fancy parser of the protobuf, but each "object" was transformed to a map

we just transformed the Java object to a Clojure map

I started using it a few months ago. I initially felt the same towards grpc. Slowly I've started appreciating it for what it is while all the while increasingly disliking the choice to use it by the thing that I'm learning it for in the first place [cosmos-sdk a blockchain library but that's a whole other can of worms].

There's some decent clojure libary options in case you're not familiar https://github.com/AppsFlyer/pronto (I've mainly used this) https://github.com/s-expresso/clojobuf (this one's pretty new but I like the interface it exposes a lot)

Are either of you using it with Clojure? @UEQDV142J @U064UGEUQ

Yeah all clojure for me

I've had to use it, and haven't enjoyed it at all. I have been using Protojure, which works nicely, but I can't shake the feeling that gRPC is not really "idiomatic" (and the dev process is not REPL-friendly, and values are opaque, etc.). Plus, the .proto file syntax seems weirdly limited

Let's separate grpc and protocol buffers Protocol buffers suck because of design and ergonomics. It does both schema description and serialization poorly. It's also not machine readable grpc sucks because of architecture - you just recreate distributed inconsistent objects It's just a poor idea all around made to solve Google's problems

It's been a while since I've used gRPC. I'll take your word for it on this: > schema description and serialization poorly but I don't know what you mean by this: > recreate distributed inconsistent objects

Not that I disagree, I'm just not following.

I had bad experiences with both protobuf and grpc in Clojure, though part of that might’ve been how it was rolled out at the company I worked for. It was unergonomic and really didn’t add much value, we didn’t need the performance. If all you’re looking for something to help you manage rpc schemas and backwards compatibility, I recommend looking elsewhere (in Clojure at least).

There are dozens of serialization formats but all people are talking about are JSON and Protocol Buffers

Could you elaborate on that? @UK0810AQ2

I just started using it for a project that has a C# component and a Clojure component and I've been pleasantly surprised by the experience. Using pronto on the Clojure side, works well and seems ergonomic to me. That said it has only been a few weeks, so I may be missing something. I was looking to use this first, but only a couple of languages are well supported: https://capnproto.org/

ISTM that gRPC/protobuf is a solution to the problem of devs not wanting to collaborate with each other. The protobuf design enforces design-by-contract -- there is no mercy for not following the spec. The binary format is good for transmission efficiency, but poor for troubleshooting. I tend to start with JSON schema first, then move to something like protobuf for optimization purposes.

Forgot to say, but I would never even consider gRPC if it was clojure-to-clojure communication, that seems crazy to me. I think it only might start to make sense when: 1. perf is very important 2. you have multiple language ecosystems to deal with

As a rule of thumb, I think of any tech coming out of Big Tech as "not for me", because they tend to be borne of problems that they face at their scale. Whatever design / operational / performance, and importantly, organisational tradeoffs those techs represent are likely not going to make sense in my context, which is almost invariably small companies.

Specific to gRPC, it says this on the tin... > gRPC (gRPC Remote Procedure Calls[2]) is a cross-platform open source high performance remote procedure call (RPC) framework. gRPC was initially created by Google, which used a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across its data centers from about 2001. cf. https://en.wikipedia.org/wiki/GRPC