Why. Seriously. Why. Whatever happened to domain-specific languages.
Pushing Swift to the Server
71–80 of 109 posts
Re: Pushing Swift to the Server
#72Earlier quoted context omitted.
Even assuming it's true, that's not an impressive claim. Frameworks in those three languages are not known for their speediness. If they claimed 1000 times, maybe that would be something worth sitting up to take notice.
Because having 100 less resources with similarly convenient language is something to sneer at...
When there are at least 4 such languages/runtime implementations that exist already and have more libraries that also "have 100 less resources" then, yes, that one claim is a lot less special.
Re: Pushing Swift to the Server
#73For Swift on the server you only need an editor like Sublime, Atom, or whatever suits your fancy. That's it, nothing else. Get one of the most popular frameworks like Kitura, Vapor, Perfect, Zewo or the dozens of smaller ones and be ready to deploy to Heroku, Bluemix, AWS, Google Cloud, Digital Ocean in no time. It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a coup…
you always need at least compiler/interpreter to execute your code... unless write bytecode in your editor
Re: Pushing Swift to the Server
#74Earlier quoted context omitted.
The times are changing, hence why Java 10 has better support for some form of value types, improved generics, JNI replacement and AOT compilation on its roadmap.
All good stuff. But I have heard JNI is already multiple times faster than Go's cgo stuff so I wonder what could be improved there.
According to Mark Reinhold, Sun designed JNI to be hard on purpose, to discourage developers to write native code.
He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones.
Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code from Java should be something like P/Invoke on the CLR. Similarly calling into Java APIs from native side should have less ceremony setting up what to call.
Additionally there should be a standard support for integrating GPGPU into Java.
As it was deemed too complex to be ready by Java 9 timeframe, it ended up being scheduled for 10+ roadmap.
For the latest status check "Going Native" at JVM Language Summit 2016.
https://www.youtube.com/watch?v=JR1zI5gLhRM&index=13&list=PL...
Re: Pushing Swift to the Server
#75No, I don't want to share models between the client and the server. I want an API dependency between them, a code dependency is actually worse. Why should the frontend change when the backend changes it´s abstractions? I want to change them independently, because they have different constraints and dependencies. If you are implementering your database schema in the frontend, you´re doing it wrong. An API is a view ag…
Are you suggesting something like http://espresso.caffei.net/ ?
Re: Pushing Swift to the Server
#76For Swift on the server you only need an editor like Sublime, Atom, or whatever suits your fancy. That's it, nothing else. Get one of the most popular frameworks like Kitura, Vapor, Perfect, Zewo or the dozens of smaller ones and be ready to deploy to Heroku, Bluemix, AWS, Google Cloud, Digital Ocean in no time. It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a coup…
Are you developing any iOS apps in Swift? How might I contact you to ask about your experience so far?
Re: Pushing Swift to the Server
#77Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)
While Swift will compile on different backends now, XCode is still the premiere Swift dev environment and will be for a good while. So a non Mac Swift dev won't be having a great time. The target market is really iOS devs who want the same language on the back end. That's a perfectly reasonable engineering goal for an iOS-first shop. But they're a vocal group and like to hype up server Swift as the next big thing for…
Given all the complaints about XCode & Swift, I would say that it's not a huge advantage.
Re: Pushing Swift to the Server
#78For Swift on the server you only need an editor like Sublime, Atom, or whatever suits your fancy. That's it, nothing else. Get one of the most popular frameworks like Kitura, Vapor, Perfect, Zewo or the dozens of smaller ones and be ready to deploy to Heroku, Bluemix, AWS, Google Cloud, Digital Ocean in no time. It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a coup…
proven?
Re: Pushing Swift to the Server
#79Wow. That "same language connected by an interface schema would have prevented Mars mission loss" thing is a really thin stretch.
This submission reminds me of "Satirical hacker news post" """ The Muskonauts figured out why their shit exploded. Hackernews, literally all of whom are actual rocket scientists, wonders if unit tests could have helped. """ Also conveniently forgetting that Computer Scientists are yet to solve types physical dimensions mapping in practical programming language. https://hackage.haskell.org/package/dimensional
Foundation's Measurements aren't bad and it's easy to extend them to do arithmetic.
Re: Pushing Swift to the Server
#80Earlier quoted context omitted.
All good stuff. But I have heard JNI is already multiple times faster than Go's cgo stuff so I wonder what could be improved there.
According to Mark Reinhold, Sun designed JNI to be hard on purpose, to discourage developers to write native code. He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones. Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code fro…
Interesting talk. Go folks also probably want cgo similarly difficult to use. Though for them I guess it will work, as they have already written compiler/GC/runtime/ssl etc in Go plus some asm.