X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Spam-Checker-Version:	SpamAssassin 3.4.0 (2014-02-07) on fly.srk.fer.hr
X-Spam-Level:
X-Spam-Status:	No, score=-1.0 required=6.3 tests=ALL_TRUSTED
	autolearn=disabled version=3.4.0
Date:	Tue, 7 Jul 2015 23:09:59 +0200
From:	"Ivan Stankovic (pokemon AT fly DOT srk DOT fer DOT hr) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	"Dave McGuire (mcguire AT neurotica DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] gEDA/gschem still alive?
Message-ID:	<20150707210959.GA2780@alpha2>
References:	<20150706200609 DOT GD24178 AT localhost DOT localdomain>
	<CAC4O8c9f0pLsLu_dyuO5ggh7RmHY1vAA=UUhk9AE0JYZb4mhBQ AT mail DOT gmail DOT com>
	<CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com>
	<20150707060409 DOT GB14357 AT localhost DOT localdomain>
	<CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com>
	<1436287952 DOT 678 DOT 26 DOT camel AT ssalewski DOT de>
	<559C0F7E DOT 7010009 AT neurotica DOT com>
	<1436295556 DOT 678 DOT 91 DOT camel AT ssalewski DOT de>
	<E90F2D99-6421-4D1A-BF28-73992A21BA1F AT icloud DOT com>
	<559C3901 DOT 9090205 AT neurotica DOT com>
MIME-Version:	1.0
In-Reply-To:	<559C3901.9090205@neurotica.com>
X-Operating-System:	GNU/Linux
User-Agent:	Mutt/1.5.23+89 (0255b37be491) (2014-03-12)
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, Jul 07, 2015 at 04:39:29PM -0400, Dave McGuire (mcguire AT neurotica DOT com) [via geda-user AT delorie DOT com] wrote:
> > Is it really that those languages have become faster, or is it
> > simply that the advances in CPU processing power means that the
> > differences between them are drowned out by other bottlenecks, like
> > IO? I wonder if you'd get similar results if these languages were
> > benchmarked on a 486?
> 
>   If all developers were forced to test their code on very slow
> machines, the world would be a much happier place.  Yet another reason
> why I moved from server-side development entirely into embedded
> firmware, where code performance still matters.

While I sympathise with many of the arguments that you present,
I have to point out that Rust enabled me sorts of code optimizations
that one would need to think and try very hard to accomplish with C.
E.g. macros that optimize to almost nothing, full dead code elimination
allowed for by the Rust compilation model (unlike that of C where you
need -ffunction-sections and pray that the linker implements this
correctly on your architecture -- which it doesn't if you're unlucky;
try doing that on avr, for example).  Note that that I'm *specifically*
talking about embedded stuff here.  Please see https://zinc.rs/ for 
an example of what has been possible with Rust on ARM for quite some
time now.

This is not to say that every language out there is like that, or
that Rust is ideal for embedded stuff.  I'm just saying that I've
seen generalizations and misconceptions mentioned in this thread
that are very far from the truth.

-- 
Ivan Stankovic, pokemon AT fly DOT srk DOT fer DOT hr

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm"

- Raw text -