> Go – very little hidden, everything in text on the page, LLMs are great. Java, similar. But writing Haskell, it's pretty bad, Erlang, not wonderful. You need much more of a mental model for those languages.
I don't think that follows. It could just be that there is way more Go and Java code to train on than Haskell and Erlang. Haskell's terseness and symbol-named operators probably don't help either.
They don't. Paragraph 4.2, "Customer's Ownership of Output" [0]. I recite verbatim below for the sake of clarity.
These are about processing the data, not owning it. They need to process the data eg to provide llm-based tab-completion. A completion is derivative work, and it is also owned by the customer, as it says below.
> The Service may generate specifically for, and make available to, Customer text and written content based on or in response to Customer Data input into the Service (collectively, “Output”), including through the use of technologies that incorporate or rely upon artificial intelligence, machine learning techniques, and other similar technology and features. As between the Parties, to the greatest extent permitted by applicable Laws, Customer owns all Output and Zed hereby irrevocably assigns to Customer all right, title, and interest in and to the Output that Zed may possess. For the avoidance of doubt, Zed and its AI Providers will not retain or use Customer Data for the purpose of improving or training the Service or any AI Provider products, except to the extent Customer explicitly opts-in on Zed’s specific feature to allow training and/or such improvement (such as fine-tuning) and is solely for the benefit of Customer.
Pull requests are a core feature of git, the protocol, so I think you probably mean certain PR features more than just PRs.
Issue trackers can be self-hosted from fully mature applications via docker images. You might find something here: https://selfh.st/apps/
CI is typically actioned from a configuration file in your repository to a CI SAAS solution, which could be anything. Travis CI was popular for a long time. When I was big into CI SAAS my favorite was Semaphore CI.
> Radicle is an open source, peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow. - https://radicle.dev/
There seems to be no way to get this kind of information from the radicle.network link in this article. Clicking the logo in the top left takes you to a page that just says "A public node run by the Radicle team", which is totally uninformative.
I think one of the biggest constraints is not directly visible to users, but its effects are: HN is built in Arc, a small LISP dialect that for a long time didn't have great performance. Some info here: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...
Accelerometer, by putting the two phones together and shaking (some app used to do this, but I can't find it with a quick search). Edit: I might have been thinking of Bump, mentioned downthread, though it's a different physical mechanism: https://en.wikipedia.org/wiki/Bump_(application)
Camera, and point it at their changing screen (or both at the same scene at the same moment). Not too intrusive.
GPS, but that would require location permission. Intrusive.
Audio, but that would require allowing microphone. Intrusive.
slightly OT but the technology behind Bump was genuinely mindblowing at the time. Phones didn't have NFC or anything like that, and they didn't use much accuracy in the way of location data, so they basically just had a general "city block" location, timestamp, and accelerometer readings and would invert the accelerometer reading and look for identical accel + timestamp.
We tested it one time with like 10 phones and everyone bumping each other / the wall as a control, in the same room and it nailed every actual pairing and ignored the others. The wiki has more, but lacks the subjective experience of how magic it was.
Why not? People were not far from it and have been getting closer and closer to it for years. To me it seemed almost certain that it would happen this decade or next.
I don't think that follows. It could just be that there is way more Go and Java code to train on than Haskell and Erlang. Haskell's terseness and symbol-named operators probably don't help either.
reply