Hacker News new | past | comments | ask | show | jobs | submit | skldj28d2's comments login

Axum is most likely to be supported long term since it has quite a bit of support and is a Tokio project but it's not nearly as batteries included as something like Rails or Django. I doubt any of the current batteries included Rust web frameworks will last.

> with Bun leading the way

Definitely leading the way in segfaults.


Basically every custom data structure right now has some custom implementation of iterators. This will set a standard and make them usable with range loops. Even simple library methods like scanner.Scan, strings.Split, regex.FindAll or sql.Query should return iterators.


> strings.Split, regex.FindAll

But they already do, slices are iterables, and the input is bounded. Plus you have lots of other benefits like indexability. What need would it solve?

> scanner.Scan, sql.Query

Right, these are not suitable for slices because they’re unbounded. But still, what’s the use case? You still have roughly the same amount of code, no? Even the same noisy if err != nil checks. Can you provide a snippet that highlights the benefits?


https://github.com/golang/go/issues/61405#issuecomment-16388...:

> Can you provide more motivation for range over functions?

> If the results can be generated one at a time, then a representation that allows iterating over them scales better than returning an entire slice. We do not have a standard signature for functions that represent this iteration. Adding support for functions in range would both define a standard signature and provide a real benefit that would encourage its use.

> There are also functions we were reluctant to provide in slices form that probably deserve to be added in iterator form. For example, there should be a strings.Lines(text) that iterates over the lines in a text.


> scanner.Scan, strings.Split, regex.FindAll or sql.Query should return iterators

Will never happen. Best you can hope for is new functions


I know. There are already proposals to add new functions to many of these packages that return iterators.


no there arent




But is this a problem?


They'll be used primarily by library authors but most people will end up consuming them a lot. They'll eliminate a lot of unnecessary intermediate slice allocations.


Erlang/Elixir are very slow for most computationally expensive tasks.


Isn’t python the same? Most of the work is done by c++ or rust libs with python as glue.


Python is the same but there's not nearly enough incentive to move to another slow language. A lot of people that are interested in using something other than Python want a language that doesn't require everything to be written in C, C++ or Fortran and used via bindings. Having most of the ecosystem written in one expressive and relatively fast language has huge benefits.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: