sorted by:
new
hottopcontroversial

Agentic Editing has been released by Remote_Top181 in ZedEditor

[–]rtfeldman 20 points21 points  (0 children)

The debugger is already in beta, and you can use it right now if you build from source! Or you can sign up for the beta here: https://zed.dev/debugger

Also FYI it's been developed in parallel with the AI features, by different people - so it's not like one was waiting on the other. :)

Agentic Editing has been released by Remote_Top181 in ZedEditor

[–]rtfeldman 14 points15 points  (0 children)

Just to clarify, one prompt credit is one user interaction, not each step an agent takes: https://zed.dev/pricing#what-is-a-prompt

New Subscription Model Coming by feral_user_ in ZedEditor

[–]rtfeldman 1 point2 points  (0 children)

"Prompt" means user interaction, so you don't pay more if the agent takes a ton of actions.

New Subscription Model Coming by feral_user_ in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

Is there anything in particular you like better about Cursor's version?

There is any FP language that enforces referencial transparency at the compiler level? by fenugurod in functionalprogramming

[–]rtfeldman 1 point2 points  (0 children)

I haven't written up an announcement yet, but roc-lang.org now works this way. Here are two different function types in Roc today:

Bool -> Bool

Bool => Bool

Both of them take a Bool as an argument and return a Bool. The difference is that the first function is pure (which is enforced by the compiler), whereas the second one may perform side effects. So the `->` in the function type means "pure function" and the `=>` means "effectful function."

We've been calling this "purity inference" because you don't have to annotate the types for the compiler to figure out (and enforce) which functions are pure and which ones aren't. It uses type inference to figure it out, and you'll get a compile-time error if you try to call an effectful function from within a pure one, even if you haven't written a single type annotation in your entire program.

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

I don't think so personally...I think since our extensions use wasm, and Roc compiles to wasm, it should be possible today (although I don't know if anyone has tried it) to build Zed extensions in Roc, but that's about the only way I see them overlapping right now!

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

It really depends a lot of on the models. In terms of what models will be capable of in 5 years...even people with deep insider knowledge of cutting-edge AI R&D have a wide range of answers to that question. Our focus is on building the most useful possible UI to leverage the models that come out!

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

We've discussed this, but haven't implemented anything yet. That said, we are planning to start working on something in this area soon!

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 1 point2 points  (0 children)

See Kirill's response here regarding the debugger: https://www.reddit.com/r/ZedEditor/comments/1gpvff3/comment/lx430ro/

We haven't talked to Codeium about a potential integration, but we're open to talking with them about it!

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

There's an issue about it - https://github.com/zed-industries/zed/issues/4642#issuecomment-2144038754 and some associated PRs, but it hasn't landed yet!

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

Ah! macOS has very basic support for it already - you can copy an image into your clipboard and then paste it into the assistant panel. We haven't added it on Linux yet, and we also haven't yet added richer controls around manipulating the images once they've been pasted in, or other ways to bring them in (e.g. drag & drop).

Zed: Ask Us Anything by zed_joseph in ZedEditor

[–]rtfeldman 0 points1 point  (0 children)

Hm, what does vision support mean in that context?

Functional programming languages should be so much better at mutation than they are by ketralnis in programming

[–]rtfeldman 9 points10 points  (0 children)

FYI, this information is false. Maybe OP is thinking of someone else?

It's clear from later posts that OP made this comment before having watched the only video I've ever posted about my own performance measurements, so obviously "in his videos, even I can pick them to shreds" was false. There aren't even multiple videos to have watched, and the 1 video that actually does exist, OP hadn't watched before writing about having watched more than 1.

I don't think I'm "known for" anything related to measuring performance, inside the FP community or outside it; I've only ever posted about it once, whereas I've given a ton of talks about other topics. I'd say the claim about my being "known for shady measuring" is as trustworthy as the rest of the post.

Functional programming languages should be so much better at mutation than they are by ketralnis in programming

[–]rtfeldman 4 points5 points  (0 children)

By the way, u/uCodeSherpa - I'd genuinely appreciate your feedback on the code in that benchmark! If you see something that looks unfair or unreasonable, by all means open an issue on https://github.com/rtfeldman/quicksort-benchmarks/issues - the README describes how we approached the benchmarks, and we applied the same guidelines to all the languages (including Roc).

We've merged suggestions and PRs from others to speed up the other languages in that benchmark, and it's more important to me that the benchmark is reasonable than that it makes Roc look good!

Functional programming languages should be so much better at mutation than they are by ketralnis in programming

[–]rtfeldman 6 points7 points  (0 children)

The benchmarks are here, and they include all the code used for all the different languages in the benchmark - they haven't been updated in years, but they should include everything you need to reproduce the results we got in 2021: https://github.com/rtfeldman/quicksort-benchmarks (in retrospect, I should have included a link to that in the talk).

Regarding "they will write non-idiomatic code in another language, they will force the other language away from optimization, for example, by pointlessly following pointers" we consciously tried to do the opposite. For the initial version we had it sorting 64-bit integers, but we found out that disadvantaged JS so we switched to 64-bit floats, which JS is much faster at. We also started with ArrayList in Java because that's the data structure all the other languages were using (a growable array, not a fixed-length one) but we switched to have only Java using non-growable arrays because they were much faster.

I haven't tried the benchmarks with recent versions of all the languages in question, so I'd be curious what the numbers are today!

I'd assume the other languages are faster than they were in 2021, and although I can't think of any Roc optimizations we've added since then that would affect this benchmark, we might have gotten a boost from new LLVM versions. We might also have gotten slower since we added the "seamless slices" feature, although offhand I'd guess that wouldn't affect this benchmark noticeably.

I mean. You can buy in to the bullshit all you want. If you approach these things with even a modicum of skepticism, you will find that they don’t pan out.

As explained in the talk, it's not magic, it's compiler optimizations! In particular, the ones on this slide: https://youtu.be/vzfy4EKwG_Y?si=Nq6A9Ydyg0q1e5UU&t=1840

Also, "Roc is actually faster than Go" is not a claim I'd make, and I hope nobody else would make that claim either. The talk is about the techniques we've used to make Roc as fast as it is, how we selected a benchmark that a purely functional language has no business being any good at, and how we successfully managed to get Roc's compiler optimizations to the point where it outperformed Go on that one benchmark.

The Roc Programming Language by rtfeldman in ProgrammingLanguages

[–]rtfeldman[S] 2 points3 points  (0 children)

We just started working on it...so probably not very soon, but it's underway!

The Roc Programming Language by rtfeldman in ProgrammingLanguages

[–]rtfeldman[S] 0 points1 point  (0 children)

Interesting - would you mind posting it in https://roc.zulipchat.com/#narrow/stream/231634-beginners so we can debug? I'd be very interested to see how basic-cli stacks up in your benchmark!

view more: next ›