"More than 70%" does not mean "More than 70% have their own driveway".
Apartments don't have driveways and underground garages are often hard to retrofit.
I used to live in a block of flats with, I was a director of the management company. We nominally had 1 parking space each, but it wasn't allocated.
We looked into putting in outside sockets, it was fairly low cost, the difficulty would be apportioning the metering as we didn't have allocated parking spaces, but with allocated parking spaces it's not a problem.
On my own housing estate in a typical British town almost every house has a drive. Those with two cars and just one drive that park 1 car on the drive and one on the street, but that's fine, just swap them occasionally (or better yet get rid of the extra car)
I can't think of seeing underground parking anywhere in the UK, other than commercial ones in cities like NCP etc.
> "the difficulty would be apportioning the metering as we didn't have allocated parking spaces"
There are already various technical solutions to this. Most chargers now days are "connected" - ie have a WiFi chip or cellular modem built in to the charging unit. Identification/billing can be apportioned via a RFID card or app interface.
In future, "Plug & Charge" will make it possible for the vehicles to securely identify themselves to the charger for automatic billing, doing away with the need for an app or RFID.
If cost of the chargers is an issue (ie you want a large number of outlets but it's initially split between only a few EV owners who are willing to pay for them), then consider something like Ubitricity (ubitricity.com) where the outlets are "dumb" and the billing smarts are built into the cable which EV owners purchase.
73% parking on private property doesn’t mean 73% have their own driveway, and it was only mentioned that it’s cheap to install a charger in a fairly recent driveway.
I suppose GP’s question is how does that 73% figure change when you look at people who can realistically have a charger installed in their parking spot.
I don't understand the jump from the lack of algebraic types, to using interface{}.
You can spell out all your types into explicit structs (where you can choose between a simple implementation with a little worse performance or to make the implementation a little more complex) and pass them around.
There are many complex code bases (kernels & databases come to mind) which use C (not C++), and they don't resort to passing void* around the "business logic" parts.
The idea that for a complex project you would choose a different language with so many different characteristics due to a minor detail about the type system (this is not exactly Haskell vs JS...). This kind of decision making would not pass in any reasonable organization...
It depends on what you mean exactly by "emulating sum types" and "pattern matching them".
An example is rolling your own discriminated union:
type Avariant struct {
a int
}
type Bvariant struct {
b string
}
type SumChoice int
const (
SumA SumChoice = 0
SumB SumChoice = 1
)
type Sum struct {
type SumChoice
A *Avariant
B *Bvariant
}
sumA := Sum{choice: SumA, A: &{a: 7} }
sumB := Sum{choice: SumB, B: &{b: "abc"} }
func foo (x Sum) {
switch(x.choice) {
case SumA: {
fmt.Printf("Value is %d", x.A.a)
}
case SumB: {
fmt.Printf("Value is \"%s\"", x.B.b)
}
}
}
As usual with Go, it's ugly and verbose and error prone, but it just about works.
The previous poster was probably thinking of something similar but using interface{} (equivalent to Object or void*) instead of Sum, and then pattern matching using an explicit type switch:
func foo (x interface{}) {
switch actual := x.(type) {
case AVariant: {
fmt.Printf("Value is %d", actual.a)
}
case BVariant: {
fmt.Printf("Value is \"%s\"", actual.b)
}
}
}
This is slightly less risky and has less ceremony, but it's also less clear which types foo() supports based on its signature. Since Go has only structural subtyping [0] for interfaces, you would have to add more boilerplate to use a marker interface instead.
[0] In Go, a type implements an interface if it has functions that match (name and signature) the interface functions. The name of the interface is actually irrelevant: any two interfaces with the same functions are equal. So if you declare an interface MyInterface with no methods, it is perfectly equivalent to the built-in `interface{}`: any type implements this interface, and any function which takes a MyInterface value can be called with any type in the program.
On the first approach, with "error prone" you mean the tag could be incorrect, right? (or even have an impossible variant with 0 or multiple variants set).
Yup. Also, there is no exhaustiveness checking (the constants we chose to define for SumChoice(0) and SumChoice(1) mean nothing to the compiler anyway - exhaustiveness checking would have you test any possible int, since SumChoice is simply an alias for int).
But are those two variants held in memory inside Sum or are they heap-allocated sitting out on some other cache line? Can one write a performant Sum type?
With pointers, they are in the heap, but at least there is no overhead. You could also declare them embedded (without the *s), but then the Sum struct would have a size that is a sum of all the variants' sizes, instead of a proper union which should have the max size (more or less).
type Sum struct {
type SumChoice
A Avariant
B Bvariant
}
This is what I meant by saying that it depends on exactly what you mean by "sum types".
Got it. Although I’m not sure what “no overhead” means if the instances have to live way far away on the heap. That means you’ve got an alloc (including a mutex lock), then the value lives far away, then the garbage-collection overhead then the delete. When I think sum-type I think a flag plus storage for the maximum size and alignment type, and all of the above bookkeeping and cache misses go away.
Yes, you're right - I was thinking of "no space overhead", and even that is not entirely correct (you pay an extra pointer per variant size, which in this case would be some overhead over the embedded version).
Still, I think most people don't worry so much about efficient packing of sum types, and instead the safety and convenience factors are more important. Of course, YMMV based on exact usage.
I'm not in anyway claiming that Go supports sum types. Someone just asked how they may be emulated, and I don't think it should be surprising that emulation has an overhead.
>> why doesn't he write blog posts? why he has so little online presence?
>> bellard is a programming genius and true C hacker. his works are so great ...
It's probably related. Obviously it's his and only his decision, but I wonder if him slowing down to share the knowledge and skills could have been more productive in the sense that others could do similar work.
Bellard is famous for starting a number of projects that have since been carried on by others.
Looking at his output some time ago, one of the main things that I found inspiring was how much good he did by sharing his work in a form that others could build on it.
Complaining that he's done insufficient to bring others on seems really unfair.
I wonder if we could regain the level of intellectual maturity of the 19th and 20th century and not criticize those who already give away so much that they are not working hard enough.
This is literally Animal Farm / team lead "multiplier" nonsense.
> But I think most importantly the decrease in dev speed and performance is an investment in future scalability.
It makes sense only if you'll ever need this scalability. And you take a hit on other fronts too: Infra cost, Deployment complexity. And both deployment complexity and code complexity also increase QA cost, instability, product and company reputation.
>> much like people don't often start with SQLite today
I thought that the card bonus programs on US credit cards were subsidized not by the transaction fees, but by the monthly interest payments. So actually payed by the non-responsible credit card users.
> If Apple were a different company, it would've made maps available for use on web browsers and non-Apple devices. That could also help in a more rapid improvement of maps as opposed to the mostly-useless state it's been in (except for a few countries and regions in certain countries that Apple likes and works more on).
If apple would have done that (for Maps and other services), how would it be different than Google?
Google offers these services for free to the end-user and generates revenue from ads.
Apple is using these services to sell more hardware devices, and generates revenue from there.
Is there an Emacs package which does something similar to the "Smalltalk Style" navigation view? It looks like it can be implemented in a very similar way to imenu
Should be interesting, especially if it can leverage lsp for the code analysis.
There was shampoo, an emacs mode for Smalltalk. It's still on github [1] but the old project home page [2] is now gone.
I recall that homepage had a convincing screenshot.
There is an implicit rule: Everyone talk about gross. Including the OP.
Salaries for developers are in the 60-80K EUR gross in DE[0]
The US median gross is <40K USD [1] and for software developers it is close to 100K USD (probably much higher is SV and major tech hubs, and much lower everywhere else) [2]
