I am going to look at Zig after 1.0 is released. The current state is that you are playing catch up with language if you have any reasonable sized project in Zig. A new release might mean that you need to rewrite significant portion of your code.
Functional programmers need to take a look at Zig
101–110 of 163 posts
Re: Functional programmers need to take a look at Zig
#102I am still hearing about Monads, but is it not the case that they have well-known flaws? And that is the reason why algebraic effects are interesting, because they don't have these flaws?
Re: Functional programmers need to take a look at Zig
#103I am still hearing about Monads, but is it not the case that they have well-known flaws? And that is the reason why algebraic effects are interesting, because they don't have these flaws?
Monads are a math/organization pattern. What flaws do you mean?
Re: Functional programmers need to take a look at Zig
#104These days I just use a few languages: 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless. 2. Haskell, I use it for DSL and state machines. 3. Bash for all deployment scripts and everything. 4. TypeScript, well for the frontend. Lately, I’ve been using G…
Well, Java would compile and work for 3 decades straight. If anything, go did have an actual breaking language change (for loop variable capture)
Re: Functional programmers need to take a look at Zig
#105Earlier quoted context omitted.
Why did you give up on Java and Rust?
Java is a resource hog when you use patterns and libraries popular in Java land. When you are working in the Java ecosystem, you just assume that this much resource is needed by the app! But when you'll code the same thing in Go using the same methods, you'll find resource usage is really very low. We’ve a 1: 1 copy of the app; on JVM, it's using 2GB RAM using Spring Boot, and on Go, it runs on 512MB RAM and is blazi…
You are comparing a (the most?) featureful web framework to a vanilla http server.. of course one will be significantly more resource heavy.
Re: Functional programmers need to take a look at Zig
#106Earlier quoted context omitted.
Java is a resource hog when you use patterns and libraries popular in Java land. When you are working in the Java ecosystem, you just assume that this much resource is needed by the app! But when you'll code the same thing in Go using the same methods, you'll find resource usage is really very low. We’ve a 1: 1 copy of the app; on JVM, it's using 2GB RAM using Spring Boot, and on Go, it runs on 512MB RAM and is blazi…
I'm not sure the effort part makes sense now that we have LLMs? LLMs basically liberate language choice, which has made Rust incredibly attractive to me since I basically get good performance out of the box, while any possibly annoying pedantic obsession with correctness can be easily handed over to the LLM. If I use a JVM language, running my test suite takes 10 to 30 seconds. With Rust it spends 3 seconds compiling…
> If I use a JVM language, running my test suite takes 10
Sounds like a bad build tool.
Re: Functional programmers need to take a look at Zig
#107Earlier quoted context omitted.
I cant really agree on Rust. It does take a bit more time to write the same code in rust vs go. But in my experience the code is much more likely to be incorrect in go than it is in rust. Which over longer periods means rust is easier to maintain.
On the other hand, most pieces of software in this world are kind of mediocre code written by unmotivated employees within tight timelines. In such context, I think Go might be a better or at least, more realistic, compromise in most cases.
If you have unmotivated employees then using Go will only exacerbate the shortcomings it has. Cutting corners is much easier in Go than it is in Rust. But in general it's true, if you want a piece of code released a bit faster but spend more in developer hours maintaining it later than Go is the better fit. And there are definitely use cases for that.
Re: Functional programmers need to take a look at Zig
#108These days I just use a few languages: 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless. 2. Haskell, I use it for DSL and state machines. 3. Bash for all deployment scripts and everything. 4. TypeScript, well for the frontend. Lately, I’ve been using G…
Well, Java would compile and work for 3 decades straight. If anything, go did have an actual breaking language change (for loop variable capture)
Note that Java makes breaking changes all the time, which is why it publishes a compatibility guide with each major release. These are usually judged to be minor breakages, but if you have a codebase on the order of millions of lines, there's a very good chance that at least one thing will break and require a little bit of work to upgrade. And Java's not unique here, every stable language makes changes all the time that have the potential to break some user in some edge case.
Re: Functional programmers need to take a look at Zig
#109These days I just use a few languages: 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless. 2. Haskell, I use it for DSL and state machines. 3. Bash for all deployment scripts and everything. 4. TypeScript, well for the frontend. Lately, I’ve been using G…
> 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless.
And fewer dependencies, and fewer vulnerabilities (if any at all, depending on your few dependencies).
Go is "only" a pain when you want to use your own copy of packages (because `replace` directives are always ignored everywhere except on the "root" package), and whenever you want to work with private Git repositories outside of the forges that have hardcoded config in the Go code (like GitHub) (because Go assumes there's an HTTPS server, and the only way to force it to use only SSH is with ugly workarounds AFAIK).
But despite this I still prefer it for personal projects because I can come back after not touching it for years, and the most I need to do is maybe update `golang.org/x/net` or something like that.
Re: Functional programmers need to take a look at Zig
#110Earlier quoted context omitted.
i dont think its generally a good idea to be making complex type generators like this in zig. just write the type out. the annoyingness of the thing you tried to do in zig is a feature. its a "don't do this, you will confuse the reader" signal. as for optional, its a pattern that is so common that it's worth having builtin optimizations, for example @sizeOf(*T) == @sizeOf(usize) but @sizeOf(?*T) != @sizeOf(?usize). i…
> if optional were a general sum type you wouldn't be able to make these optimizations easily without extra information Rust has these optimizations (called "niche optimizations") for all sum types. If a type has any unused or invalid bit patterns, then those can be used for enum discriminants, e.g.: - References cannot be null, so the zero value is a niche - References must be aligned properly for the target type, s…
Yes, the care that Rust goes through to ensure that niches work properly, especially when composing arbitrary types from arbitrary sources, shows why you absolutely don't want to be implementing these optimizations by hand.