1. We needed to get bills to send to our accounting department. There is no way to get this out of Bluemix. We needed to contact 5 different people and send 2 different support tickets.
2. At one point we couldn't log into our accounts, the authentication server was down.
3. The docker container doesn't always get internet. Also it sure as hell is guaranteed to not have internet if you restart it.
4. If you use their SAAS databases, then some of them you can connect to from the outside world, but some you can't. And there is no way of knowing which.
5. Just because IBM makes a product available doesn't mean it works. We used NodeRED together with the IBM developed database connectors for DashDB. That connector will timeout after ~24 hours and then not throw any errors when you keep writing to it. Took 3 days to figure this out and fix it.
6. Their deploy system is nice, pity it brings down your service for 5-10 minutes even for deploys that are literally 100 lines of java code.
7. It's painfully slow to push images to their docker hub. Took 3 hours to upload an image with ubuntu and java. And our uplink is 50mbit.
I am one of the people working on the IBM container service that's available as part of Bluemix. I am not here in any official capacity, just as someone who wants to understand what the pain points of our customers.
Let me start by saying that I understand your pain. As every product on the market, we have issues occasionally, such as the authentication one you mentioned or the networking. However, these are only exceptions and rarely affect our users, at least as far as we are aware. Did this happen repeatedly or was it a one time occurrence?
With regards to the ticketing system, I believe you are correct. Things are not as smooth as you or I would like them to be. I will pass this on to the management chain.
For the uploading speed of images, I also believe this may be quite rare, since I cannot remember hearing complaints about it. Did this happen on separate occasions?
With that being said, please send us tickets when something is not going the way you'd expect.
The authentication one came right when we were going to shut down our use of bluemix. We reported it directly to IBM here in Norway.
The networking issue in docker happened for a few days. The "fix" from IBM (after a ticket) was for us to add a 30 second sleep to our containers. Needles to say this wasn't a fix we were happy with.
Tickets were also a huge hassle in the beginning. It was a 10 step process just to submit a ticket. It got better after a while.
We didn't file a ticket about the upload speed for images. I just remember sitting in a meeting realizing that the container had crashed, and when I restarted it it had no internet. So I thought, that while I was at it I would just push a new image with some bug fixes. That worked fine and I got a new container with internet, but pushing the image took more time than the meeting lasted without there being large changes to the image.
Swift is gaining momentum fast. It has a big advantage because it's arguably the best way to write iOS apps. It'll replace Objective C as a top 5 used language.
In fact, a quick check of Tiobe shows Objective C heading down fast with Swift about to pass it on its way up:
This is really cool to see. Really hoping to see something similar appear for Swift on Azure or AWS. Also really hoping to see Swift web frameworks begin to appear, now that Swift is open-sourced & running on Linux.
Absolutely. Two days ago (before the open source announcement), I begrudgingly started learning Swift for a school project in iOS development. Now I'm itching to dive into the language.
If you're looking for something similar for other programming languages too, check out https://bit.run/. It supports Ruby, JS, Go, Python, Rust, PHP and many more.
It should be noted that there are some caveats to TypeScript, namely that it's type-safety is only compile-time and not at run-time. It is best-effort type-safety.
That said, the edge cases are few and far between. TS is a fantastic language to work with.
I think the issue you're mentioning isn't so much that TS only enforces type safety at compile time, because that's true of Haskell, OCaml, C++, etc. as well, but that by its nature it can't enforce any type contracts with the large quantity of dynamically-typed JavaScript you're probably going to be dealing with. Of course, this is also an issue when safe Haskell, OCaml, etc. code interacts with compiled C code at runtime as well.
If you're writing iOS apps, Swift is the language to learn.
If you're writing server-side code for Linux/OSX, probably not quite yet. The language is nice, but it's only been available as open-source for a day now... the ecosystem you'd need to be productive in Swift isn't there yet.
(On the other hand, if you'd like to be involved in building that ecosystem, now's probably the time to jump in.)
At the moment, it seems like it would be really nifty to use in hobbyist or small data-crunching projects to get C-like performance [1] with a saner syntax, less memory management issues, etc.
I wouldn't want to use it for anything substantial, but if IBM's already hopping on the bandwagon it seems like a good language to learn for heavier use later on.
Official documentation is here [1], with additional documentation and resources (that are more iOS and OSX specific) available here [2].
In particular, the Swift Programming Language ebook isn't a bad starting point. The IBM Swift Sandbox looks like a nice little interactive environment to complement it, though, if you don't have access to a Mac to run Xcode.
It's open source. Works on Linux, Mac OS X, Android, iOS, Windows, etc. It has a good ecosystem and tooling built around it already but you can also tap into the C# ecosystem, if necessary.
Have you tried kotlin? It is developed by jetbrains, works in the JVM and you can mix java code and kotlin code in the same project. It is still in beta but it has been developed for more years than swift and both look quite similar. Jet brains said they wanted to release the version 1.0 the the end of this year... Plus it is fully integrated in intelliJ idea
I wonder if this was announced as a reaction to Swift going open source. I could see some IBM team working on this system as a POC, and suddenly being given an urgent deadline to coincide with the license change.
Gain from the momentum and maybe turn a pet project into something bigger. I guess that's the benefit of having tens of thousands of developers...
I think that you are right on this, when looking at one of the examples (server.swift) it seems that people are paid by characters typed and they forget (or never heard of) the mantra DRY (Don't Repeat Yourself):
func fdSet(fd: Int32, inout set: fd_set) {
let intOffset = Int(fd / 16)
let bitOffset: Int = Int(fd % 16)
let mask: Int = 1 << bitOffset
switch intOffset {
case 0: set.__fds_bits.0 = set.__fds_bits.0 | mask
case 1: set.__fds_bits.1 = set.__fds_bits.1 | mask
case 2: set.__fds_bits.2 = set.__fds_bits.2 | mask
case 3: set.__fds_bits.3 = set.__fds_bits.3 | mask
case 4: set.__fds_bits.4 = set.__fds_bits.4 | mask
case 5: set.__fds_bits.5 = set.__fds_bits.5 | mask
case 6: set.__fds_bits.6 = set.__fds_bits.6 | mask
case 7: set.__fds_bits.7 = set.__fds_bits.7 | mask
case 8: set.__fds_bits.8 = set.__fds_bits.8 | mask
case 9: set.__fds_bits.9 = set.__fds_bits.9 | mask
case 10: set.__fds_bits.10 = set.__fds_bits.10 | mask
case 11: set.__fds_bits.11 = set.__fds_bits.11 | mask
case 12: set.__fds_bits.12 = set.__fds_bits.12 | mask
case 13: set.__fds_bits.13 = set.__fds_bits.13 | mask
case 14: set.__fds_bits.14 = set.__fds_bits.14 | mask
case 15: set.__fds_bits.15 = set.__fds_bits.15 | mask
default: break
}
}
Given the unfortunate way fd_set apparently got imported, how else would you do this? The only alternative I see is to throw UnsafeMutablePointer at it, but that brings in the ugly specter of undefined behavior. Note that in Swift you cannot use a variable to address a tuple, so there's no way to use intOffset to access the corresponding field of set.__fds_bits.
What you're seeing here is a result of an unfortunate interaction with bridging to C APIs. fd_set is a C struct which contains a fixed-length array. Swift doesn't have fixed-length arrays, so those get translated to tuples instead.
This is not ideal, but it comes up almost never.
As for your suggestion, that seems like an entirely stylistic thing. DRY is about not copy/pasting large chunks of code, not minimizing individual lines by using compound mutate/assign operators. I've never seen anyone say (before!) that something like `x = x + 1` violates DRY.
More importantly nothing about DRY overwrites the ideal that making the intent of your code explicitly clear is more important then fixating on micro optimisations. I feel like the code as it is less easy to misunderstand while skim read.
Here is my experience with Bluemix:
1. We needed to get bills to send to our accounting department. There is no way to get this out of Bluemix. We needed to contact 5 different people and send 2 different support tickets.
2. At one point we couldn't log into our accounts, the authentication server was down.
3. The docker container doesn't always get internet. Also it sure as hell is guaranteed to not have internet if you restart it.
4. If you use their SAAS databases, then some of them you can connect to from the outside world, but some you can't. And there is no way of knowing which.
5. Just because IBM makes a product available doesn't mean it works. We used NodeRED together with the IBM developed database connectors for DashDB. That connector will timeout after ~24 hours and then not throw any errors when you keep writing to it. Took 3 days to figure this out and fix it.
6. Their deploy system is nice, pity it brings down your service for 5-10 minutes even for deploys that are literally 100 lines of java code.
7. It's painfully slow to push images to their docker hub. Took 3 hours to upload an image with ubuntu and java. And our uplink is 50mbit.