Hi, A bit of context first.
I'm working on building a full stack web framework in the tradition of Rails and Django (https://github.com/essenciary/Genie.jl). And not only that I use Julia for general purpose programming, I also come from a completely different background, doing almost exclusively web development for all my professional life (15 years now of Ruby, PHP, JS, etc). I'm building the framework from the outside in: developing a project and abstracting away common features into the framework. Here's the first project I deployed: http://genieframework.com/packages. It's been very stable, running for over 3 months now, no issues whatsoever. I'm now working on the second project, a blogging platform. Currently at about 5K lines of code, framework + implementation. It's not very big, but it's something. Now, to answer your questions: 1. I've had a good experience with Strings. Can't comment about 0.5 as I'm still on 0.4.6 but so far so good. The heaviest things I did with strings were part of a templating system, parsing HTML files, extracting markup, etc. Dealing with hundreds of lines of HTML or files of tens of KB like a hot knife through butter. Of course, depending on your use case, milage might vary. Some things that stroke me as weird-ish about Strings: a. ASCIIStrings vs UTF8Strings. Say you work with external generated content that you get from a DB (or web or whatever). Depending on the actual content of the string, Julia will generate an ASCIIString or a UTF8String. And they don't automatically convert between each other, so if you expect one type and get the other, you'll get an error. So I ended up using AbstractString everywhere the type of string I'll get was unknown (which was almost everywhere) - but using Abstract types is a performance no-no according to the docs. So if any of the experienced Julia users could recommended a way to deal with this, that'd be awesome! I kept pondering about this but could not find a definitive answer. b. indexing into UTF8 strings. Can bite if you're not careful, but Julia provides the necessary API to deal with this plus proper documentation. Just keep it in mind. 2. I did a bit of thinking on this one when implementing the ORM. You know, have your objects map to database tables, with one class per table and one instance per row, with properties mapped to table columns. So these types would be defined by the users of the framework, modeled according to their DB tables. And the framework provides a rich API for working with these objects and interacting with the underlying DB (all CRUD operations) without touching SQL. Traditionally, in Ruby or PHP, these models inherit from a base Model class and get all the needed behavior. In Julia I obtained the same effect by employing parametric methods. I have defined an AbstractModel and all the user models would extend it. And all the methods operate on {T<:AbstractModel}. Works great! 3. a common design pattern in web frameworks in the mainstream OOP languages is to map standard CRUD operations to certain controller methods (by convention). So you'll have index() for listing, show() for one item, create() for adding, update() for updating, etc. All these methods take the same single param, which provides them context (usually data related to the request). Another design pattern is that you'll have a controller for each business object - and each controller will have the mentioned methods for manipulating its data. You can probably see where I'm going with this: the need to have lots of methods with the same name and same param and having to invoke the right one. In standard OOP, you have a controller class for each business object and the methods are encapsulated (ClientController, UserController, ProductController). Then you invoke the one you need. I approached things in the same manner in Julia - but this was kind of bad. I was forced to create empty concrete controller types just to be able to use them as additional params, to allow me to invoke the correct method. That felt crappy so I refactored my code to use modules instead of types for defining the controllers and it works great! So the point is, sometimes (many times?) you can't port design patterns from another language using the exact implementation. In both cases above, ORM and Controller, you need to take the core idea and implement it the Julia way. Otherwise you'll just force yourself onto the language and the end result will be suboptimal. 4. I already touched this above - it's core, you can't live without it. And you should't try to. If you want to use Julia, that is core Julia and you need to embrace it as such. It takes a bit of getting used to, but once it clicks, it's natural. I'll close by touching on another aspect of Julia for general purpose programming. The community is great and all the Julia "seniors" are awesome, super-super helpful! I can't begin to explain how many times I reached for help and every single time I got the answer I needed. I want to thank everybody, again, for their time and their support. However, Julia, at this point, is by far and wide a language used for scientific computing. The vast majority of its users are doing this and only this. So until Julia becomes a mainstream language, be prepared for a lonely ride. From the perspective of web development for example, you can't expect the level of collaboration and enthusiasm that you'd get if you'd put your efforts into a language with a focus on web development, like say Elixir or JavaScript. But in order to get there eventually, somebody needs to start from scratch. And after looking very carefully at over 20 languages in the last 2 years, I truly believe Julia has the potential to be a game changer due to it being compiled, its speed, its parallel computing API, its simple syntax and least but not last its power in dealing with large amounts of data. Cheers! marți, 23 august 2016, 14:39:26 UTC+2, JColn a scris: > > Hello, > > I'm looking at Julia for general purpose programming and things look good > so far. However, I want to see if I can elicit feedback from those that > have ventured deeper into larger projects before moving further. Below > are questions regarding areas of concern I've seen cited and I'm wondering > if these issues are real. If anyone can provide experience I would be much > obliged( My frame of reference is python). > > 1. Strings. Are they faster in 0.5 (python speed or better). How about > ease of use? > > 2. Inheritance- Any issues with not being able to do concrete inheritance? > > 3. Module system and dispatch- Lots of Ink has been spilled on this, and > I understand that organizing multi dispatch code is an open research > question. However, it seems there are legitimate concerns about name > clashes,ease of use etc I've also perused some open issues, but don't see a > fundamental redesign. How does Julia fare for larger general projects > compared to say python or java> > > 4. Multi dispatch. How do you find its utility for non numerical code? > > Thanks! > > >
