"You really can't have this both ways. Either features like traits and
implementations matter, in which case my programming in the large concerns
come into play, or those features don't matter, in which case Rust isn't an
enhancement of C. Pick one."
Why cant i have a large standard lib ...with traits and use a lot of c
style modules in my code "modules" ? Together they form a large app...
By "module" i wasnt thinking a rust crate , more say a WCF service .. with
loosely coupled message style async communication via pipe / shared memory.
C# can do it but C# cant do it pauseless ... nor can i build such a
framework in C#..
"App architecture is unquestionably important. No argument. Nonetheless,
mistakes in the language design - in this case the absence of lexical
scoping for impls (aka type class instances) - can destroy any hope of
success for the best imaginable architecture."
I dont think it stopped Haskell ... and for the system programming core it
will be even less important ... Im quite sure you can write s decent kernel
or service with rust .. Im not convinced you can do a 3D app ( in non c
style) due to the large amount of concpets embeded in the types . That
said it imay still better than C++.
Is a do everything well case too much to ask ? It may even be possible
theoretically but practically eg can you satisfy the C++ community .. I
see no point in going near general business apps , You would be mad not to
use Java , C# , PHP or Java script due to factors like skills in the market
place. However C/C++ is another case , senior devs and management are
asking can we do this green field app in C# and Java but C /C++ wins in
serveral cases for green field apps.
- Small embeded systems .. need a small runtime and work with existing c
libs {Rust can do this but runtime too fat at the moment)
- No Pause , 3D games.
- Competative Highest performance , low latency trading they are after
every ms they can sqeeze. It means you get the order in. There is also
some competition with libs..
- Building a run time ... making a self hosting runtime with GC or a kernel
reliant on a GC is a pain .
- Device drivers that do IO ..
To me rust can deliver on these...
On Tue, Jul 16, 2013 at 11:56 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Mon, Jul 15, 2013 at 8:01 PM, Bennie Kloosteman <[email protected]>wrote:
>
>> >It's a big issue. It's a fundamental impediment to programming at scale.
>>
>> -Its better than C and Rust allows pure C style as well as types.. there
>> are large C and Haskell apps....
>> -if your target is systems programming than i think this is even less
>> of an issue.
>> - If your standard lib has most of the types than it becomes less of an
>> issue ( not that Rust does well here , there standard lib is like C ) ,
>> since you wont often create the same type as the standard lib .
>>
>
> You really can't have this both ways. Either features like traits and
> implementations matter, in which case my programming in the large concerns
> come into play, or those features don't matter, in which case Rust isn't an
> enhancement of C. Pick one.
>
> I have been thinking about this more and more and over the years i think
>> ALL large scale multi purpose multi team apps bascially degrade without a
>> huge amount of work to keep it perfect...
>>
>
> Yes. But at least in languages with link safety it is possible to resolve
> problems without assembling a large team divided by multiple organizations,
> some of whose members are dead by the time the problem is identified.
>
>
>> Yet a "module" stays useable and maintanable for along time...
>>
>
> Ideally so. In the absence of link safety, there is no such concept. Rust
> does not preserve link safety.
>
>
>> So to me the problem of programmign at scale is less the language but the
>> app architecture and the way developers program .
>>
>
> App architecture is unquestionably important. No argument. Nonetheless,
> mistakes in the language design - in this case the absence of lexical
> scoping for impls (aka type class instances) - can destroy any hope of
> success for the best imaginable architecture.
>
>
> Jonathan
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
