9 ms·

To me, Hare's greatest strengths are in its simplicity, error handling, the standard library, and its documentation. Hare also has a culture of careful and deli

To me, Hare's greatest strengths are in its simplicity, error handling, the standard library, and its documentation. Hare also has a culture of careful and deliberate engineering which values correctness, completeness, and predictability. I asked the #hare IRC channel to add their own thoughts, will edit this comment with any answers: > Simplicity. > I think a strength is the plan for long term stability. > It's simple and the compiler is tiny. > First thing that comes to mind is error handling. > The syntax seems simple to me, like c and go and unlike c++ and rust. > I think a major strength is you can transfer your C expertise. > You don't have to worry about your post-1.0 code breaking or becoming obselete from new language idioms. > Clear communication from the hare dev team about what the project goals are.

xscott 4y ago
I'm certain there is room for a better C, but simple is in the eye of the programmer. I would argue that Scheme is obviously simpler, but most people don't want to write system software in that. I suspect "simple enough" is a threshold/constraint, but not really the goal.
xixixao 4y ago
I am really curious why “println” lives in “fmt” module. I get that it does string formatting, but it also prints, and I would expect “fmt” to only do formatting. This sours my first impression of the language. It makes me expect lots of other counterintuitive decisions in the language.
- emersion 4y ago
  FWIW, Go's fmt package does the same: https://pkg.go.dev/fmt https://pkg.go.dev/fmt
  - zxwrt 4y ago
    link without tracking: https://godocs.io/fmt https://godocs.io/fmt
- kragen 4y ago
  If you have a formatting operation that outputs some number of chunks of text to a stream, using some dynamically dispatched output operation which does something similar to writing to a buffered output file, you can use it to produce a string fairly easily, as long as it fits in memory: you implement an output operation that appends to a string buffer. This is close to optimally efficient except when appending characters one or two at a time, in which case the extra dynamic dispatch overhead may be significant compared to whatever else you're doing to choose those characters. If you have a formatting operation that produces an in-memory string, you cannot use it if the amount of text being produced is too large, or if you do not know if it is too large. But if it is not too large, you can then output the string to a buffered output file, although this is less efficient because it involves an extra copy and potentially dirties a lot more memory. So these two ways of handling formatting are easily interconvertible when memory permits, but in some circumstances only the first one is applicable, and it is always more efficient. Therefore, when reliability or efficiency is important, generating a formatted string should be implemented as a layer on top of sending formatted output to a stream, not vice versa. There are cases where reliability and efficiency are not important, because your code is being used by end users and not as part of a library, and an error message is also an acceptable result of trying to run your program, and in those cases you should probably write your program in a language like Lua, Python, or JS. It is probably true that if you are used to languages like those, a lot of design decisions that are necessary for reliability and efficiency will be counterintuitive to you.
  - lifthrasiir 4y ago
    Note that this explains why string formatting is inherently tied with the I/O layer, but not necessarily why `println` (which is a very specific I/O operation) should be in the `fmt` module. That one is more subjective and probably only for the convenience.
    - kragen 4y ago
      Do you mean why you can write (untested) fmt::println(x, y, z); instead of (also untested) fmt::fprintf(os::stdout, "{}{}{}\n", x, y, z); ? I mean I agree that presumably anything you could do in the first form could be done in the second form, less conveniently as you say, but if you omit println from fmt then all the Golang programmers learning Hare will be surprised about the missing stair they expect as the Hare counterpart to fmt.Println. And I think omitting the terminating newline in your format string is a common enough bug that it's probably worthwhile to include a separate function that adds it implicitly, especially in the case of fmt::print, which doesn't have a format string to add it to. Even without Golang experience, if you're going to have an fprintf and a println, I'd look for the println in the module that has the fprintf in it.
cgh 4y ago
It seems quite similar to Zig, including the error handling flexibility and memory management. But Zig also has a good concurrency story via its “colourblind” async/await support, although concurrency seems to not be a Hare design goal. Is there something about Zig that rubs you the wrong way? Honestly, Hare almost seems like a Zig subset. Edit: I respect your technical skills and sheer volume of output a lot so not trolling here, just trying to gain clarity after reading the language introduction.
- ddevault 4y ago
  Yes, I tried to work with Zig long before Hare was even an idea. I had hoped that Zig would fill the hole in the ecosystem that Hare is designed to fill, but ultimately I felt that I needed to write Hare. I think that Zig is far too complex and essentially unbounded in scope. A language to replace C needs to be as conservative as C, if not even more considering the coming changes from C2X.
  - cgh 4y ago
    Thanks. I agree that Zig is more complex than advertised. By the way, good job on Hare’s documentation, pretty impressive for an early-stage language.
    - ddevault 4y ago
      Thanks!
  - 2c2c2c 4y ago
    how long has it been since you've checked it out. I'm no systems programmer and the drawing quality of the language to me was being able to jump into stdlib symbols and actually understand the code
    - ddevault 4y ago
      I revisit Zig often.
boris 4y ago
I wonder what are your plans regarding the build system/package manager? Specifically, do you plan to roll your own language-specific tooling (with some support for building C dependencies)?
- ddevault 4y ago
  We're leaving package management in the capable hands of distribution packagers. https://harelang.org/distributions/ https://harelang.org/distributions/
  - cyber_kinetist 4y ago
    "Hare programs are statically linked. We know you’re not a fan of this. We’re sorry." Absolutely hilarious (and thanks for making this decision!)
  - wheelerof4te 4y ago
    That layout is so smooth. Smart choice for packaging. Keep it simple should be a rule, not the exception.
  - wheelerof4te 4y ago
    Do you believe that Hare will make it into the next Debian Stable release? That should be somewhere in summer of 2023, if we go by previous release dates.
    - ddevault 4y ago
      It's hard to say, I'm not sure.

xscott 4y ago

I'm certain there is room for a better C, but simple is in the eye of the programmer. I would argue that Scheme is obviously simpler, but most people don't want to write system software in that. I suspect "simple enough" is a threshold/constraint, but not really the goal.

xixixao 4y ago

I am really curious why “println” lives in “fmt” module. I get that it does string formatting, but it also prints, and I would expect “fmt” to only do formatting. This sours my first impression of the language. It makes me expect lots of other counterintuitive decisions in the language.

emersion 4y ago
FWIW, Go's fmt package does the same: https://pkg.go.dev/fmt https://pkg.go.dev/fmt
- zxwrt 4y ago
  link without tracking: https://godocs.io/fmt https://godocs.io/fmt
kragen 4y ago
If you have a formatting operation that outputs some number of chunks of text to a stream, using some dynamically dispatched output operation which does something similar to writing to a buffered output file, you can use it to produce a string fairly easily, as long as it fits in memory: you implement an output operation that appends to a string buffer. This is close to optimally efficient except when appending characters one or two at a time, in which case the extra dynamic dispatch overhead may be significant compared to whatever else you're doing to choose those characters. If you have a formatting operation that produces an in-memory string, you cannot use it if the amount of text being produced is too large, or if you do not know if it is too large. But if it is not too large, you can then output the string to a buffered output file, although this is less efficient because it involves an extra copy and potentially dirties a lot more memory. So these two ways of handling formatting are easily interconvertible when memory permits, but in some circumstances only the first one is applicable, and it is always more efficient. Therefore, when reliability or efficiency is important, generating a formatted string should be implemented as a layer on top of sending formatted output to a stream, not vice versa. There are cases where reliability and efficiency are not important, because your code is being used by end users and not as part of a library, and an error message is also an acceptable result of trying to run your program, and in those cases you should probably write your program in a language like Lua, Python, or JS. It is probably true that if you are used to languages like those, a lot of design decisions that are necessary for reliability and efficiency will be counterintuitive to you.
- lifthrasiir 4y ago
  Note that this explains why string formatting is inherently tied with the I/O layer, but not necessarily why `println` (which is a very specific I/O operation) should be in the `fmt` module. That one is more subjective and probably only for the convenience.
  - kragen 4y ago
    Do you mean why you can write (untested) fmt::println(x, y, z); instead of (also untested) fmt::fprintf(os::stdout, "{}{}{}\n", x, y, z); ? I mean I agree that presumably anything you could do in the first form could be done in the second form, less conveniently as you say, but if you omit println from fmt then all the Golang programmers learning Hare will be surprised about the missing stair they expect as the Hare counterpart to fmt.Println. And I think omitting the terminating newline in your format string is a common enough bug that it's probably worthwhile to include a separate function that adds it implicitly, especially in the case of fmt::print, which doesn't have a format string to add it to. Even without Golang experience, if you're going to have an fprintf and a println, I'd look for the println in the module that has the fprintf in it.

cgh 4y ago

It seems quite similar to Zig, including the error handling flexibility and memory management. But Zig also has a good concurrency story via its “colourblind” async/await support, although concurrency seems to not be a Hare design goal. Is there something about Zig that rubs you the wrong way? Honestly, Hare almost seems like a Zig subset. Edit: I respect your technical skills and sheer volume of output a lot so not trolling here, just trying to gain clarity after reading the language introduction.

ddevault 4y ago
Yes, I tried to work with Zig long before Hare was even an idea. I had hoped that Zig would fill the hole in the ecosystem that Hare is designed to fill, but ultimately I felt that I needed to write Hare. I think that Zig is far too complex and essentially unbounded in scope. A language to replace C needs to be as conservative as C, if not even more considering the coming changes from C2X.
- cgh 4y ago
  Thanks. I agree that Zig is more complex than advertised. By the way, good job on Hare’s documentation, pretty impressive for an early-stage language.
  - ddevault 4y ago
    Thanks!
- 2c2c2c 4y ago
  how long has it been since you've checked it out. I'm no systems programmer and the drawing quality of the language to me was being able to jump into stdlib symbols and actually understand the code
  - ddevault 4y ago
    I revisit Zig often.

boris 4y ago

I wonder what are your plans regarding the build system/package manager? Specifically, do you plan to roll your own language-specific tooling (with some support for building C dependencies)?

ddevault 4y ago
We're leaving package management in the capable hands of distribution packagers. https://harelang.org/distributions/ https://harelang.org/distributions/
- cyber_kinetist 4y ago
  "Hare programs are statically linked. We know you’re not a fan of this. We’re sorry." Absolutely hilarious (and thanks for making this decision!)
- wheelerof4te 4y ago
  That layout is so smooth. Smart choice for packaging. Keep it simple should be a rule, not the exception.
- wheelerof4te 4y ago
  Do you believe that Hare will make it into the next Debian Stable release? That should be somewhere in summer of 2023, if we go by previous release dates.
  - ddevault 4y ago
    It's hard to say, I'm not sure.