vendiddy

I don't think this is true.

The history of Elixir has its roots in Jose learning Erlang, loving the properties BEAM, but wanting a different language.

All of the principles of the BEAM still exist in Elixir. And a lot of the Elixir semantics come from Erlang, precisely because Jose studied Erlang and the BEAM.

I've come to expect that, every time I update and OS or app to a newer version, it's going to be slower and more bloated.

Why can't it be the opposite? Why can't I expect an update to run faster than the previous version?

I feel like they are a workaround to GUIs being slow and bloated Electron apps.

But I wish we'd just make fast GUIs instead of giving up and building TUIs instead.

My biggest complaint about ChatGPT is how slow their interface is when the conversations get log. This is surprising to me given that it's just rendering chats.

It's not enough to turn me off using it, but I do wish they prioritized improving their interface.

Giving the AI an actual programming language (functions + objects) genuinely does seem like a good alternative to the MCP mess we have right now.

Demented AIs running amock is just what we need in this day and age.

We've recently adopted Zig at a few systems at our company but I think maybe "cool" or "new" is the wrong metric?

I view Zig as a better C, though that might be subjective.

It is not yet ready but the master branch has an initial draft.

https://github.com/kaitai-io/kaitai_struct_compiler/commits/...

It would be premature to review now because there are some missing features and stuff that has to be cleaned up.

But I am interested in finding someone experienced in Zig to help the maintainer with a sanity check to make best practices are being followed. (Would be willing to pay for their time.)

If comptime is used, it would be minimal. This is because code-generation is being done anyway so that can be an explicit alternative to comptime. But we have considered using it in a few places to simplify the code-generation.

Just seeing this now.

The thinking was to minimize the the places where a secret could leak. So with an HTTP client, I would think at the lowest layer possible.

I don't think of it as a way to eliminate secrets leaking. More-so reducing the surface area of accidental leaks.

It's not C but we have sponsored a Zig target for Kaitai. If anyone reading this knows Zig well, please comment because would love to get a code review of the generated code!

Not an answer, but I do wish there was a low level primitive and a corresponding high level language construct to pass around secrets.

Something like: my_secret = create_secret(value)

Then ideally it's an opaque value from that point on

I think this is spot on. A document metaphor would have made a Wave a lot easier to understand.

If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right?

Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same?

Sometimes optimizing for "easy to understand and change" means breaking something apart. Sometimes it means combining things. I've read that John Carmack would frequently inline functions because it was too hard to follow.

So, rather than whether something is big or too small, I would ask whether it would be easy to understand/change when coming back to it after a few months.

Put another way: why not optimize for the actual thing you care about rather than an intermediate metric like LOC?

I think it's a valid question, but it's better to assume they had their reasons and try to understand why before drawing conclusions.

And even if you fall under the first category, I find it hard to believe that the performance bottleneck is solved by using Vercel and SSR.

With all the other crazy shit people are doing (multi-megabyte bundle sizes, slow API calls with dozens of round-trips to the DB, etc) doing the basics of profiling, optimizing, simplifying seems like it'd get you much further than changing to a more complex architecture.

how about "NotExpert"

Yes we have. I don't know why you got so much pushback.

Right now innovation moves at a slow pace the web nobody seems to realize the what-if. The W3C announces some incremental improvement to JS feature and everyone gets excited. It just reminds me that all we realistically have is JS.

There are so many hacks on top of hacks. Typescript compiles to JS because, well, you only have JS. So many attempts at compile-to-JS languages. There are dozens of problems that should not exist.

Meanwhile in the native world, you have huge a diversity of programming languages and tooling. No committee is needed for each language to experiment with new features.

The unfortunate part is that the envisioned browser would have been far simpler to implement and more extensible than the mess we have now.

I find if I read the source code of a dependency I might add,

it's common that the part that I actually need is like 100 LOC rather than 1500 LOC.

Please keep preaching.

And if you really do? Print the percentage to stdout.

I generally love AI.

But I lament these blurred lines of reality. Is this photo real? Was this reply ChatGPT or did they actually write it?

It makes me feel uneasy.

I can't remember who I read this from (it might have been Alan Kay) but they basically said the web browser should have been an address bar with the ability to run any sandboxed applications in the screen below. They said the internet well designed but the browser was a disaster.

So hyperlinks were good but the rest was a bad design. An HTML viewer and Javascript interpreter would have just been one possible app to run in the browser.

It is a shame that, to this day, the browser can't easily handle running arbitrary applications. You're still effectively locked into JS/HTML.

I customized the hell out of my keybindings. I might be in the minority though! I was trying to give examples of (stupid) little points of friction that might prevent someone from taking the leap.

The vision sounds interesting but I think if they have two challenges they will need to overcome to compete in the IDE space

1) Their LLM integration needs to be at the quality of Cursor and VSCode to pull people away from those

2) Reduced friction to move over (keyboard shortcuts, common plugins, etc)

I think the Zed team is perfectly capable of winning. The bigger risk would be them trying to tackle fancy stuff before making sure the basics are good enough to get developers to switch.

They need to build up a deep understanding of why folks are sticking to Cursor/VSCode and not swapping over.

P.S. I would love for Zed to win in the market because I'm sick of slow software and it's refreshing to finally see an intense focus on performance.

I don't think it is because it just requires that you write frontmatter in YAML which is pretty human readable and common in certain markdown formats.

Your notes are still in markdown.

But exactly. The one thing you care about in a gym app is getting into the gym!

If get a chance to read some Elixir/Erlang code you'll see that pattern matching is used frequently to assert expected error codes. It does not mean ignore errors.

This is a common misunderstanding because unfortunately the slogan is frequently misinterpreted.

I think the slogan was meant to be provocative but unfortunately it has been misinterpreted more often than not.

For example, imagine you're working with a 3rd party API and, according to the documentation, it is supposed to return responses in a certain format. What if suddenly that API stops working? Or what if the format changes?

You could write code to handle that "what if" scenario, but then trying to handle every hypothetical your code becomes bloated, more complicated, and hard to understand.

So in these cases, you accept that the system will crash. But to ensure reliability, you don't want to bring down the whole system. So there are primitives that let you control the blast radius of the crash if something unexpected happens.

Let it crash does not mean you skip validating user input. Those are issues that you expect to happen. You handle those just as you would in any programming language.

It is but requires discipline.

I've been coding for 15 years but I find I'm able to learn new languages and concepts faster by asking questions to ChatGPT.

It takes discipline. I have to turn off cursor tab when doing coding exercises. I have to take the time to ask questions and follow-up questions.

But yes I worry it's too easy to use AI as a crutch

sounds like legacy code

This is exactly what I want!

This will also allow the wider community to innovate rather than waiting on standards bodies to decide what the think is best.