On 2014-12-21 19:31, Sean Kelly wrote:

> I was following the original RoR book.  I got bogged down in setting up
> the DB and wiring everything together.

The default settings will use SQLite and if you're on a Mac that will already be installed. That means you don't have to do anything. For anything else, just add the address, the database and account information. Run "rake db:create" to create the database and "rake db:migrate" to migrate any changes you make to the database via Rails.

I have had problems with Rails, but never getting started. Well, I suppose it's easy when you know how to do it.

-- 
/Jacob Carlborg

I tried Ruby back in I think 2008 and had just an absolute beast of a time getting it running on the servers. PHP, by contrast, almost just worked.

RoR is a lot better now than it was at that point, though I'm still not impressed with it. I do some work stuff with it and often hit pretty random seeming problems:

1) versions don't match. Stuff like rvm and bundler can mitigate this, but they don't help searching the web. Find a technique and try it... but it requires Rails 2.17 and the app depends in 2.15 or something stupid like that. I guess you can't blame them for adding new features, but I do wish the documentation for old versions was always easy to get to and always easily labeled so it would be obvious. (D could do this too!)

2) SSL/TLS just seems to randomly fail in applications and the tools like gem and bundle. Even updating the certificates on the system didn't help most recently, I also had to set an environment variable, which seems just strange.

3) Setting up the default WEBrick isn't too bad, but making it work on a production system (like apache passenger) has been giving us trouble. Got it working for the most part pretty fast, but then adding more stuff became a painful config nightmare. This might be the application (based on Rails 2 btw) more than the platform in general, but it still irked me.

4) It is abysmally slow, every little thing takes forever. DB changes, slow. Asset recompiles: slow. Tests: slow. Restarting the server: slow. The app itself: slow. I'm told Ruby on the JVM is faster though :)


My main problems with ruby on rails though are bad decisions and just underwhelming aspect of actually using it. Everyone sells it as being the best thing ever and so fast to develop against but I've seen better like everything. Maybe it was cool in 2005 (if you could actually get it running then...), but not so much anymore.

On Thursday, 18 December 2014 at 08:56:29 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 18 Dec 2014 08:09:08 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On Thursday, 18 December 2014 at 01:16:38 UTC, H. S. Teoh via Digitalmars-d wrote:
>> > On Thu, Dec 18, 2014 at 12:37:43AM +0000, via Digitalmars-d wrote:
>> >> Regular HD I/O is quite slow, but with fast SSD on PCIe and a good
>> >> database-like index locked to memory…
>> >
>> > That's hardly a solution that will work for the general D user, many of
>> > whom may not have this specific setup.
>> 
>> By the time this would be ready, most programmers will have PCIe interfaced SSD. At 100.000 IOPS it is pretty ok.
>
> didn't i say that the whole "64-bit" hype sux? ;-) that's about "memory
> as database".

Heh, btw, I just read on osnews.com that HP is going to create a new hardware platform The Machine and a new operating system for it based on resistor based non-volatile memory called memristors that is comparable to dram in speed. Pretty interesting actually:

http://www.technologyreview.com/news/533066/hp-will-release-a-revolutionary-new-operating-system-in-2015/

On Sunday, 21 December 2014 at 10:00:36 UTC, Russel Winder via Digitalmars-d wrote:
> Although the vast majority of Java is used in a basically I/O bound
> context, there is knowledge of and desire to improve Java in a CPU-
> bound context. The goal here is to always be as fast as C and C++ for
> all CPU-bound codes. A lot of people are already seeing Java being
> faster than C and C++, but they have to use primitive types to achieve
> this. With the shift to internal iteration and new JITS, the aim is to
> achieve even better but using reference types in the code.
>

That is quite a claim. If it is true in some context, and I'd go as far as to say that vanilla code in C/C++ tend to be slower than the vanilla version in java, ultimately, C and C++ offer more flexibility, which mean that if you are willing to spend the time to optimize, Java won't be as fast. Generally, the killer is memory layout, which allow to fit more in cache, and be faster. Java is addicted to indirections.

On Monday, 22 December 2014 at 17:25:48 UTC, deadalnix wrote:
> On Sunday, 21 December 2014 at 10:00:36 UTC, Russel Winder via Digitalmars-d wrote:
>> Although the vast majority of Java is used in a basically I/O bound
>> context, there is knowledge of and desire to improve Java in a CPU-
>> bound context. The goal here is to always be as fast as C and C++ for
>> all CPU-bound codes. A lot of people are already seeing Java being
>> faster than C and C++, but they have to use primitive types to achieve
>> this. With the shift to internal iteration and new JITS, the aim is to
>> achieve even better but using reference types in the code.
>>
>
> That is quite a claim. If it is true in some context, and I'd go as far as to say that vanilla code in C/C++ tend to be slower than the vanilla version in java, ultimately, C and C++ offer more flexibility, which mean that if you are willing to spend the time to optimize, Java won't be as fast. Generally, the killer is memory layout, which allow to fit more in cache, and be faster. Java is addicted to indirections.

If one is willing to spend time (aka money) optimizing, there are also a few tricks that are possible in Java and used in high frequency trading systems.

Latest as of Java 10, indirections in Java will be a thing of the past, assuming all features being discussed make their way into the language.

C and C++ are becoming a niche languages in distributed computing systems.

--
Paulo

On 2014-12-21 20:37, Adam D. Ruppe wrote:

> 1) versions don't match. Stuff like rvm and bundler can mitigate this,

I'm not exactly sure what you're meaning but using Rails without bundler is just mad.

> but they don't help searching the web. Find a technique and try it...
> but it requires Rails 2.17 and the app depends in 2.15 or something
> stupid like that. I guess you can't blame them for adding new features,
> but I do wish the documentation for old versions was always easy to get
> to and always easily labeled so it would be obvious. (D could do this too!)

This page [1] contains documentation for Rails, for 4.1.x, 4.0.x, 3.2.x and 2.3.x. It's basically the latest version of a given branch. This page [2] contains the API reference for Rails, it's not easy to find but you can append "vX.Y.Z" to that URL to get a specific version.

> 2) SSL/TLS just seems to randomly fail in applications and the tools
> like gem and bundle. Even updating the certificates on the system didn't
> help most recently, I also had to set an environment variable, which
> seems just strange.

I think I have seen that once or twice when upgrading to a new version of OS X. But that's usually because your gems and other software is still built for the older version. I can't recall seeing this for a new project.

> 3) Setting up the default WEBrick isn't too bad, but making it work on a
> production system (like apache passenger) has been giving us trouble.
> Got it working for the most part pretty fast, but then adding more stuff
> became a painful config nightmare. This might be the application (based
> on Rails 2 btw) more than the platform in general, but it still irked me.

I haven't been too involved in that part. I have set up one or two apps with passenger and it was pretty easy to just follow the installation. Although, that wasn't production servers.

> 4) It is abysmally slow, every little thing takes forever. DB changes,
> slow. Asset recompiles: slow. Tests: slow. Restarting the server: slow.
> The app itself: slow. I'm told Ruby on the JVM is faster though :)

Yeah, that's one major issue. It can be very, very slow. But I also think it's too easy code slow with something like ActiveRecord. It's easy to forget it's actual a database behind it.

> My main problems with ruby on rails though are bad decisions and just
> underwhelming aspect of actually using it. Everyone sells it as being
> the best thing ever and so fast to develop against but I've seen better
> like everything. Maybe it was cool in 2005 (if you could actually get it
> running then...), but not so much anymore.

I find it difficult to find something better. I think that's mostly because of the existing ecosystem with plugins and libraries available. I feel the same thing with D vs Ruby. At some point I just get tired with developing my own libraries and just want to get something done.

[1] http://guides.rubyonrails.org/
[2] http://api.rubyonrails.org

-- 
/Jacob Carlborg

On Mon, 22 Dec 2014 15:36:27 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Heh, btw, I just read on osnews.com that HP is going to create a new hardware platform The Machine and a new operating system for it based on resistor based non-volatile memory called memristors that is comparable to dram in speed. Pretty interesting actually:
> 
> http://www.technologyreview.com/news/533066/hp-will-release-a-revolutionary-new-operating-system-in-2015/

yes, i read about that some time ago. it's fun conception, yet they will be forced to emulate files anyway. i.e. such machine can be either "only one user, only one task" (a-la Oberon, for example), or a mad to program. everyone using files today, and nobody will write everything again for some OS without files.

so it will be a toy, or will try hard to emulate current arch. either way nothing new from the programmer's POV.

On Monday, 22 December 2014 at 21:05:22 UTC, Paulo Pinto wrote:
> C and C++ are becoming a niche languages in distributed computing systems.
>

That is quite a claim.

Even with new java feature, you'll certainly reduce java's indirection addiction to some extent, but that won't give you control of data layout, which is one of the highest criteria when it comes to speed (because you fit more in cache).

Granted, when it come to distributed computing, you have many problem to manage (network, node failing, sheduling, ...) and how much you can feed to the CPU is one criterion amongst others.

I also concede that making thing in Java and getting them fast enough is a much easier job than it is in C++.

On Tuesday, 23 December 2014 at 13:56:51 UTC, deadalnix wrote:
> On Monday, 22 December 2014 at 21:05:22 UTC, Paulo Pinto wrote:
>> C and C++ are becoming a niche languages in distributed computing systems.
>>
>
> That is quite a claim.
>
> Even with new java feature, you'll certainly reduce java's indirection addiction to some extent, but that won't give you control of data layout, which is one of the highest criteria when it comes to speed (because you fit more in cache).
>
> Granted, when it come to distributed computing, you have many problem to manage (network, node failing, sheduling, ...) and how much you can feed to the CPU is one criterion amongst others.
>
> I also concede that making thing in Java and getting them fast enough is a much easier job than it is in C++.

It is as you say, the problems to solve around the application have a bigger impact than the language itself.

On our use cases, a few hundred ms are acceptable as response times, so it isn't worth developer time to squeeze every ms out of the CPU.

My claim is based on the fact, that on my little enterprise world I see C++ being stuffed inside legacy boxes in architecture diagrams.

C++ code is equated with CORBA and DCOM components that are still somehow kept alive.

--
Paulo

On 12/21/14 1:59 AM, Russel Winder via Digitalmars-d wrote:
>
> On Sat, 2014-12-20 at 15:16 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 12/6/14 7:26 AM, Russel Winder via Digitalmars-d wrote:
>>> Primitive types are scheduled for removal, leaving only reference
>>> types.
>>
>> Wow, that's a biggie. Link(s)? -- Andrei
>
> Simon Ritter laid out the OpenJDK/JCP/Oracle thinking way back in 2011
> in a number of conference presentations. cf.
> http://www.slideshare.net/JAX_London/keynote-to-java-se-8-and-beyond-simon-ritter page 41 has the explicit statement of goal for JDK10. OK so this was
> pre-JDK8 and reality has changed a bit from his predictions, but not
> yet on this issue.
>
> There are changes to the JIT for JDK9 and JDK10 that are precursors to
> removing primitive types, so as to get rid of the last unnecessary
> boxing and unboxing during function evaluation. Expression evaluation
> is already handled well with no unnecessary (un)boxing.
>
> Many see "value types" cf JEP 169 http://openjdk.java.net/jeps/169 as a
> necessary precursor, but it is not exactly clear that this is actually
> the case. It's a question of which JIT is part of the standard
> reference implementation (OpenJDK) and what suppliers (e.g. Oracle,
> IBM, Azul, etc.) ship in their distributions.
>
> Although the vast majority of Java is used in a basically I/O bound
> context, there is knowledge of and desire to improve Java in a CPU-
> bound context. The goal here is to always be as fast as C and C++ for
> all CPU-bound codes. A lot of people are already seeing Java being
> faster than C and C++, but they have to use primitive types to achieve
> this. With the shift to internal iteration and new JITS, the aim is to
> achieve even better but using reference types in the code.
>
> There are an increasing number of people from Oracle, IBM and Azul
> actively working on this, so it is a well-funded activity. Targeting
> JDK10 means they have 2 years left to get it right :-)

Hmmm... On one hand there's "make everything objects" in the slides, and on the other hand we have the JEP that adds value types. Confusing.

Andrei