Live data from Hacker News

A glimpse into a new programming language under development at Microsoft

lambda-the-ultimate.org

221–230 of 230 posts

Re: A glimpse into a new programming language under development at Microsoft

#221
post #170

Earlier quoted context omitted.

>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.

That is still light years ahead of coding with vi/emacs in UNIX SYSTEM V style, like many here still seem to do.

I only do it when I am left without any other choice, maybe growing up with Amiga/Smalltalk/Oberon GUIs has spoiled me.

Re: A glimpse into a new programming language under development at Microsoft

#222

Earlier quoted context omitted.

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"

Trying to turn a language into a totally and completely different language is dumb. This is not complicated. Civil discourse also requires that you take the time to read and comprehend words before you reply to them with crap.

Re: A glimpse into a new programming language under development at Microsoft

#223

Earlier quoted context omitted.

>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 ty…

>Surely the most common source of memory corruption is bounds violations.

Surely the most common source of oranges is orange trees.

>Even reconciling our disagreement on terminology

You aren't reconciling it, you are just repeating "I don't like the real definition of type system in regards to computer science". That's great for you and all, but it has nothing to do with me. If you want to learn about it I can recommend some material, but if you just want to argue "I don't understand X therefore using the correct terminology for X is wrong" then there's no need to continue.

Re: A glimpse into a new programming language under development at Microsoft

#224
post #206

Earlier quoted context omitted.

> 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…

> For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?).

No, the heap primarily uses unique ownership, which is equivalent to malloc/free. Reference counting is an option (and mark/sweep in the future) but idiomatic Rust only uses reference counting where it is necessary.

> Secondly from my initial use of Rust I dont think you cannot protect a chunk of data with a lock and share it (w/o copying) across threads/processes as you would with a systems language like C++.

Yes, you can. http://static.rust-lang.org/doc/master/extra/arc/struct.Mute...

> Rust is not aimed at high performance applications - I dont see anything wrong with that statement.

Rust is aimed at high performance applications and has been since day one.

Re: A glimpse into a new programming language under development at Microsoft

#225
post #31

This is going to be horribly negative so a bit of context first: I'm a professional C# programmer. I love C#, I think it's a great language. But there's a huge downside: C# only works on Windows. This vastly reduces the number of things you can do with it (yeah, I know about Mono). There's nothing here that suggests that this would have anything other than the same restrictions. So, assuming the language develops int…

> C# only works on Windows

That's not true.

> yeah, I know about Mono

And you know it :-). I agree if you want to express that C# on Linux is a niche. But there're big projects using it in production. Have a look at the Mono project page. Also, have a look at Xamarin.

> can't do mobile, can't do big data, probably won't work very well for scientific computing

There's no language that does all these things well. Java is for Android and big data suited, but not for scientific computing. Fortran, C and C++ are great at scientific computing, but certainly not for mobile (except Qt on niche plattforms). Objective C is not appropriate for big data and scientific computing. Rust and Go aren't the can-do-it-all languages / ecosystems either.

C# and the .NET ecosystem are actually second to Java in terms of reach and versality. Taking Xamarin into account C# has the top spot for mobile.

> equally I worry that it'll be used as a way to generate patents to prevent the ideas being used elsewhere

FUD

Re: A glimpse into a new programming language under development at Microsoft

#226
post #98
post #31

This is going to be horribly negative so a bit of context first: I'm a professional C# programmer. I love C#, I think it's a great language. But there's a huge downside: C# only works on Windows. This vastly reduces the number of things you can do with it (yeah, I know about Mono). There's nothing here that suggests that this would have anything other than the same restrictions. So, assuming the language develops int…

I don't see why Microsoft would create something that would work on other systems....they want people to use Windows.

Of course they want people to use their OS (just like Apple wants people to use theirs), but that does not mean they always lock the language into the OS. They created TypeScript, licensed it under Apache 2.0 and made the installer for it an npm package in Node[1].

[1] npm install -g typescript and it's installed and ready to go wherever you are using Node.js

Re: A glimpse into a new programming language under development at Microsoft

#227
post #109
post #97

Earlier quoted context omitted.

Kotlin seems nice but when's Kotlin going to be "for real"? What I mean by that is, when will it go 1.0? When will we see a major project from Jetbrains implemented in it? Kotlin has been around for a couple of years now and Jetbrains still won't answer these questions as far as I can see[1]. [1] - http://devnet.jetbrains.com/message/5490337?tstart=0

You can start with the latest build. It is that good. There is no need to wait for the 1.0 version.

So you would use a pre-1.0 version with no guarantees of backward compatibility to implement something real? Something that a business depends on, not just something you can toss up on your GitHub page to look cool? I would fire you as soon as we tried to update to a new version and had to spend weeks fixing your now broken code.

Re: A glimpse into a new programming language under development at Microsoft

#228
post #206

Earlier quoted context omitted.

>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.

If you use a C style pointer, it is no longer an abstraction. I don't see what your point is.

Re: A glimpse into a new programming language under development at Microsoft

#229
post #206

Earlier quoted context omitted.

>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…

> For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?). No, the heap primarily uses unique ownership, which is equivalent to malloc/free. Reference counting is an option (and mark/sweep in the future) but idiomatic Rust only uses reference counting where it is necessary. > Secondly from my initial use of Rust I dont think you cannot protect a chunk of data with a lock and share…

So are you confirming or denying that Rust is about zero-cost abstraction? Because it sounds like you're saying if you don't use any abstractions, its zero cost :)

Anyway, I don't have anything against Rust. I cheer for their success.

Re: A glimpse into a new programming language under development at Microsoft

#230
post #159

Earlier quoted context omitted.

It looks like you have a very narrow perspective on C#. I've never tried running .net on a non-windows platform, so I can't comment in that space. I'll leave that to someone else. As someone who's built bespoke big data applications, scientific computing (if we're both talking about large scale computation for analytics), desktop applications, server applications/services, and web sites (one of which is within the US…

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…

There is Hadoop, Microsoft have been pursuing it aggressively recently.

SciPy type stuff is best handled using F#, which also works on Mono, and has some features that I haven't seen in any other languages (e.g. Type Providers).

There are multiple .NET web frameworks, including Microsoft's own ASP.NET MVC and Web API, but also OSS efforts like FubuMVC, Nancy, ServiceStack, Simple.Web and more, most of which work as well on Mono as on MS .NET.

As you say, the Node story on Windows has improved lately, and most current languages work as well on Windows as on any other platform.

C# itself is probably second only to JavaScript in terms of cross-platform development: Xamarin for Mac and mobile; Mono for Linux (yes, it's incomplete, but Linux people should be used to that); Unity for game development across consoles, mobile devices, web and traditional PCs. By "cross-platform" I don't necessarily mean write-once-run-everywhere, which results in lowest common denominator dreck anyway, but the ability to reuse your skills and some code in many different environments and domains.

Post reply on HN