7 ms·

Considering that Rust exists, I really don't hope that Zig gets much adoption, at least until the language improves a lot in some key aspects. There definitely

Considering that Rust exists, I really don't hope that Zig gets much adoption, at least until the language improves a lot in some key aspects. There definitely is a design space for a simpler language than Rust that is easier to write, but Zig is too far on the side of C and has lots of trivially introducable unsafety. It's an improvement over C , but imo not enough.

fwsgonzo 6y ago
One thing I noticed is that Zig is not 1.0 yet, so perhaps it will still improve in those aspects you are thinking about?
1_player 6y ago
Rust instead is too far on the side of C++ I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. In some niches Rust is perfect, but in every language thread on HN there's often someone that suggests to use Rust whatever the use case. C, in that respect, is more flexible and gets out of the way much more, of course while being unsafer, but it's easier to keep your mind on the goal and not figuring out the best memory safe approach for this piece of logic. Which is why I'm very excited for Zig. I don't want another C++. Give me safer C, thanks.
- adrianN 6y ago
  In C you also have to think about lifetimes and types, only that the compiler is helping you a lot less to get things right.
  - 1_player 6y ago
    Of course, but you don't need a lot of work to make the C compiler happy. The result might not be 100% safe, secure and mathematically proven, but sometimes you need to deliver, fast, not create the safest 1k lines of code on Earth. To be honest I haven't used C in a long time, but I've been looking for a low level language that sparks as much joy as C does. Go, Rust ain't it, IMO.
  - flukus 6y ago
    In C you have to think about lifetimes (and to a lesser extent types) at specific times, typically after the "make it work" step of writing code. Rust on the other hand forces you to think of these things from the start and this inhibits solving the actual problem first. Now there's an argument the front loading these decisions may be beneficial overall but I don't find that compelling either. After the "make it work" stage there's thinking about performance, comments, logging, etc and you usually need to think about lifetimes as they change at this point as well, so front loading it has only added work overall.
    - tene 6y ago
      This description doesn't match my experience of writing Rust at all. During the exploratory phase of my projects, I very rarely run into nontrivial lifetime issues, and when I do, I can just put whatever data into an Arc and then it just works. Most of my exploratory code is just objects that own their data. Later in a project, while doing a bunch of refactoring to handle performance, logging, etc. , I have a much easier time letting the compiler tell me when I've made mistakes with a value's lifetime rather than trying to keep the whole program in my head for the duration of the refactor. I don't spend a lot of time thinking about lifetime issues during either phase of my projects. Mostly I just write the same sort of thing that I'd have written in other languages, and the compiler tells me when I've made a mistake.
- orthoxerox 6y ago
  > I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. I've always wanted a "shut up about memory safety for a while, just don't free anything, I want to find out if my code produces the right answer" mode in rustc.
- the_duke 6y ago
  I totally agree that Rust isn't the right language for every domain. But especially in all those domains where memory safety is an issue , in my view it is currently the best option. Rust forces you to think about memory safet and ownership, which is hard to adjust to for many. But it does so for a good reason. In C you also have to think about lifetimes all the time, but the compiler let's you do whatever you want , and the issues instead have to get fixed when bugs pop up, or with static analysis tooling, etc. "I don't want to think about lifetimes" is exactly how we end up with vulnet and buggy software. After the initial learning curve, Rust is a very productive language, exactly thanks to the powerful type system. Like I said, I do wish for a simpler language that can provide similar guarantees, and I do think the design space is in reach, but Zig is (currently) not it.
  - jorangreef 6y ago
    If we are talking of domains where memory safety is an issue, then surely the category of memory safety must include OOM-safety? i.e. Safe handling of out-of-memory conditions under overload?
    - saagarjha 6y ago
      Sure, but crashing cleanly in out-of-memory conditions is generally regard to be "safe" (if undesirable for reliability).
      - jorangreef 6y ago
        I personally like panics and assertions, but the "safety" of the approach would still have to depend on the characteristics of the system. I do not agree that panic-on-OOM should be considered "safe" at a global level hidden within a std lib, where there is no knowledge of the target domain. For example, if an attacker could arbitrarily inject overload to restart rate-limiting processes and then abuse this to trivially brute-force OTP logins. The definition of safety with respect to a resource in general always needs to include the safety of the system as it crosses the threshold i.e. in this case into out-of-memory, so if a system claims memory safety, the first thing I would want to ask is, what about OOMs?
- square_usual 6y ago
  This might just be me being naive, but if you have a business-rules heavy project, why not just use a garbage collected language? I can't think of many use cases where you need a systems programming non-GC language but also have to write tons of custom business logic.
  - 1_player 6y ago
    Indeed I do, these days I spend most of my time on Elixir. But it's handy to have a lower level language that can compile statically for some complex sysadmin task. Go is fine, but a little too plain for my tastes.
  - jorangreef 6y ago
    Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. Beyond the correctness argument, also because the GC can really come back to bite you when you least expect, following the sudden "knee" of Little's Law. I've seen multi-minute pauses every few seconds even with V8's GC in production and it was not a pleasant experience. It cropped up, out of the blue, and in the end required a V8 core team member to advise and help comment out a few lines of C++ GC code that were overzealous.
    - creata 6y ago
      In your first paragraph, you seem to be confusing interpreted languages and GC'd languages. Even Java has all of the features you've listed above, afaict.
      - jorangreef 6y ago
        Yes, I was thinking of Java, which is why I said not "many" and "tend".
    - 6y ago
- littlestymaar 6y ago
  > but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. That's a really strange argument, because as soon as you're not in a GCed language, you need to think about the lifetime of your objects. The big difference with Rust is that you can't make mistakes when doing so, because the compiler will catch it. You don't have the mental burden that if you make a mistake everything will blow up and you can focus on your business rules instead.
orthoxerox 6y ago
Right. It's a better C, but it has to compete with C's ubiquity: there's make and cc on most *nix boxes. JetBrains went out of their way to make migrating to Kotlin as easy as possible: you can literally upgrade your Java project file by file.
- HourglassFR 6y ago
  > JetBrains went out of their way to make migrating to Kotlin as easy as possible: you can literally upgrade your Java project file by file. Yes, offering a good path to switching (and conversely keeping the old voodoo part of the code no one wants to touch) is the way to go. And as I understand it, Zig offers this possibility as well.
- 1_player 6y ago
  Which is why Zig shipping with a functional C compiler with cross platform support is a brilliant idea. Just run `zig cc` and you don't even need `clang` around. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
  - vips7L 6y ago
    And you can directly import C headers into zig files. It's quite amazing.
- pjmlp 6y ago
  Kotlin has settled its future by marring with Android. As Java evolves and Kotlin needs to cater to Mountain View masters, upgrading the Java file won't be enough as many modern features don't exist on ART.
  - unscaled 6y ago
    It was true for a while that Kotlin got stuck on JVM 8 for its target bytecode, but it's no longer true, Kotlin supports all versions up to 15 now: https://kotlinlang.org/docs/compiler-reference.html#jvm-target-version https://kotlinlang.org/docs/compiler-reference.html#jvm-targ... I think the first Kotlin version to use post-Java 9 bytecode is the Kotlin 1.4.20 using invokedynamic for string concatenation: https://blog.jetbrains.com/kotlin/2020/11/kotlin-1-4-20-released/ https://blog.jetbrains.com/kotlin/2020/11/kotlin-1-4-20-rele... Kotlin sealed classes are planned to be rendered as JVM sealed classes when JVM sealed classes go out of preview (probably Java 17), and the same is planned for mapping Kotlin value classes as Project Valhalla user-defined primitive types. All these features obviously won't be available if you target Android, but they will still be there for you if you don't.
ttt0 6y ago
I personally don't care about Rust at all, I already have C++ for that. But I'm very interested in Zig.

fwsgonzo 6y ago

One thing I noticed is that Zig is not 1.0 yet, so perhaps it will still improve in those aspects you are thinking about?

1_player 6y ago

Rust instead is too far on the side of C++ I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. In some niches Rust is perfect, but in every language thread on HN there's often someone that suggests to use Rust whatever the use case. C, in that respect, is more flexible and gets out of the way much more, of course while being unsafer, but it's easier to keep your mind on the goal and not figuring out the best memory safe approach for this piece of logic. Which is why I'm very excited for Zig. I don't want another C++. Give me safer C, thanks.

adrianN 6y ago
In C you also have to think about lifetimes and types, only that the compiler is helping you a lot less to get things right.
- 1_player 6y ago
  Of course, but you don't need a lot of work to make the C compiler happy. The result might not be 100% safe, secure and mathematically proven, but sometimes you need to deliver, fast, not create the safest 1k lines of code on Earth. To be honest I haven't used C in a long time, but I've been looking for a low level language that sparks as much joy as C does. Go, Rust ain't it, IMO.
- flukus 6y ago
  In C you have to think about lifetimes (and to a lesser extent types) at specific times, typically after the "make it work" step of writing code. Rust on the other hand forces you to think of these things from the start and this inhibits solving the actual problem first. Now there's an argument the front loading these decisions may be beneficial overall but I don't find that compelling either. After the "make it work" stage there's thinking about performance, comments, logging, etc and you usually need to think about lifetimes as they change at this point as well, so front loading it has only added work overall.
  - tene 6y ago
    This description doesn't match my experience of writing Rust at all. During the exploratory phase of my projects, I very rarely run into nontrivial lifetime issues, and when I do, I can just put whatever data into an Arc and then it just works. Most of my exploratory code is just objects that own their data. Later in a project, while doing a bunch of refactoring to handle performance, logging, etc. , I have a much easier time letting the compiler tell me when I've made mistakes with a value's lifetime rather than trying to keep the whole program in my head for the duration of the refactor. I don't spend a lot of time thinking about lifetime issues during either phase of my projects. Mostly I just write the same sort of thing that I'd have written in other languages, and the compiler tells me when I've made a mistake.
orthoxerox 6y ago
> I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. I've always wanted a "shut up about memory safety for a while, just don't free anything, I want to find out if my code produces the right answer" mode in rustc.
the_duke 6y ago
I totally agree that Rust isn't the right language for every domain. But especially in all those domains where memory safety is an issue , in my view it is currently the best option. Rust forces you to think about memory safet and ownership, which is hard to adjust to for many. But it does so for a good reason. In C you also have to think about lifetimes all the time, but the compiler let's you do whatever you want , and the issues instead have to get fixed when bugs pop up, or with static analysis tooling, etc. "I don't want to think about lifetimes" is exactly how we end up with vulnet and buggy software. After the initial learning curve, Rust is a very productive language, exactly thanks to the powerful type system. Like I said, I do wish for a simpler language that can provide similar guarantees, and I do think the design space is in reach, but Zig is (currently) not it.
- jorangreef 6y ago
  If we are talking of domains where memory safety is an issue, then surely the category of memory safety must include OOM-safety? i.e. Safe handling of out-of-memory conditions under overload?
  - saagarjha 6y ago
    Sure, but crashing cleanly in out-of-memory conditions is generally regard to be "safe" (if undesirable for reliability).
    - jorangreef 6y ago
      I personally like panics and assertions, but the "safety" of the approach would still have to depend on the characteristics of the system. I do not agree that panic-on-OOM should be considered "safe" at a global level hidden within a std lib, where there is no knowledge of the target domain. For example, if an attacker could arbitrarily inject overload to restart rate-limiting processes and then abuse this to trivially brute-force OTP logins. The definition of safety with respect to a resource in general always needs to include the safety of the system as it crosses the threshold i.e. in this case into out-of-memory, so if a system claims memory safety, the first thing I would want to ask is, what about OOMs?
square_usual 6y ago
This might just be me being naive, but if you have a business-rules heavy project, why not just use a garbage collected language? I can't think of many use cases where you need a systems programming non-GC language but also have to write tons of custom business logic.
- 1_player 6y ago
  Indeed I do, these days I spend most of my time on Elixir. But it's handy to have a lower level language that can compile statically for some complex sysadmin task. Go is fine, but a little too plain for my tastes.
- jorangreef 6y ago
  Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. Beyond the correctness argument, also because the GC can really come back to bite you when you least expect, following the sudden "knee" of Little's Law. I've seen multi-minute pauses every few seconds even with V8's GC in production and it was not a pleasant experience. It cropped up, out of the blue, and in the end required a V8 core team member to advise and help comment out a few lines of C++ GC code that were overzealous.
  - creata 6y ago
    In your first paragraph, you seem to be confusing interpreted languages and GC'd languages. Even Java has all of the features you've listed above, afaict.
    - jorangreef 6y ago
      Yes, I was thinking of Java, which is why I said not "many" and "tend".
  - 6y ago
littlestymaar 6y ago
> but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. That's a really strange argument, because as soon as you're not in a GCed language, you need to think about the lifetime of your objects. The big difference with Rust is that you can't make mistakes when doing so, because the compiler will catch it. You don't have the mental burden that if you make a mistake everything will blow up and you can focus on your business rules instead.

orthoxerox 6y ago

Right. It's a better C, but it has to compete with C's ubiquity: there's make and cc on most *nix boxes. JetBrains went out of their way to make migrating to Kotlin as easy as possible: you can literally upgrade your Java project file by file.

HourglassFR 6y ago
> JetBrains went out of their way to make migrating to Kotlin as easy as possible: you can literally upgrade your Java project file by file. Yes, offering a good path to switching (and conversely keeping the old voodoo part of the code no one wants to touch) is the way to go. And as I understand it, Zig offers this possibility as well.
1_player 6y ago
Which is why Zig shipping with a functional C compiler with cross platform support is a brilliant idea. Just run `zig cc` and you don't even need `clang` around. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- vips7L 6y ago
  And you can directly import C headers into zig files. It's quite amazing.
pjmlp 6y ago
Kotlin has settled its future by marring with Android. As Java evolves and Kotlin needs to cater to Mountain View masters, upgrading the Java file won't be enough as many modern features don't exist on ART.
- unscaled 6y ago
  It was true for a while that Kotlin got stuck on JVM 8 for its target bytecode, but it's no longer true, Kotlin supports all versions up to 15 now: https://kotlinlang.org/docs/compiler-reference.html#jvm-target-version https://kotlinlang.org/docs/compiler-reference.html#jvm-targ... I think the first Kotlin version to use post-Java 9 bytecode is the Kotlin 1.4.20 using invokedynamic for string concatenation: https://blog.jetbrains.com/kotlin/2020/11/kotlin-1-4-20-released/ https://blog.jetbrains.com/kotlin/2020/11/kotlin-1-4-20-rele... Kotlin sealed classes are planned to be rendered as JVM sealed classes when JVM sealed classes go out of preview (probably Java 17), and the same is planned for mapping Kotlin value classes as Project Valhalla user-defined primitive types. All these features obviously won't be available if you target Android, but they will still be there for you if you don't.

ttt0 6y ago

I personally don't care about Rust at all, I already have C++ for that. But I'm very interested in Zig.