Nope... US$120k is most likely the base price (car + taxes). The Certificate of Enrolment (CoE) is market rate, and right now it's an additional SG$85k to SG$111k depending on the vehicle category (on top of the base price).
I read that flyer as the price of the car plus COE. The "Excite Package" Dolphin lists "Guaranteed COE" for $165,888 Singapore dollars ($122,505 USD) all in.
>In Singapore, most people typically purchase new vehicles through dealers. Dealers will collect orders from customers and participate in the COE bidding on behalf of their customers.
>Supply and demand set the price for COE, which regulates demand. When COE prices are high, vehicle prices, as quoted by dealers, will have to increase, reducing demand. When COE prices are lower, dealers can afford to reduce prices if they want to, which will increase demand.
I looked into Vue + Webpack vs Vue + Brunch on my last project. I ended up with Brunch because the requirements are fairly basic and Brunch are easier to grok. Had the requirements be a little bit more complex, I could have easily gone for Webpack.
IMO, there are a few key things lacking with the Vue + Brunch combo:
- The `sass-loader` plugin allows me to use Sass dialect in SFC-style Vue (Single File Component). I'm using plain CSS with Vue + Brunch SFC as I cannot find a Brunch plugin offering similar functionality.
- There are some Brunch idiosyncracies. For one, the processing pipeline is executed as per `package.json` (dev)Dependencies ordering. I spent quite a bit of time before figuring this out.
I believe these are referred to Railway-Oriented Programming. I've seen several other examples for Elixir (incl. ones using macros), but by far this is the 'cleanest' syntax :)
Here's a similar construct in Scala:
(for {
user <- currentUser(...)
group <- groups.fetchForUser(...)
friend <- friendships.fetchFriend(...)
member <- groups.addMember(...)
} yield {
render(...)
}).recover {
case e: Exception -> ...
}
The Scala example, yes... The Elixir one? Is it actually a Monad? I figure it's simply destructuring + pattern matching (against the value of the first tuple value, :ok or :error atom).
To expand a bit more, it's not like Scala's `Either[T, U]` where we're limited to a pair of types, I think you can return other atom values (but use :ok and :error) as a convention.
Also, there is an Elixir library I'm using that's a closer in spirit to Scala's for-comprehension called `monadex`. Example below:
result = success(comment_params)
~>> fn p -> link_reply_to_id(p) end
~>> fn p -> create_changeset(p) end
~>> fn cs -> assert_changeset(cs) end
~>> fn cs -> insert_changeset(cs) end
> Scala core library is littered with :: +: and other nonsensical operators.
They are very useful. With the two you mentioned (:: and +:) they can be used for pattern matching in addition to concatenation (of a list / sequence), for example:
scala> val list = 1 :: 2 :: Nil
list: List[Int] = List(1, 2)
scala> val x = list match {
| case head :: _ => head
| case _ => 0
| }
x: Int = 1
scala> val seq = 1 +: Seq(2, 3) :+ 4
seq: Seq[Int] = List(1, 2, 3, 4)
scala> val y = seq match {
| case a +: _ :+ b => a + b
| case _ => 0
| }
y: Int = 5
It can be a bit confusing at first, especially for mutable vs immutable collection operators. But you end up remembering some, if not most of it, after using them a number of times.
and that's what I meant, when I said niche use cases. You can replace all operators with names and still have no difference. At some places code will be verbose, but on whole code will be more readable. Another example if you want is http://www.scala-lang.org/api/2.9.2/scala/sys/process/Proces.... All operators can be replaced by completely readable names like run, build, read, write.
Scala on whole is optimized to have lesser no. of characters in code, in contrast to verbosity of Java. Case classes and lambdas are what good came out of it, I understood the concept and now I can use them. Operator overloading and Implicit are what move pendulum to other side, they are not some novel concept and make very readable code, unreadable.
Why do we use operators at all? We can just as easily write out plus, minus, multiply, and divide.
Concatenating to a list and pattern matching are extremely frequent operations in Scala. Some of the operators they use have been in use for decades in the languages that influenced Scala.
Like many features across many languages it can be taken too far at times and people that enjoy Scala talk about them all the time. That said, the similarities of your example to operators I use at the command line every day makes it nice to read for me.
IMO the ProcessBuilder class is not a very good example, as the operators are designed to match the existing shell / bash ones (e.g. `#>>` is similar in behaviour to bash's `>>`).
I'm currently working with Scala and recently dabbling with Elixir and Phoenix. It's a good language and great platform, however, I still prefer static typing.
I'm still getting used to dynamic typing in Elixir. Most of the time I feel like just matching against Map data structure or records.
While Dialyzer is great, writing the typespecs is a bit of a maintenance overhead. I suppose it's a tradeoff...
> I came to Elixir from Scala, [..] now I don't have to deal with the half of the Scala community that tries to make Scala into Haskell.
IMO Scala will continue to be a multi-paradigm lang. On pure-FP and libs, it's a choice and really depends on the problem domain. It might not be a good solution to everyone, but I'm glad it exists.
I think of Elixir typespecs as documentation more than as overhead. Given that I'm writing comments that tell the shape of the inputs and outputs of every function anyhow, I might as well do it in a way that lends itself to static analysis. :)
> Nothing really changed, you could write Android apps on Kotlin before, as well as on any other JVM language. But now "Kotlin is the hero".
The announcement shows Google making a commitment to make Kotlin successful in Android, rather than leaving the effort all to the community and JetBrains.
> I suspect that Google's adoption of Kotlin is just politics: [...] Google could acknowledge Scala years ago, but didn't [...]
In regards with the Scala evolution, there's a lot of things to be excited about. In the near term, 2.13 should see various optimisation to core libraries and faster compilation.
> Also, I don't understand the point of Kotlin. [...] Kotlin is just a subset of Scala. [...]
Kotlin is a better Java, whereas Scala is much, much more.
Scala is still my go-to JVM languages, but one Kotlin use case for me is to write libraries that will be called from Java [1]. Its biggest advantage is that it's succinct, has useful functional features (e.g. Scala-like collections), while producing code signatures that's very close to Java.
You can load balance your app for 3.5k $ on additional server. By reducing load, time spend in GC will be less. Additionality by having more hardware you can use more aggressive strategy[0].
I have taken Zing for a spin on 24 c3.8xl ec2 instances running Elasticsearch with 32G heaps and just under 2 billion indexed documents with millions of updates/day. The results are considerably better. If I just went up to 30 or even 50 ec2 instances on HotSpot/Openjdk, I would see no performance benefit with regard to GC. And I have performed this test. I'm not saying dont use Java because of GC, but I am saying don't overestimate the value of more efficient garbage collection in any case.
Shoutout to the Azul guys, Simon, Elaine and Paul for coming on-site and watch me compile all their extensions on Amazon Linux and help me perform all the testing.
Besides the benefits the new JIT provides, Zing will help you if your workload runs with / consumes over 8GB of RAM. At this point, HotSpot GC pauses [1] starts becoming noticeable (i.e. jitter).
For me it brings a lot of benefits: easier to find parts, consumer-level parts pricing, and lower TDP.
I'm running a dual Xeon as you mentioned, through buying ex-fleet parts at less than half price of new ones. Several issues I experienced:
- Lack of motherboard options. I had to purchase new motherboard at a high price since the ones that support dual Xeons are either in an incompatible form factor or simply out-of-stock. I settled with Asus Z9PE-D8 WS with an SSI-EEB form factor.
- Outdated BIOS. I had to order a new, pre-flashed, BIOS chip since the BIOS that came with the motherboard refused to boot with the CPU and memory combo.
- Hard to find suitable ECC RAM. The motherboard only supports limited RAM (speed + latency) configs, and finding those is becoming harder. Availability looks seasonal at times.
- Needs capable power supply. One thing that people often look past is the need of a proper PSU. I had to upgrade to one which support two CPU power connectors.
I'm running a similar setup to yours (IIRC I have the same mobo even), but I'm quite happy with it. I got new Xeons (1630 e5 @ 3.7 ghz), RAM compatibility was not something I found an issue (we're talking +/- 5 months ago here), power supply - I got a 1000W PS anyway to power several GPU's, I guess at that level they come with several connectors standard and I just didn't run into it as an issue. To be honest though I went for Xeon to get ECC, so if these new AMD's support that, then maybe next time...
What is SIMD support like for Ryzen? Does it do avx2 or something similar?
It's true that server components are generally loud. If you have the room, I recommend my setup - which is to have a (home build) rack in the basement, and run long DisplayPort cables (and USB extension cables) to the desk. Or build a closet around a rack in an office, which can be soundproofed. This does push it to the next level in terms of work involved, obviously (and cost as well if you don't have tools or time to DIY most of it).
Most programming related workloads I can think of hardly benefit from avx2. Also, the additional power draw while using avx on intel is considerable, despite the clock rate drop; so perf/watt may not be as much behind as one might initially think.
This downside is likely to become slightly more serious as time goes on and more software uses avx2; but it's certainly not crippling.
Proper cases can be hard to come up with (new they are rather expensive), e.g. I can't do anything with a 85 cm deep pizza box in my rack (because that pizza box is like 15 cm longer than the whole thing), so I needed a bit more special case, which has space for a standard 2S board but is short as well. Only Supermicro had one of those.
Yeah, this is another problem that I had. Plenty of full-tower cases these days support EATX, but SSI-EEB not so much (at least, the ones that can support it out-of-the-box).
In the end, I went with one of the Phanteks Enthoo [1] cases. Decent quality without breaking the bank :)
https://www.motorist.sg/coe-results https://bydcars.sg/wp-content/uploads/2025/01/BYD-Pricelist-...