Earlier quoted context omitted.
I think that is exactly the point. The argument is that if a language is developed/mainly contributed by a single company there is an inherent risk of that language being suddenly discountinued or lacking features that are needed by other people/companies. At least that's how I understand the critics against microsoft in this case.
> lacking features that are needed by other people/companies. Funny how nobody seems to give pile on Google for how it handles Go here...
Microsoft is creating a new Rust-based programming language for secure coding
191–200 of 207 posts
Re: Microsoft is creating a new Rust-based programming language for secure coding
#192Earlier quoted context omitted.
Being a modern language not stuck in the 60's language design is not feature bloat.
Orthogonal concepts. Modern languages can be bloated.
If Go's design was perfect, its eco-system wouldn't feel like Java 1.0, full with libraries to replicate what should be language features to start with.
The first time I saw "go generate" it was on Borland C++ 2.0 for MS-DOS, released around 1990.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#193Earlier quoted context omitted.
Orthogonal concepts. Modern languages can be bloated.
Or stuck in the pre-history of language design. If Go's design was perfect, its eco-system wouldn't feel like Java 1.0, full with libraries to replicate what should be language features to start with. The first time I saw "go generate" it was on Borland C++ 2.0 for MS-DOS, released around 1990.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#194Earlier quoted context omitted.
Or stuck in the pre-history of language design. If Go's design was perfect, its eco-system wouldn't feel like Java 1.0, full with libraries to replicate what should be language features to start with. The first time I saw "go generate" it was on Borland C++ 2.0 for MS-DOS, released around 1990.
Can't lie. It's entertaining to watch people like you get emotional over a piece of technology.
Some of us care about advancing the state of art, instead of being stuck into the ways of the past.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#195Earlier quoted context omitted.
Can't lie. It's entertaining to watch people like you get emotional over a piece of technology.
Not really, passional about language design and safety, indeed. Some of us care about advancing the state of art, instead of being stuck into the ways of the past.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#196Re: Microsoft is creating a new Rust-based programming language for secure coding
#197I'm curious to see what Microsoft does. The big breakthrough with Rust was ownership, and Microsoft seems to agree on that. Rust has a lot of other baggage that could be dispensed with. Of course, Microsoft has their own baggage.
More precisely Cyclone already had borrow checker over a decade ago. Rust derives much of its memory model from that language.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#198Earlier quoted context omitted.
AFAIK, Julia has a garbage collector. I envision the thing more like a rust split into two variants. One with GC and mandatory typing, one without.
Yes, for sure my suggestion was an incomplete answer, but still you would want the lower language be GC-aware/GC-compatible so I am not sure what the advantages of having two languages would be compared to having a GC language that can have non-GC modules/functions. We also have an example of something more similar to what you are asking with Javascript+wasm (or better Typescript+wasm). I think they are both a fertil…
Re: Microsoft is creating a new Rust-based programming language for secure coding
#199Earlier quoted context omitted.
Yes, and I think Julia is a perfect starting point for an extremely productive general purpose language. The one major wart with Julia is reliance on GC, I'm interested to hear what workarounds exist. If no common usage patterns rely on the GC, it should be possible to write "recycling" code that doesn't incur GC pauses and hence, unpredictable latency. I really enjoy using Julia, it's a great balance of concision, e…
There is a common demand from people for extracting just a very concrete computation from a julia codebase and compiling it to a standalone library (or even just using it within an existing julia program, but guaranteeing certain allocation or real time behavior). For example, julia includes a pure julia implementation of libm, but we also maintain the openlibm C library, since we link it into some of our C dependenc…
Is some concept of language support for traits/ interfaces and/or static typing part of this effort?
Also, would there be different levels of leanness for the static compile? I can see some people wanting binaries that use a minimal runtime or GC, but no heavy JIT etc so that a larger set of programs can be distributed but at some tradeoff.