The idea that MS is out to envelope developers by enticing them into a language that requires massive cash outlays or *ongoing licensing fees* is not supported by reality. ... The only requirement being that they run on a Windows OS Mhm. Yes, I suppose you can run some C# on a non-windows machine, but it'll have bugs, break, some libraries won't be supported and there's no tooling support. ...but don't worry, you can…
What would make you happy here? Would open sourcing the C# compiler be enough? Open sourcing .NET? Providing .NET support and development for Linux? I'm honestly just curious, not to put you on the spot.
typescript and go are two examples of doing the right thing.
It's not hard, heck Microsoft has even done it before, they just missed the ball with C#.
This attitude is why java is stuck in the stone ages. Any ideas coming from the dynamically typed world are "dumb".
No, dumb ideas are dumb. It has nothing to do with java. Haskell is statically typed, and it is far more advanced than the languages you are thinking of when you think advanced.
which ideas are dumb and why?
btw being a jerk doesn't help your case.
lesson in civil discourse by example: "I don't think that a ||= operator is a good idea because XXX"
Context is cool. With context, you can participate in a conversation, rather than stating an obvious but non-sequitur fact. By definition, type checks are done at compile time. Haskell's defer-type-errors is precisely an example of that. The error is found at compile time, but rather than signal it, the offending code is replaced with an exception.
sanxiyn's comment seems to fully understand the context. Re-read his message in the context of my message. > By definition, type checks are done at compile time. That does not match my definition of type checks. Ignoring things like Typed Racket or clojure.core.typed for a moment. Consider a cast in Java: This is a type safe operation which incurs a runtime type check. Now maybe you're thinking of global type checkin…
>sanxiyn's comment seems to fully understand the context
No it doesn't, given that the context was specifically runtime checks like array bounds checking, and he replied with a non-sequitur about memory corruption.
>That does not match my definition of type checks.
That is because "your definition" is incorrect. I am using the actual definition. "Dynamic typing" is a deliberately incorrect name for untyped languages. Runtime checking of value compatibility is not type checking.
I think you're missing my point, it's about sweet spots. C# has a sweet spot on windows desktop and ETL style data processing. You could have written all of those things in C++, Java or Python. But the ecosystem isn't there. There's no Hadoop, SciPy, Django or Rails. For crying out loud, just running a less compiler on Windows required someone to sit down and rewrite it from scratch. (The node story has improved on w…
>And none of this looks likely to change. Windows has been a second rate development platform for some time now, and Microsoft don't mind. Says who? Those of us that use GUI environments not stuck in 70's terminals workflow think otherwise.
> Rust has a completely different type system model What are the differences? It sounds pretty similar to Rust—"rvalue references, move semantics, destruction, references / borrowing" are straight out of Rust's playbook. Granted, if it's based on C#, it sounds like it'll be more object-oriented than Rust is, which is a difference. Rust has some object-oriented features, but they're much more minimalist than what C# o…
>What are the differences? As you mentioned, if they based it entirely on C# , it will be a unified type system. We'll only get more information when they release a standards specification. >Rust is about zero-cost abstractions, period. Um.. no? For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?). This obviously means that the programmer has little control over memory allocati…
You'll have to take the word of the people aiming rust, really.
Refcounted pointers are just one option in rust. ~Obviously~ you can use anything from C-style pointers and your own custom allocator that calls brk() directly to atomically refcounted and/or mutexed threadsafe smartpointers to manage your memory.
I think you're missing my point, it's about sweet spots. C# has a sweet spot on windows desktop and ETL style data processing. You could have written all of those things in C++, Java or Python. But the ecosystem isn't there. There's no Hadoop, SciPy, Django or Rails. For crying out loud, just running a less compiler on Windows required someone to sit down and rewrite it from scratch. (The node story has improved on w…
You're right. I am completely missing your point. I can't speak for all .net shops, but in my experience you roll your own. You sit down, discover your problem, and write a solution for whatever you need from scratch specifically tailored to your need and performance requirements. Afterward, you understand the code (and the intent behind it) very very well. I don't lament the lack of third party frameworks. I take th…
Believe me, I'm a great advocate of building the thing you need rather than blinding using libraries, but there's some great stuff out there: lessc, RabbitMQ (although that works well on Windows), Riak, Postgres, neo4j, hadoop, jQuery (Microsoft saw the light on that one), elastic search, pygments. Of those, Microsoft can offer alternatives to 2 of them: MSMQ and SQL Server. The others are sufficiently costly to re-implement that you're likely to just try to work around the problem (I'd love to see someone attempt a DB with Riak-like reliability on .NET... RavenDB is not that DB.)
>And none of this looks likely to change. Windows has been a second rate development platform for some time now, and Microsoft don't mind. Says who? Those of us that use GUI environments not stuck in 70's terminals workflow think otherwise.
It's getting better a bit since 2-3 years ago but before that Microsoft was always stuck in the 90's style of development while other platforms have moved forward significantly. Nuget is a late attempt to follow Maven and yet still behind. EntityFramework came in late and I heard ppl moaned. No Docker... Chocolatey came in late. So yeah... Says the parent thread and me.
Yeah, Microsoft's ORM solutions are pretty horrible but then... so is NHibernate. But NHibernate was better and five years earlier, so it was really hard to see why Microsoft even bothered with EF.
You're right. I am completely missing your point. I can't speak for all .net shops, but in my experience you roll your own. You sit down, discover your problem, and write a solution for whatever you need from scratch specifically tailored to your need and performance requirements. Afterward, you understand the code (and the intent behind it) very very well. I don't lament the lack of third party frameworks. I take th…
Believe me, I'm a great advocate of building the thing you need rather than blinding using libraries, but there's some great stuff out there: lessc, RabbitMQ (although that works well on Windows), Riak, Postgres, neo4j, hadoop, jQuery (Microsoft saw the light on that one), elastic search, pygments. Of those, Microsoft can offer alternatives to 2 of them: MSMQ and SQL Server. The others are sufficiently costly to re-i…
If you like Riak, there is a .net client library. There is a .net port of lessCSS. RabbitMQ works with .net. You can access postgres with .net. I didn't see any features of Neo4J that I can't do pretty easily with MSSQL and a custom DAL. You can talk to Hadoop from .net. I've been using jQuery with ASP.net since it was released. Elasticsearch runs on windows, and I don't see why you can't use it with a .net project. I don't really see the point of pygments, but it looks like it's pretty easy to use with IronPython.
So in those instances you have a choice. You can use those libraries/products as they stand, or you can roll your own.
sanxiyn's comment seems to fully understand the context. Re-read his message in the context of my message. > By definition, type checks are done at compile time. That does not match my definition of type checks. Ignoring things like Typed Racket or clojure.core.typed for a moment. Consider a cast in Java: This is a type safe operation which incurs a runtime type check. Now maybe you're thinking of global type checkin…
>sanxiyn's comment seems to fully understand the context No it doesn't, given that the context was specifically runtime checks like array bounds checking, and he replied with a non-sequitur about memory corruption. >That does not match my definition of type checks. That is because "your definition" is incorrect. I am using the actual definition. "Dynamic typing" is a deliberately incorrect name for untyped languages.…
1) Surely the most common source of memory corruption is bounds violations.
2) Even reconciling our disagreement on terminology, I still disagree A) that a strict phase separation is a prerequisite for types to exist at all and B) that it even makes sense to talk about "untyped" as if I couldn't just invent a type system (however complex) for proving properties of a particular language that previously had no known type system.
The simple fact of the matter is that definitions evolve over time as we learn more about our field. "Type safety" is historically valid phrase for what we now know as "memory safety". In context of the performance claims, it was quite clear what the author meant.
>And none of this looks likely to change. Windows has been a second rate development platform for some time now, and Microsoft don't mind. Says who? Those of us that use GUI environments not stuck in 70's terminals workflow think otherwise.