Live data from Hacker News

Zig is hard but worth it

ratfactor.com

291–300 of 307 posts

Re: Zig is hard but worth it

#291
post #243

Earlier quoted context omitted.

When Python was originally designed disk space was precious, and access to the Internet was rare, and its dependency management was designed for that world. Its multiple retrofitted package managers never fully fixed it. However, better integrated package managers can work well. In case of Node.js and Cargo, the main argument against them is that it's too easy to add dependencies.

Fundamentally the problem with python is that it's packages are global and every workaround except ~docker can't fix it except in a hacky way since the package resolution is specified in the language

Tell us more, cause it’s not a problem I know

Re: Zig is hard but worth it

#292
post #55

Earlier quoted context omitted.

I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.) The more peripher…

So you manually do what a package manager would do automagically and better. What do you think you are doing that is better than a program resolving dependencies, downloading h them and building them, putting them in the right location and tracking the versions used in a lock file

Re: Zig is hard but worth it

#293

Earlier quoted context omitted.

Fundamentally the problem with python is that it's packages are global and every workaround except ~docker can't fix it except in a hacky way since the package resolution is specified in the language

Tell us more, cause it’s not a problem I know

Try installing two pieces of software that depend on two different versions of tensorflow, then come back here.

Re: Zig is hard but worth it

#294
post #244

Earlier quoted context omitted.

I want to invest in Odin but I see the velocity and growing mindshare that Zig has and I wonder if it's not better to settle for that. Also how do you find the compile times?

Part of "mindshare" are organizations pushing it on social media and marketing. Choose the language that solves your problems and that you like. Don't make a choice because a group is telling you what to like, is bullying others because they like something different, or are trying to shove something down your throat for their profit or benefit. Perfectly fine to have an independent mind, and make decisions best for y…

Yes I definitely agree with that sentiment. Some things unfortunately happen faster with community support. Platform integrations, toolchains etc that require a lot of busywork. But I think I'll cautiously move with Odin regardless as I like how it's designed. Probably will end up learning both.

Re: Zig is hard but worth it

#295
post #244

Earlier quoted context omitted.

Part of "mindshare" are organizations pushing it on social media and marketing. Choose the language that solves your problems and that you like. Don't make a choice because a group is telling you what to like, is bullying others because they like something different, or are trying to shove something down your throat for their profit or benefit. Perfectly fine to have an independent mind, and make decisions best for y…

Yes I definitely agree with that sentiment. Some things unfortunately happen faster with community support. Platform integrations, toolchains etc that require a lot of busywork. But I think I'll cautiously move with Odin regardless as I like how it's designed. Probably will end up learning both.

I think this is a great idea. I would suggest joining the Discord server if you want to talk to like-minded people and immerse yourself in the language: https://odin-lang.org/community/discord/

Re: Zig is hard but worth it

#296

Earlier quoted context omitted.

Tell us more, cause it’s not a problem I know

Try installing two pieces of software that depend on two different versions of tensorflow, then come back here.

I can install multiple python interpreters side by side each with independent packages and I can install different versions of the same python package for the same interpreter. I haven’t tried or had a need, by induction sounds possible :shrug:

Re: Zig is hard but worth it

#297
post #94

Earlier quoted context omitted.

> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected…

Makes me so sad that I can't just code up a parser and have a useable language. I have a lot of ideas, but heck, just syntax highlighting is... I don't know where to begin. And auto-completions. I need a tool that does 90% of that like PegJS or other parser-generators do for the parsing part. Don't see why a parser-generator can't also spit out an LSP. And if it knows what tokens are valid next, it should be able to…

Because LSP is not just "give me some semi-decent completions based on parsing tokens in this file". Proper LSP will treat code semantically, in case of e.g. Rust it may complete a method name from a trait method because you have the trait somewhere in scope, which comes from a third-party package which the LSP also parses, where it needs to expand some procedural macros to get to source code, etc etc.

We've been spoiled by good LSPs, perhaps. But again, it's not just "parse this file please".

Re: Zig is hard but worth it

#298

Earlier quoted context omitted.

Have you tried bevy? I’m starting with bevy for a non-game project, but I’m blown away by how simple it is to use once you get used to the magic.

Bevy isn't on the same level as tools like UE and Godot.

Zig gamedev libraries aren't either

Re: Zig is hard but worth it

#299
post #22

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack o…

In my case, Zig was super-simple to pickup, I've been using rust for few years so I was already in the systems programming (as a hobby), and I also had to read some C/C++ during that time, that probably helped me too.

Other than that, I was and I am, mostly a frontend developer with ECMAScript and TypeScript experience. I think Zig is very close to both, because Zig has anytype, so you can do duck-typing like you do in JS, and it has programmable type system, just like TS. Not to mention that reflection is basically your daily bread in JS/TS.

TLDR: If you have some systems programming experience and you've done a bit of TS, I'd definitely recommend you to give Zig a try. One weekend should be enough. I did that literally single-handed, as I was recovering after wrist surgery.

Re: Zig is hard but worth it

#300
post #195

Earlier quoted context omitted.

Honest question here (that I have every time I see someone talk about memory safety in 2023), are you aware of Ada/Spark?

If Ada and Spark solve problems as well or better than Rust and have been around for longer, why have I never seen any program written in them? I don’t know anything about ada/spark but it seems clear that something has gone terribly wrong for them to not have taken off like Rust has.

That doesn't answer my question.

To attempt to answer your question, you might be surprised to learn just how much Ada/spark exists in the world if you go looking. Most of it is not open source. I'm not sure they haven't "taken off like Rust has" because Rust is still very niche, kinda like Ada is

Post reply on HN