Roborio and Swift?

[Aero]

Originally Posted by Arhowk

No idea what "Go" is but 1684 will be doing JavaScript next year (if I'm still on the team) (or a custom language still being developed if time allows). The only reason that we didn't do it this year was that plans for a backup roboRIO fell through.

// just looked up "Go"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

// just looked up "Javascript"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

[virtuald]

Go actually has *better* generic programming, sorta. It would be cool to use in FIRST.

[Fauge7]

I just dont get why you would do mono/c#, java has the same syntax as the library is more mature

[Arhowk]

Originally Posted by Aero

// just looked up "Javascript"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

Javascript indeed has type inheritance, assertions (console.assert(expression, object)), generic programming, and some operator overloading through "valueOf" hacks.

Javascript does not need method inheritance due to it's loose type definition, is built to avoid circular dependencies, and has no concept of pointers so pointer arithmetic is pointless.

Please attempt to be less aggressive next time.

Go actually has *better* generic programming, sorta. It would be cool to use in FIRST.

Meh. It has something. Whether or not it can be considered conventional "generic" programming is debatable.

I just dont get why you would do mono/c#, java has the same syntax as the library is more mature

It's just preference. Plus, alot of the Java library is inaccessible on the roboRIO since it's primarily graphical. (though the same and more can be said for C#)

[connor.worley]

Originally Posted by Aero

// just looked up "Javascript"

no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

Why would you need any of these features for an FRC robot? Proper inheritance and overloading is a comfort thing, but the rest are mostly useless in an FRC context.

[Monochron]

Originally Posted by connor.worley

Why would you need any of these features for an FRC robot? Proper inheritance and overloading is a comfort thing, but the rest are mostly useless in an FRC context.

Educational probably. Especially pointer arithmetic, that is a nearly daily part of my job.