On 2020-02-10 16:31, Brian Candler wrote:
> p.s. Does anyone know how well Rust reads as this is highly important to
> me?
>
>
> I have read Rust described as being in the spirit of "pragmatic Haskell".
>
> https://jmmv.dev/2018/07/rust-vs-go.html
> https://jmmv.dev/series.html#Rust%20revie
On Monday, 10 February 2020 10:09:47 UTC, Kevin Chadwick wrote:
>
> p.s. Does anyone know how well Rust reads as this is highly important to
> me?
>
I have read Rust described as being in the spirit of "pragmatic Haskell".
https://jmmv.dev/2018/07/rust-vs-go.html
https://jmmv.dev/series.html#Ru
On 2020-02-09 15:05, David Riley wrote:
> Correspondingly, the rather heavy requirements for the Go runtime make it a
> lot less practical for small embedded use cases (though not impossible, as
> recent list traffic indicates). If I were building a small (think <=256k
> RAM) embedded system th
If you use any dynamic memory strict latency is very very difficult in any
language/platform. I’m not really sure how a platform like Discord has strict
latency requirements - it’s not as if the ‘read badge’ not updating is going to
crash the plane.
As an example a lot of auto systems use Java
On Feb 7, 2020, at 7:24 AM, Everton Marques wrote:
>
> I think Go is way better than Rust, but it is amusing to see why people pick
> one over another.
I think they have very different use cases. Rust is fundamentally a functional
language, which suits it quite well for things functional lang
On Saturday, 8 February 2020 08:38:40 UTC, Eric S. Raymond wrote:
> Go, on the other hand...I'm an old
> hand from the same culture the Go devs exemplify.
>
I'm glad somebody else has said that. For me, Kernighan and Pike's
involvement was the clinching argument in favour of Go. Coding
p
Bakul Shah :
> Did you consider using nim? It is much closer to python. You could've even
> selectively replaced python bits with nim bits based on profiling.
I did, very briefly. At the time I had to make the decision - a little
over a year ago now - Nim did not seem quite well-established enough
> On Feb 7, 2020, at 10:44 PM, Eric S. Raymond wrote:
>
> On the other hand, for me to have tried to port reposurgeon to Rust
> would have been a mind-numbingly stupid idea. And that will be true of
> any application above a certain complexity of internal data-structure
> management, where havin
Tyler Compton :
> It would have been nice to see performance measurements from a more recent
> Go version. That said, it makes sense to me that Rust would be a better
> choice for this kind of application, where the main performance bottleneck
> is the sheer number of objects in memory. A language
I think if you look into Zing or Shenandoah you’ll find a different experience.
Literally zero tuning required.
> On Feb 7, 2020, at 3:29 PM, Marcin Romaszewicz wrote:
>
>
>
>
>> On Fri, Feb 7, 2020 at 11:43 AM Robert Engels wrote:
>> I didn’t look into the project but reading between th
On Fri, Feb 7, 2020 at 11:43 AM Robert Engels wrote:
> I didn’t look into the project but reading between the lines here I am
> betting that Java would perform as well as Rust in this case. This is an
> example of where not having generational GC hurts badly - since it appears
> that most of the
I didn’t look into the project but reading between the lines here I am betting
that Java would perform as well as Rust in this case. This is an example of
where not having generational GC hurts badly - since it appears that most of
their heap would be very long lived objects.
> On Feb 7, 2020
You're not oversimplifying. GC incurs a price, and that's performance. If
you have a program which manages its own memory optimally for its usage
pattern, it will be more efficient than a generic GC that has to handle all
usage patterns. I use Go everywhere I can, since the tradeoff between
program
It would have been nice to see performance measurements from a more recent
Go version. That said, it makes sense to me that Rust would be a better
choice for this kind of application, where the main performance bottleneck
is the sheer number of objects in memory. A language where you get to
express
On Friday, February 7, 2020 at 5:13:45 PM UTC+1, Lutz Horn wrote:
>
> > "Remarkably, we had only put very basic thought into optimization as the
> Rust version was written. Even with just basic optimization, Rust was able
> to outperform the hyper hand-tuned Go version. This is a huge testament t
> "Remarkably, we had only put very basic thought into optimization as the Rust
> version was written. Even with just basic optimization, Rust was able to
> outperform the hyper hand-tuned Go version. This is a huge testament to how
> easy it is to write efficient programs with Rust compared to
16 matches
Mail list logo
