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
I think Go is way better than Rust, but it is amusing to see why people pick
one over another.
"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
17 matches
Mail list logo
