161–170 of 255 posts
The one thing that would put rust over the top right now is something along the lines of gofmt - something simple, with zero configuration, that can be run on commit or even save.
gofmt is a huge win for Go. Bye bye bikeshedding. I'd love to see that for Rust too.
I've been incredibly impressed by the willingness of the Rust team to take a step back and re-evaluate old decisions. I think this 1.0 release will be much better for all the iterations put into e.g. dynamically sized types and other things that never quite fit in their first half-dozen iterations of the design. Congrats all!
Well, there's been some buzz about rust in the haskell community, which piqued my interest. And now it's time to give it a look.
Earlier quoted context omitted.
One reason is that let takes a pattern, so you can do things like: let (x, mut y) = ... Another reason is that we feel 'mut' more cleanly communicates mutability than 'var.' Another reason is that we prefer immutability by default, and let/var doesn't communicate that as nicely as let and let mut. There are some discissions about this on the ML archives, RFC repo, or discuss, if you're interested.
let (x, var y) = ... can easily express the intention. Also, communication is in the ear of the beholder. Var: variable, that varies. 'Let' would be immutable by default. Thanks for the response anyway.
let var x = ...
Earlier quoted context omitted.
Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.
It's good enough when you can configure it and apply it selectively. If I want to clean up a function in my code base, I can e.g. select it and run "perltidy" over it, which has a configuration dot file for the company code standard (or CPAN guidelines etc.). Or just clean up some nags so that version control behaves better. But if the only option is not running it at all or having all the code automatically fit to w…
Earlier quoted context omitted.
I haven’t tried Go yet, but gofmt seems like something that every new language should strongly consider.
FWIW, C++ already has it with clang-format
Earlier quoted context omitted.
> Duck would have a GameObject, rather than be a GameObject Duck should not be a class, it should be a factory function that creates a generic GameObject and configures it with the set of components that allows it to look, walk and quack like a duck.
Can you elaborate on the reasons for that?
It's also much easier to data-drive entity types; at some point you will even do away with factory functions for GameObject types and describe these types in data files loaded at runtime. This opens up options for designer-friendly editing tools and even 3rd party modding.
Earlier quoted context omitted.
> I think Python and Go are two examples where the standard library has very much proven invaluable. C#. The amount of time I've wasted in Java programming teams while arguing over things like which of three quirky XML parsing implmentations[1] was the One To Use while the .net team powered off and built useful functionality... [1] This was a few years ago, obviously.
So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. Quite an odd view from a software engineer. I like having as much choice as possible.
I prefer to get things done.
Earlier quoted context omitted.
We have them.
Like three different kinds, too! // Old-style generics; monomorphized // with S as an "input" type of MyTrait fn foo >(elem: T) { ... } // Where-clause-style generics; monomorphized, // with S as an "output" (associated) type of MyTrait fn foo (elem: T) where T: MyTrait { ... } // Trait objects; dynamic dispatch fn foo(elem: Box ) { ... }
Being a game developer, inheritance is a really important language feature. I'm not one to abuse the power. Currently, for school I've been working on an OpenGL game engine in C++. It's a component based system. The only real inheritance situation that's important to me, is to allow the user of the engine to create any object and make it inherit from GameObject (example: Duck would inherit the members and methods fro…