131–140 of 158 posts
I know there's only so many names in the world but this is going to completely ruin searches for the Unison file synchronizer: https://github.com/bcpierce00/unison
I'm old enough that I thought this was related to the old mainframe/UNIX company from the 90s!
Forgive me the heresy, but when I look at this example: helloWorld.deploy : '{IO, Exception} () helloWorld.deploy = Cloud.main do h = sketchy underlinedeployHttp ! Environment.default helloWorld ServiceName.assign (ServiceName.create "hello-world") h Then how am I not just swapping YAML gobbledygook for Unison gobbledygook here..? I understand the general idea of expanding the scope of programmable code onto the infr…
Whatever gobbledygook you’re writing to specify how your system works, a programming language is better than a markup file.
I know there's only so many names in the world but this is going to completely ruin searches for the Unison file synchronizer: https://github.com/bcpierce00/unison
Earlier quoted context omitted.
Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc. You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application. Maybe I'm misinterpreting your…
> you reap the benefits of type-safety, testability, and code reuse, etc. If you treat infrastructure as a problem that has to be solved by code, obviously you'll run into code specific issues like type safety. In the real world I've never root caused a production issue back to that.
Your definition of type safety might not include validation + using the type to carry proof of that validation throughout the life of the program.
For examples see:
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
I strongly dislike marketing material that tries to normalize gross incompetency around complexity problems that don't actually exist.
Earlier quoted context omitted.
It definitely is ambitious! A multi-year effort. This post https://www.unison.cloud/our-approach/ talks more about why such radical changes were necessary to achieve what we wanted. (In particular check out the "3 requirements of the dream" section, which walks through what the programming language needs to support to be able to do things like "deploy with a function call.") My general take on "when and where to inno…
Not trying to pour cold water, but the "3 requirements" post seems to address straw man problems. There are existing solutions to each problem. 1. "Deployment should be like calling a function" isn't that the mantra of serverless? e.g. GCP Cloud Run or AWS Lambda? This is also becoming much more streamlined with server-side WASM e.g. wasmCloud. 2. "Calling services should be easy" this is what protobuf is for; cross-…
It is true that tech exists that try to make all 3 of those items easier. YMMV, but having used these technologies myself and now having used Unison + Unison Cloud, all I can say is that the Unison experience is quite different overall.
The details matter. A bicycle and a motorcycle share some common principles but that doesn't mean they're "about the same". The fine details of execution and polish can matter too: Slack is different than IRC, Dropbox was different than the million other backup services. Also, bringing a number of things in a cohesive way can lead to big improvements in the experience when it's done well.
Getting into specifics a bit, I don't think deployment with a function call is well handled by existing technologies, because of the reasons discussed in the post. In the absence of Unison's features, there is inevitably some sort of out-of-band packaging step or "setting up the environment with the right dependencies" as a precondition, instead of calling a function and having it Just Work.
Re: RPC, Unison remote calls can pass around arbitrary values, including functions and values containing functions. This Just Works. There's also no generated code which needs to be somehow integrated into your build and no boilerplate converting from the "wire format" objects to your actual domain objects you want to work with.
My experience with ORMs is they are overly opinionated / magical and provide insufficient control for many projects. So every project I've worked on ends up not using ORMs in favor of a layer of boilerplate for talking to the storage layer... which still can't store functions or even sum types properly! And it's not typechecked, either. Using our cloud's storage, I get to use whatever data structures I want, can write my own easily if needed, and I can store any value at all including functions and again it Just Works. And access is typechecked. It's pretty great!
When you put all these things together in a single cohesive programming environment, with a common type system and language, uniform composition, a set of tools all meant to work well together, you really start to see how different it is! It already feels like a huge step up, and will only keep getting better and better as we build out Unison and our cloud platform.
All that said, I'm kind of doubtful that abstract arguments like this will be convincing. Instead, I'd just try Unison out for a low-risk project and decide for yourself if the details are making a big difference for you.
Hope that is helpful! :) If you do decide to play around with it, feel free to come by the Discord https://unison-lang.org/discord to get help, ask silly questions, etc. We are here to help and it's a nice community.
Earlier quoted context omitted.
Hi, one of the Unison creators here. We've talked about adding pluggable syntax[1]. It's in principle straightforward (the code is already stored in a database as its abstract syntax tree, not text) and I imagine a future version of Unison could let you pick from a variety of syntaxes. But we haven't gotten to it yet. [1] https://github.com/unisonweb/unison/issues/499 ... that said, the language semantics and librari…
I think you guys are a self-selected bunch of very smart people, also unafraid to break ground and try something new - so you may underestimate how much a familiar syntax means to us plebs. For instance, Erlang always intrigued me, but Elixir (familiar syntax but with Erlang semantics for those who don't know) was what made me really consider the Erlang ecosystem.
Forgive me the heresy, but when I look at this example: helloWorld.deploy : '{IO, Exception} () helloWorld.deploy = Cloud.main do h = sketchy underlinedeployHttp ! Environment.default helloWorld ServiceName.assign (ServiceName.create "hello-world") h Then how am I not just swapping YAML gobbledygook for Unison gobbledygook here..? I understand the general idea of expanding the scope of programmable code onto the infr…
Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc. You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application. Maybe I'm misinterpreting your…
That's probably a bit too philosophical and nothing a company should have to worry about. Again, I think you're doing great work here, I'm just unsure whether this is the best solution for the overarching problem.